Project estimation is extremely tough without the correct information, however doing it effectively is among the only ways to make certain the success of the project (and, by extension, the business). Regrettably, numerous project managers locate themselves unable to answer critical questions like:
- How lengthy will the project take?
- How several resources will it consume?
- What is the appropriate quantity to bid on/budget for this project?
Without having this info, the project manager can never make sure that the schedule and budgets are accurate. The good news is that the requirements gathering phase of a project can really offer insight into the length and scope. Here is an example of how this method works and how it may be implemented into any business.
The Wrong Way
In 1992, whilst working for a consulting corporation referred to as The Kernel Group (TKG), our team’s job was to port Tivoli’s software from Sun’s Solaris operating system to IBM’s AIX operating program. The project was to be accomplished under a fixed bid, so estimating the effort required to port the code was of paramount significance.
Our team examined the code thoroughly. Some members thought that the million or so lines of code could be ported in about two days. Other people thought it would take at least a week, perhaps even two. The team jointly decided that we ought to estimate for 3 weeks, just to be secure. As a result, our project bid was $325,000.
Once the project began, we discovered how inaccurate our project estimation was. The porting schedule expanded to exceed our original estimate and we consumed not merely all the $325,000, but a lot more on top of that.
The Right Way
TKG employees had been necessary to track time on a per-project basis, and each and every project was broken into phases: requirements/specification, design, coding, testing, debugging, documentation, training, etc. The project for Tivoli was no diverse.
There is a extremely valuable book by Robert B. Grady called Practical Software Metrics for Project Management and Process Improvement. Grady believes that the requirements/specification phase generally takes up 6-8 percent of the time it’s going to take to complete the entire software project. He utilizes this formula to estimate total project size, meaning that if it took 60 hours to do the specification, one can infer that the total job will take 1,000 hours. Given that the specification usually comes 1st in any project, one can get some fairly reliable estimates from this technique alone.
Right after the enormous mistake on the Tivoli project, our team learned its lesson. When the next project came about, we used Grady’s ratio to predict overall project size based on the length of the requirements phase. This time, we came up having a very accurate project estimate and continued to use the procedure to our advantage for all of the subsequent fixed-cost consulting work we did for Tivoli. Due in part to the strength of the solution and how well it ran on IBM’s AIX operating method, Tivoli was able to ultimately sell the business to IBM for $743 million in 1995.