If you have ever been asked to estimate the cost of a project you will know it is not easy. Estimating a small project that's similar to one you've done before might not be too difficult. But estimating the cost of a large project without personal experience to fall back on is very much more difficult.
A senior manager approaches you in the corridor. He is on his way to an important meeting. He needs a rough idea - just a rough idea - of what a project that he has a vague idea about might cost. He asks you to give him an estimate of the project's cost. What do you do, do you give him an estimate?
I knew a project manager whose response to such a request would be as follows. He would take a pair of dice from his pocket and roll them. If the dice showed nine he would say the project will cost nine. When asked 'nine what?' he would reply with a shrug 'make up your own mind'. Nine dollars, nine years, nine thousand man months - who knows?
Few of us are quite that brave when faced with a senior executive on the warpath. But the point is: if you don't know, say so.
Estimating tools are a seductive idea. You buy an estimating tool that asks you hundreds, even thousands, of questions about your project and then tells you what the project will cost. The trouble is that these tools tend to ask you two sorts of questions: the unanswerable and the un-understandable.
At the start of a large project if the tool asks 'how many web pages will be produced of medium complexity?' that question is probably unanswerable. And if the tool asks 'will six sigma quality be a mandatory requirement in non-critical month end processing?' you wouldn't know what the question meant and certainly wouldn't realise that the difference between a yes and a no answer could mean a doubling of testing costs. By the time you've guessed at the answers to a couple of hundred questions like that you can see how accurate the tool's estimate is going to be.
Function Points is another great idea. Each bit of stuff you will deliver will count as a certain number of Function Points. A complex web page might be 10, a simple one might be 2. We know it takes one man month to deliver, say, 100 Function Points, so just work out how many Function Points you will deliver and, Bob's your Uncle, you know what the project will cost!
But you can see the problem there as well as I can - you have to know exactly what you will deliver before you can give an estimate. And you don't know that at the outset of the project.
So is there a magic bullet, some secret technique that allows those in the know to provide accurate estimates at the start of large projects? No, there isn't. Certainly not for software projects. Building a bridge, maybe. Bridge building may be highly technical but it is essentially definable at an early stage and lends itself to the use of formulae - given the length of the span and the width of the bridge a good estimate of the quantity of steel can be given. Unfortunately software projects remain shrouded in mist for much longer into their lifecycle. And it's much harder to know in software projects if things have been done properly during the early stages - and if they haven't been done properly who knows what testing might cost!
But, aha you say, surely bridges and software are the same: in both cases when the design is completed an accurate estimate of project cost is possible. True (assuming again that the design is done properly). But in a construction project a relatively small percentage of the total project cost is spent in design. In a software project perhaps 40% of the project budget will be spent by the time the design is completed. Waiting until you've done 40% of the project before giving an estimate may not always be acceptable.
So, is there an answer? Well, yes and no. Yes, things can be done to make estimates much more reliable. But no, there is no single, simple way of estimating software projects accurately at the outset. Reliable estimating unfortunately comes down to hard work, proactivity and self discipline.
Hard work: doing each stage of the project properly, particularly the early stages. It's hard work to pin down software projects and produce a solid Project Definition. It is hard work and difficult properly and completely to define the business processes that the new software will automate. It is hard work to produce a solid design and to ensure its correctness and completeness.
Proactivity: lifting up stones to see what crawls out early on in the project requires get up and go. It's all too easy to leave the stones unturned and then have the problems crawl out of their own accord near the end of the project. Particularly if the project manager knows he will be long gone before the project nears its end.
Self discipline: pretending you've finished the design when you haven't really is very easy in a software project (particularly if the project manager is on a bonus for completing the design on time) but can mean huge and unpredictable costs later in the project. Delaying the design stage end date until the design really is finished will require self discipline - even self sacrifice - but will make the estimate for the remainder of the project more reliable.
The course therefore does not just focus on estimating techniques - they are pretty meaningless when considered in isolation. (If the project is estimated perfectly but is then mismanaged, that 'perfect' estimate will turn out to be very wrong!)
The course covers how to get the project properly defined; how to try and ensure that requirements and design are complete and correct; how to factor in unknowns and uncertainties - risks, issues, change; what can be estimated when and how to produce estimates; how to manage the performance of the project so that it does come in close to the estimate. Indeed the course takes an holistic approach to managing projects and views estimating as one of a number of interrelated and interdependent tasks that the project manager and others must perform properly if the project is to be a success.
Project Estimating is one of the topics covered in this
Project Management Book.
The book is in essence a free, online version of the project management course.
Articles on Project Management:
So You Want To Be A Project Manager?
Quality Management in Software Development Projects
Project Management in the Public Sector
The Tale of Three Project Managers
Towards a Project-Centric World
Project Management Proverbs and Training Course
Risk Management in Software Development Projects
Project Management Book
Home Sitemap Contact Us Project Management Articles Project Management Book IT Project Management Course