4.8 A STRATEGIC TEMPLATE FOR COST ESTIMATION

< Day Day Up >

Estimation is a process. To control estimation, to improve its effectiveness within our own organization we must stop treating it as a black box activity and remove the air of formula-driven magic so often promoted by IT staff. Do this and the process can be defined, managed, modified and optimized.

I will now present a template definition of that process which I hope can be tailored to your organization. This will give you the process definition and you can then get on with managing that process.

We start with an overview of the estimation process. If you imagine the development process as a V model with requirements definition, high- and low-level design as the components of the left leg of that V, coding or implementation as the apex and the various testing activities, unit, sub-system or link and system testing forming the right hand leg you may ask where the estimation activities fit. I suggest that you think of a second V model paralleling the development V. The components of the second V includes work consolidation to form the basic project, estimation at different stages of development, project control and project, rather than technical, reviews. This chapter concentrates upon the estimation activities.

You can think of the various techniques used to help estimators as "bricks" out of which we build the estimating process. You can select from those presented here and from the various commercial tools to form your own organizational estimating strategy. All of the techniques mentioned here are described in other technical books that deal with the subject. If you can still find a copy, one of the best collections of such descriptions can be found in the appendices of the "Software Reliability Handbook," Rook (1) . This is possibly one of the best contributions to our understanding of metrics, albeit that the author is sadly no longer with us.

In fact, so much has been written about estimating techniques that I do not intend to repeat the very detailed technical discussions here, if you are interested then I suggest you use the sources quoted in the bibliography and form your own opinion. Here you will only find a brief discussion of technical aspects.

The estimation process must interact with its environment and you may wonder if this template can apply to both enhancement projects and to new development work. I will state quite categorically that the template does apply to both environments. Corrective maintenance, that is fixing bugs in the current release of the a system, is better considered as support. This type of work needs to be managed and that management depends upon the collection of relevant management statistics that will allow you to estimate the likely support costs for a given release for your own environment. However, it is not feasible to produce estimates from some formal mechanism when you have a red priority defect that has to be fixed ASAP!

The most important impact that the environment has is that things tend to be easier in a maintenance environment where more than one release is made during a financial year. The reason is simply that you have data available to you on a regular basis and this data can be used to manage and assess your estimation process.

Given that estimation is a process that involves people, then we should consider the different roles that those people can play. This brings us to an interesting point: there is considerable debate as to whether estimation should be the responsibility of individual project managers or of a centralized estimating group. The arguments go something like this:

If my IT group is regularly required to produce estimates then I am tying up valuable project resources by diverting them onto this type of work, which would seem to suggest that we could improve effectiveness by establishing a centralized function that took on the responsibility for estimate production. Furthermore, a group of individuals whose main role was to make estimates should quickly develop expertise in that work. Essentially, this approach would produce an experience center.
The counter argument is that people do not react well to imposed estimates whether they come from management or from an estimating group. In fact, presenting a project manager with an estimate and then expecting him or her to deliver against that estimate is almost certainly going to lead to projects that do not deliver on time and in budget! Of course, if every project manager is going to be expected to take responsibility for estimation, then this does increase the scale and complexity of the job if you try to improve your own organizational estimation process.

So, what is the answer if, as it appears, both approaches have positive and negative aspects? A wise man once said that, when placed on the twin horns of a dilemma, you should seek the third horn. In other words, there are more than two ways to skin a cat!

I believe that ownership of the estimates by the project manager is vital and I suggest that the primary estimator be the project manager. The primary estimator is the person who has the final say over which estimate is submitted to the estimate recipient. Assuming that the estimate is accepted, the project manager cannot then claim that the estimate was imposed on him. One thing that your own organization will have to do is define the level of project or projects for which there will be a primary estimator.

The primary estimator should not be expected to do the work in isolation. Your organization should define the role of assistant estimator. Assistant estimators help the primary estimator by providing additional views of the project, by providing different levels and types of experience and by providing sounding boards against which the primary estimator can bounce ideas of cost and duration.

Additionally you should, in my opinion, establish an estimation support group. This group can develop into the center of experience mentioned earlier, the main difference is that they act in a consultative role rather than in a prescriptive role and that their position in respect of the primary estimator is clearly defined. They also have another role. In most organizations the estimation process can be classified as "ad hoc." This is a polite way of saying chaotic! Changing this situation so that the organization boasts a defined, managed and optimizing estimation process will not happen overnight and somebody must facilitate this evolution. The estimation support group can provide training, can cross check estimates from managers to assess their feasibility and can monitor the process to identify improvements and areas that need improving.

While such a group represents an additional overhead it must be realized that change does not happen automatically or without cost. To rephrase a common quotation from the Quality guru Crosby, Quality is free - eventually!

The final role that needs to be defined is that of the estimate recipient. This can be a real customer, especially in a bid situation, a planner, marketing or a manager. I often remember a tale told to me by a technical director of his project manager days. He went in with an estimate which was then cut by his boss. Needless to say, the project managers estimate proved to be much more accurate even though, he assured me, he tried to do the job as quickly as possible.

I often wondered how he treated his project managers now that the shoe was on the other foot. Which raises an important question, what happens when the estimate recipient questions that estimate?

In reality this situation will be constantly present and the estimation process must identify and facilitate a sub-process of negotiation and reconciliation. Obviously personalities will have an impact on this activity but I feel that it is safe to assume that most individuals involved in project management, and hence in the estimation process, are actively committed to making sure that a project succeeds. There should be a formal, minuted meeting between the primary estimator and the estimate recipient which is structured around the concept of the project management triangle.

This model simply states that there are three, high level parameters that affect projects; duration, cost and content. Only two of these parameters can be fixed. For example, if I have to decorate a house then the content may appear to be fixed. I can only do the work faster if I load resources onto the job increasing cost, in other words if I fix content then duration and cost trade off. But of course the content, even in this job is not necessarily fixed. I may reduce content by specifying one coat of paint instead of two and in this way I may work to a fixed duration by trading off content and cost.

Such a discussion assumes that my estimates of cost, content and duration are true and in software engineering projects it is impossible to be sure of this. What I can do is increase my confidence in those estimates by recording past performance and, most importantly, by recording the assumptions that lie behind my estimates. It is much easier to discuss, or argue, about assumptions than about estimates because my ownership of the assumptions is less solid.

Of course, if a manager insists that my estimate be reduced then he should expect to have to justify that reduction by recording and stating the underlying assumptions that apply. This acceptance of responsibility should form part of your estimating procedures or strategy and should be accepted and endorsed by your organization. Implementing such a strategy is not easy and this is one area where the estimation support group can help because they should be responsible for auditing the process and its application. The manager who insists that an estimate be reduced records the reasons why and the support group ensures that this is done.

The worst-case scenario where a project manager has to accept estimates imposed from above that are lower than those he or she believes apply needs careful management. What has happened is that a risk has been associated with the project and two things should occur. The project manager should be allowed to record the fact that the estimates are imposed and the resulting project should receive management attention to a greater extent than normal during the whole of its life or until the risk is resolved through re-estimation.

If your organization has a central project control office then this risk management action should be their responsibility. But you may be in for a pleasant surprise. It does seem that when estimation processes are defined along the lines described so far, the perception of imposition concerning estimates reduces because the project manager will be more involved in the estimation process than may otherwise happen. Why is this? It may be that the fact that everyone is now working within a defined procedure that, in part at least, demystifies the estimation process and that sets out clear responsibilities with lines of communication. This results in clearer understanding and a depersonalization of that process and, hence, a reduction in conflict. After all, none of us want a project to fail but sometimes we don't talk about the problems.

Which is fine in theory but what about the estimation template? Let us start with some of the possible building bricks that we can use, the estimating techniques I have mentioned. What follows is a description of those techniques as I have helped implement them in more than one organization.

I will start with something called the Modified Delphi Technique. This is based on the Wideband Delphi Technique that is fully described in "Software Engineering Economics" by Barry Boehm and it is nothing more that a slightly formalized approach to using expert opinion.

< Day Day Up >