4.2 WHY DO WE ESTIMATE?

 < Day Day Up > 



4.2 WHY DO WE ESTIMATE?

I wish to start by stating what, for some people, will be the obvious. I am going to discuss why we in the IT industry need a cost estimation process within our installations and why, from a business viewpoint, that process can be vital to our success and, in some cases, to our survival.

Software development and enhancement centers around a project view of work. That is, around components of work that are managed as discrete elements with a defined end point and, if we are lucky, also a defined start point. The management of these elements is documented in the project plan in the sense that it is this plan that guides management activity. For example, if we are failing to meet the milestones described within the project plan we would hopefully instigate some form of corrective action to identify and deal with, or at least to contain, the problem that was causing the slip.

The foundation of the project plan is the estimate of cost or duration for the work items within the plan. The plan, in another form, may also be used to "bid" for the work in the first place. Based upon an initial statement of requirement from a potential customer, information is prepared that tells the customer what the cost of that work and its duration is likely to be and this can form the basis of a contractual agreement between the customer and the supplier.

So we can already see a process beginning to evolve around the "estimates." An estimate can form the basis of a bid for work and it can also feed into the more detailed planning process, including plans for risk management, when the work is won.

I remember attending a project planning course some years ago that most certainly did not live up to the expectations of some of the audience. Although the course was presented in an exceptionally clear and professional manner it concentrated on the techniques of project planning such as critical path analysis and earned value reporting. As such it did not address the problems that some of the audience wanted resolving which was ways of answering two questions; "What will this work cost me?" and "How long will it take?"

Project planning, as presented, seemed to consist of a applying very clear techniques to a very basic item of data, the estimate. What the individuals who felt somewhat cheated required was, obviously, a course that taught them how to estimate — or was it? As you will see, my belief is that estimation and project planning are so closely related that you cannot totally separate the two and make either work.

Of course, once you use an estimate and a planning process to produce cost and duration figures you are effectively making a promise. "This work will be done for this cost and it will be delivered to you, the customer, at this point in time." If your organization, be it the organization as a whole or an internal IT function, intends to operate a policy of "quality service" then you should, by definition, meet those promises.

This implies that your estimation processes, and I now include planning in that process, had better produce figures that you can meet. You cannot deliver a quality service if your projects arrive late and cost more than originally stated.

This should always be seen as a success factor for any business but it becomes a truly critical success factor if you operate in a fixed-price environment! Such an environment has no mercy on the poor software supplier. If the project you have bid on and won costs more than you thought, then you have no contractual right to cover those costs. Get those estimates wrong and you will suffer the consequences - totally!



 < Day Day Up > 



Software Metrics. Best Practices for Successful It Management
Software Metrics: Best Practices for Successful IT Management
ISBN: 1931332266
EAN: 2147483647
Year: 2003
Pages: 151
Authors: Paul Goodman

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net