How to accurately estimate and forecast in project management

Estimating costs is one tough aspect of project management. This task can be quite a bit easier and more effective if you follow four simple steps during the planning process.
Editor's note: This article was originally published on Feb. 19, 2003.

The new project plan sits on your desk. Before you open it, you think of all the issues you've had with other projects -- months-long delays, blown budgets, having to hire expensive contractors at the last minute. Now you're wondering what's waiting to bite you in this plan.

But the CIO's life shouldn't be that way. All projects contain risk, but a lot of the work on each project should be familiar to the performing organization, so you shouldn't have to start fresh each time you start a new project.

You can follow four essential elements to ensure the accuracy of estimates in any plan:

  1. Clarify the project priorities.
  2. Make sure the planning process allows for proper and complete estimates.
  3. Apply lessons learned from other projects.
  4. Don't make the team's plan fit management's guesses.

Clarify the project priorities

While no project should start without a proper business justification, you must also convey the project priorities to the team. Project managers talk about a project's "triple constraints" of scope (work), time (schedule), and cost (budget). When you initiate a new project, you're authorizing people to work under your auspices. You're also authorizing the project manager and the team to make decisions on your behalf (whether you realize it or not).

For the team to make decisions that are closely aligned to the way you would like them to be made, you must clearly state the project priorities. There's no such thing as "all three variables are equally important."

Think back to your Y2K projects. Everyone in the industry had time as priority number one. (You couldn't get a schedule extension if you tried.) Priority numbers two and three varied. Some companies paid enormous amounts for consultants to get mainframe applications fixed or rewritten. For these companies, scope was priority number two, and cost was priority number three.

Other organizations decided that some applications "weren't worth it" and scrapped some affected programs. For these companies, cost was the number two priority, and scope was number three.

The important point is to understand that the team needs to know what the priorities are in order to create estimates that accomplish the work in the right way.

Make sure the planning process allows for proper and complete estimates

A team of experts from the various functions within your organization got together and worked out the details. One of these people should be from the business unit that needs the solution the project will provide. Defining work, or scope, of the project is absolutely critical. All the stakeholders, including the CIO, need to know exactly what will be provided by the project, and what will not be provided.

The project management tool for defining scope is called the Work Breakdown Structure (WBS) -- the single most important project-planning tool. The WBS is "a deliverable-oriented grouping of project elements that organizes and defines the total work scope of the project," according to the Project Management Institute.

The project team builds the WBS by breaking down, or decomposing, the high-level solution into smaller pieces, or components. Components are broken down into sub-components, etc., until the team ends up with deliverables that are small enough to estimate duration and cost reasonably accurately. The team uses the WBS to generate an activity list. The items on the activity list are then reviewed to estimate the duration and cost of each one.

For best results, you should create three duration estimates for each activity: best case (optimistic), worst case (pessimistic), and the most likely (realistic) duration. At the minimum, three-point estimates should be created for any activity or deliverable that is unique, risky, or relatively new to the team. Ordinarily, the most likely estimates are used for most activities in developing the project schedule. Or the project manager may elect to use a weighted average of the three-point estimates for selected activities.

The three duration estimates allow the project manager to perform simple sensitivity analysis on the project schedule. By changing key durations, the project manager can model the overall schedule impact of possible scenarios. For example, the project manager can model what happens to the project schedule if a given activity takes the worst-case duration, instead of its most likely duration.

Apply lessons learned from other projects

Applying lessons learned is common sense, but it isn't automatic. CIOs need to know if the core team reviewed other projects within the organization for successes and failures, and if they learned from that information. If the team actually reviewed trade journals and industry sources for similar project information, that's a bonus!

For example, if the plan on your desk shows that the business requirements will be documented and accepted in 15 working days, and your last three projects took at least 20 working days each to get accepted requirements, your project manager should be able to explain why the team is estimating only 15 days for the new project. It's time to find out the following:

  • Are they reusing some earlier work?
  • Is a more skilled person doing the work?
  • Has the business unit already drafted a good version of the requirements?

As CIO, you need to be able to understand the context of the plan and hone in on the critical areas that might be a source of error or delay (as per past efforts). What do you need to do to make sure that lessons learned are collected?

  • Make sure that time is allocated at the end of every project to analyze, collect, and distribute lessons learned. Although I have been suggesting this for years, most of my project management students say, "That is the first thing that gets cut out of our schedules!"
  • Use a standard methodology. It almost doesn't matter which one. Your project teams just need to be able to reference some standard terminology for phases and deliverables, which in turn helps them compare past projects to current projects.
  • For a realistic view of project costs, implement a cost- and labor-tracking system that can capture actual and planned costs and durations down to the project deliverable level.
  • Invest in an archival system that will provide access to the above information. It could be project plans in three ring binders located in a project library, or it could be an enterprise-wide project data repository.

Don't make the team's plan fit management's guesses

This is the number one way to ensure project failure. Yet, almost every time I meet a new IT project manager, the discussion proceeds along these lines: "I've just been named project manager for Project X. We have to deploy this new application Y. Management has decided that we have 10 weeks and $175,000. But our best estimates indicate it will take 17 to 20 weeks, and more like $325,000. But we are just told to do the project, and make it fit management's targets."

If the above project proceeds, failure is assured. Management has overridden the detailed estimates of the team; the project manager is de-motivated, the team is even more de-motivated, and, in all probability, the project will take longer than even the team estimated, if it is allowed to run to completion.

If there are hard constraints, such as dates or budget limits, they must be communicated to the team. If the team's estimates of schedule and budget don't meet management's expectations, further discussion is required. Maybe the project really isn't worth doing. Or maybe the project isn't feasible given the constraints imposed.

Figure A

Figure A

Post this checklist on the wall to help with accurate project forecasting and estimating.

The bottom line

The CIO delegates responsibility for the project to the project manager. The project manager prepares estimates using good project management techniques and his or her best judgment. (Figure A recaps the project management techniques that lead to accurate estimates.)

Both the CIO and the project manager are responsible for learning from whatever happens on each project and to apply that learning to the next project. If all that is accomplished, not only does estimating become more accurate, but the entire project planning effort can be improved.

Get weekly PM tips in your inbox TechRepublic's IT Project Management newsletter, delivered on Wednesday, offers tips to help keep project managers and their teams on track. Automatically sign up today!

> The project management tool for defining scope is > called the Work Breakdown Structure (WBS). I'm an application developer/business analyst, estimation specialist, and software management consultant and not a PMI-trained project manager, but this statement puzzled me. I've always thought of scope in terms of what's to be delivered, and the WBS as a team document describing how we (initially) plan to do it. Especially when talking with sponsors, it's vital to steer the conversation towards results and not tasks. If they need a lower budget or shorter schedule, I want them thinking about dropping outcomes (software features) of lower priority to the business, not picking through the WBS and shaving time off of tasks.


"Don't make the team's plan fit management's guesses" Depending on the size of the management team's collective ego, just approaching them with staff estimates won't prove effective in deterring the plans of forging ahead on a sure-to-lose project. They'll likely chalk it up as workers who are lazy and/or unproductive just trying to justify their sloth. I've been in the position where I've had to do research (not just Googling for information, but actually doing academic-type research; journals, database searches, etc) to document similar projects at similar firms, and show management how much they cost. This is easier with scale (such as SAP & Waste Management...can write a book on the amount of information available on that case study) as opposed to smaller projects; but if you can find the information, it can really help make a poignant argument against proceeding as planned. Just wanted to throw that out there. I like the succinct checklist. I'll incorporate that into my toolbox.

While I agree with the author with respect to some of the fundamental tasks that need to be performed prior to the coding cycle, its seems that individuals who have never written code in their life tend to believe that the preliminary steps are unnecessary. They tend to enter into a sales or bargaining position where they believe you are first asking for more then what is needed so they believe it is there job to bargain you down. In effect they are the cause of the demise of the project but insure the blame will be placed on the developers, planners, etc.. I think the author pointed this out at the end of the article. I constantly struggle with estimating. One problem is to get the money to even make the estimate. As an independent software development company, many customers believe that the estimating stage should be done for free. Yet many will pay an architect huge sums of money to plan how their custom house will be built. My inhouse staff uses a home grown hourly tracking system for both billing and customer relations. I also use the system to arrive at estimation figures when repeating the development of similar modules. Its been helpful but when customers are faced with the reality of how long something takes they simply cant believe it and continue to seek consultants who will tell them what they want to hear instead of reality. I believe that this is the single most important factor that is ruining the image of professional developers and software architects. In short your ideas are correct but it simply doesn't follow the reality of human beings who are put into positions to make decisions. This type of training needs to be directed more to the CEO and financial department rather then IT who already know the steps. Bill D Intellimatic Inc a 20 year software developer veteran.


I would say it can be either depending on how you work, but I would think it's most useful to break down the work by task. An important principal in WBS's is the 100% rule where you list every deliverable (internal and external) so you know everything that is to be completed by the project (thus it would have every item in the scope, otherwise it wouldn't match the 100% rule). It just depends on how you work and what works for your project(s).

Editor's Picks