We create cost estimates at many times in a project. From budgetary estimates at the start of a project all the way to PERT estimates of tasks in a work breakdown structure. Creating a budgetary estimate seems impossible – you have to make many assumptions, your estimates are based on the unknown – they can’t be good. There are ways to make budgetary estimates easier to generate and refine – but they can create a sense of false precision.
Small Tasks Can Be Estimated Accurately
We wrote before about reasons that a project plan will fail. One of those reasons is bad estimates. One of the best ways to assure that you have reasonable estimates is to manage the size of those estimates. When you keep your estimates to tasks in the 1 to 8 hour range, you are forced to put additional thought into design, implementation gotchas, and you end up making better estimates.
Early Estimates for Large Jobs
At the other end of the spectrum, we sometimes have to build budgetary estimates for large jobs. Jobs that are too big to estimate in terms of small tasks – at least in the time that we have to create the estimates. Use case points can be used as a framework to provide a reasonable estimate of large jobs. To use a use case points analysis, you have to have an understanding of scope and goals that allows you to identify a set of use cases, with enough detail to know how complex they are.
Sometimes we have to make estimates before we have the level of detail needed to apply use case points (or other structured techniques) to build a budgetary estimate.
Our only hope for very large, ill-defined estimation is to create a very rough estimate – in man-days or man-months.
Just Kidding yourself
You can make an argument that any estimate of a project so poorly defined that you don’t know the use cases well enough to estimate them is a waste of time – that you’re just kidding yourself. If you are trying to build an accurate estimate – we agree. But you sometimes have to make decisions without accurate estimates. A business often has to make relative decisions about which projects to pursue, before there is detailed information which can take time to gather.
OK, so you’re in an impossible position – what do you do?
- Breath.
- Plan for the future.
- Build a budgetary estimate (also known as a rough order of magnitude estimate).
Breath
Recognize that you’re the “expert” and your executives are looking to you to give them some insight about how big the job is.
Planning for the Future
When you do an early, budgetary estimate, you should expect that you will be iteratively refining that estimate – maybe multiple times per day. And you’re estimating something large, with a lot of moving parts, and a lot of assumptions. If it wasn’t a large, complex, messed-up, ambiguous affair, you would have been able to make better estimates. So plan on making a lot of changes to the estimates.
Building A Budgetary Estimate
Don’t look at a big project and say “It’s 1000 man-months” and call it a day. Decomposition helps you make better estimates on small tasks – the same is true on large projects. So, decompose as much as you can. If you’re estimating an enterprise deployment of multiple applications, break down the estimates to a per-application level. Assuming you can’t go any further, estimate the effort at this level. Then set up a spreadsheet to roll up the estimates for the applications into an overall estimate.
There are some other things you can look at at this point
- Sequencing – are there any obvious dependencies that force serial development activities? What can be done in parallel.
- Staffing – do you have an unlimited supply of team members, or do you need to stagger development due to resource constraints?
- Regional teams – can you split the development or testing to outsourced or regional teams?
These inputs help you with staggering the allocation of effort over time. They also allow you to apply a burden rate for the labor (based on financial models for staffing costs).
Iteration
Your spreadsheet should roll all of the costs (over time) up to final numbers. You end up with a whole bunch (maybe hundreds) of “small numbers” that, with assumptions, become one big number.
Then you show this to your executive – who sees hundreds of numbers, and one big number. Improperly positioned, your executive will walk away believing that the big number is precise, because the estimation looks complex. This introduces a sense of false precision. You know that the “small” numbers are educated guesses. So adding it all up gives you just one big educated guess. If you miscommunicate at this stage, you could be setting yourself up for disaster. Your exec might shoot down the project because of your unacceptably high estimate. Or even worse, commit you to a dangerous and impractically low estimate.
The way you climb out of this morass is with iterations. So plan your spreadsheet to make it easier to change. Get better estimates, validate assumptions. Start detailed planning. With each iteration, remove an unknown. Create a better estimate for a subset of your massive project. The more time you have, the better your estimate becomes. Just keep in mind that it is still budgetary, until you use a rigorous estimation technique like the ones we mentioned above.
Directional
Now you’ve uncomfortably delivered a budgetary estimate, hopefully set expectations so that it will be received the right way. You’ve improved it as much as you can with the time you have available by iterating. What now?
Breath again.
Your estimate is likely to be directionally correct, however wrong the actual numbers may be. Your estimate is going to be compared with other estimates that are likely to be just as inaccurate. But your numbers do provide some insight into the relative sizes of the different projects. And they will allow executives to make the best decisions they can on very limited information.
Conclusion
Do what you have to do. Understand how suspect the numbers are. And make them better, as much as you can.
