Consider This -- How Requirements Gathering Can Help

Project estimation is extremely difficult without the right data, yet doing it effectively is one of the only ways to ensure the success of the project (and, by extension, the business). Unfortunately, many project managers find themselves unable to answer such crucial questions as:

• How long will the project take?
• How many resources will it consume?
• What is the appropriate amount to bid on/budget for this project?

Without this information, the project manager can never be sure that the schedule and budgets are accurate. The good news is that the requirements gathering phase of a project can actually provide insight into the length and scope. Here is an example of how this method works and how you can use it in your company.

The Wrong Way to Estimate

In 1992, I worked for a consulting company called The Kernel Group (TKG). I was put in charge of porting Tivoli's software from Sun's Solaris operating system to IBM's AIX operating system. The project was to be done under a fixed bid, so estimating the effort required to port the code was of paramount importance.

I looked at the code with a coworker of mine, and he came to the conclusion that we could port the million or so lines of code in about a weekend. I told him that it would take at least a week, maybe even two. We jointly decided that we probably ought to call it three weeks, just to be safe. As a result, our project bid was $325,000.

Once the project began, we discovered how truly terrible we as software engineers were at the task of project estimation. To make a long story short, the porting schedule expanded to exceed our original estimate, and we consumed not only all of the $325,000 but a lot more on top of it.

The Right Way to Estimate

TKG employees were required to track time on a per-project basis, and every project was broken into phases: requirements/specification, design, coding, testing, debugging, documentation, training, etc. This project for Tivoli was no different.

Just before we started working on the project, I read a 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% to 8% of the time it will take to complete the entire software project. He uses this formula to estimate total project size, meaning that if it took 60 hours to do the specification, you can infer that the total job will be 1,000 hours. Since the specification always comes first in any project, you can get some pretty reliable estimates from this method alone. In fact, in my experience as both a programmer and the CEO of a software company, I have found it to be incredibly accurate and useful.

After our huge mistake on that first project for Tivoli, we learned our lesson. When the next one came around, we used Grady's ratio to predict overall project size based on the length of the requirements phase. This time, we came up with a very accurate project estimate, and we continued to use the process 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 system, Tivoli was able to eventually sell their company to IBM for $743 million in 1995.

Measuring Progress

So how will you know when you've reached your goal for estimation process improvement? One way is to use a key performance indicator, which measures progress toward a strategic business goal. For example, you might use the formula [(EA)/E], where 'E' represents estimated hours to complete the project and 'A' represents actual hours spent to complete the project. It is important to keep this KPI value as close to zero as possible, which indicates that you are bidding on projects more accurately. You can get the necessary data to calculate it from any time-sheet system, including a paper one. Automated time-sheet systems, however, can actually provide reports to calculate the KPI figure for you.