What is Project Estimation
Project Estimation is where you work out what length of time in man days or man hours that it will take to complete a task. all of these tasks are added together to get the Project Estimate.
Project Estimation is one of the most important tasks for a successful project. Yet so many places get it wrong. If you get it wrong then you can be scuppered right from the start. You will be fighting an uphill battle all the way – and it will be unsuccessful.
1. How Are Projects Estimated
I have never seen anything so unscientific as the process used for estimating IT projects. It goes something like this. If 100 metres can be run in 9.58 seconds then if you multiply that by 100 you can see how fast someone can run 10,000 metres.
What usually happens is very rough. The project estimator(s) will take chunks and say this should take 10 days, this should take 15 days, this should take 12 days. This is just from their experience but it is a very rough and unscientific method of estimating.
2. Who Estimates Projects Currently
You often get a Project Manager coming in from the outside who estimates the projects. All they can estimate is how long it would take the average person in previous places he or she has worked on previous projects he or she has worked on.
They have no idea on the speed that the people at this new company can create software. Let’s face it, even the people who have been at the company a long time would be pretty poor at estimating how long people they know would take to do a piece of work never mind someone from the outside.
3. How Project Estimation is Done
Tell me this. How long do you think it would take me to run 10,000 metres? That’s right, you know very little about me, what condition I am in, what age I am, whether I smoke or not etc. It could be anything. However, what if I gave you an extra piece of information?
What if I told you that the last time I ran 10,000 metres I did it in 40 minutes. I also said that I had done some good training since then and was now in slightly better condition.
That would help you a lot in estimating how fast I could run 10,000 metres next time out. If you then estimated that I could run it in 39 minutes next time you probably wouldn’t be very far out.
4. How Projects Should be Estimated
So, now tell me. How often, in project estimation, is this information available. That is, how speedy are the analysts and developers in an organisation. What is the quality is the code that they produce?
And yet, as you could see from my 10,000 metres question, this information is crucial. That’s if you are going to make a proper assessment and do a proper project estimation of how quickly a project can be done.
With the information of how fast I had done the 10,000 metres it would be entirely possible to do a reasonable project estimation of how fast I could run a 10,000 metres again. Without this information you are likely to be wildly out in your project estimation of how fast I could run the next 10,000 meters I participated in.
And yet this is how, in IT, project estimation normally works. Stupid isn’t it?
How to Estimate Current Company Project Speed
The first thing anyone should do before project estimation is to find out how quickly that the company was able to do previous projects. This will not be as difficult as you may imagine. The company will have a record of how long the project took in terms of man days, how much the system cost. It will also have the functionality of previous systems documented.
The first thing that a new Project Manager must do is to find out how fast the company was previously in creating a system. He or she should take a good example from a recent similarly sized project.
The best way to measure the speed of a company in doing projects is to count the function points. It’s not a perfect way of project estimation. However, it’s a lot better than the usual finger-in-the air method that is currently used.
5. How to Use Function Points to Measure Projects
You will have been provided with the number of Man Days that the previous system took to implement. Once you have your Function Points counted, you can then divide the Man Days by Function Points. That’s to find out how many Function Points were previously delivered per day.
Once you have that information you can then use that for project estimation on the new project. You have the specification. So go and count the expected Function Points. One problem that you have here is that, as the system progresses, the number of Function Points is likely to rise as functionality is added or reveals itself.
6. How to Estimate Likely Project Creep
What you should do here is to ask for a copy of the original specification at the start of the previous project. That is before any functionality was added. If you count the function points in that you can then see how much the number of Function Points increased through the project.
If it rose 30% through the project you would then add 30% to your estimate once you’ve counted the initial Function Points as that is the growth you would expect. This may take a little time but it is well worthwhile.
7. How to Use the Average Company Speed for Estimating Projects
This shows you the rate that the organisation can create working code. However, the individuals on your project may not be all the same. Also, they may have different speeds of producing code. Although salaries are not that different in IT for people on the same grades, at the same companies, productivity can be very different.
However, when estimating the length of time a project will take it is probably better to take the company average rather than factor in the different speeds that different developers and analysts go at. This will give you a little extra contingency.
So take that for granted in the beginning. Otherwise you could be badly hit if some of the better people took ill or left the company.
So, now you have your scientifically calculated the speed that the organisation can create working code. You should use that now for your estimate of the project and include the Function Point growth contingency.
