Fear No Project Blog – Focusing on the Management Side of Projects

Establishing a project budget can be as simple as calculating what it will cost to perform each task in the work breakdown structure and adding them to get a total budget. However, as any project manager who has created a project budget knows, creating a project budget is rarely simple or straightforward (and usually not totally in your control!).

The complicating factors include clients who want as much functionality as possible for the lowest cost, business development and sales staff who wants to win contracts, and senior managers who want to maximize profits. In addition, everyone wants the product to work well and be easy to use. The person in the middle of this vested-interest conflict is the project manager.

And for those certified PMPs, there is a whole section in the PMBOK® that talks about this topic.  Planning in chapter 3 talks about estimating costs and then budget as a part of the planning process and then chapter 7 “Project Cost Management” discusses the techniques and best practices for preparing budgets and managing the costs.

Just because creating an acceptable project budget is not simple does not mean you will not have to do it. So, how can a project manager protect the hoped for success of the project and manage risks by not agreeing to do more than can be done?

Not the Dilbert way – of course. Checking out PMBOK, Chapter 7, they suggest beginning with project scope, which may require the addition of design detail to create defendable cost numbers. You also need the project schedule and information on staff availability. Once you know what needs to be done, how quickly and by whom, cost estimating can begin.

PMBOK lists several cost estimating methods that may be done alone or in complementary fashion.

• Expert judgment – your experience on similar tasks and projects, input from consultants
• Analogous estimating – other similar organization projects cost history data
• Parametric estimating – Parametric Cost Estimating Handbook from NASA offers guidance, though somewhat dated. COCOMO II is used in traditional waterfall style software development. According to S. Chandrasekaran from St.Joseph’s College of Engineering, Agile software development requires a different cost estimating model which he describes in his paper, “Multi-criteria Approach for Agile Software Cost Estimating Model,” which can be found with other cost estimating articles at 2Dix.
• Bottom up
• Three point estimating – most likely, optimistic, pessimistic
• Reserve analysis – with a contingency fund to cover uncertainty in estimates
• Cost of quality – add in

My advice to you is “back up your estimates with data”. Be prepared to justify costs and explain risks – in non-technical terms — of making too optimistic assumptions. Try to achieve reduction in scope commensurate with lowered budgets. Do not feel too badly if you lose some of the cost estimating battles.  The real key is to document your assumptions (like there are 7 modules to design, or we will perform 2 week long tests).

What has been your experience with cost estimating software projects in the real world? Do you pad your estimates knowing you may have to settle for less?  Or do you just add some contingency to duration and costs?

Leave a comment and share your experience!