December 7, 2005

My good friend Stan Rifkin (formerly a key member of Watts Humphrey’s team at the Carnegie Mellon Software Engineering Institute, and now principal of Master Systems Inc.) once penned the following criteria for software project estimation:

1) Commitments have to be based on work [scope] to be performed; therefore, there must be agreement on this.
2) Estimates have to be based on a) the work to be performed and b) historical records of performance.
3) Commitments must not exceed the capability to perform, or else there is no reason to estimate.

What Stan meant on bullet 1) has to do with the importance of the quantitiy of work products entering a negotiation discussion. The key words are commitment, and agreement. These work products can be number of features or requirements; later on during design they can also be the number of software elements like modules, programs, objects, or new/changed code.

Translating bullet 2) is about knowinging your capability. Most teams don’t keep good records of their most recent projects. It’s not hard to get, and I offer a roadmap in my article “Corporate Alzheimers and Deadline Management“.

Bullet 3) is most important. It means “don’t plan beyond your capacity.” Nearly everyone does it; hence the ever-present statistics on project failures over the years. But what I think Stan means when he uses the phrase, “else there is no reason to estimate”, is that you WILL start what is called a Yourdon Death March project, and you are doomed.

How does this pertain to software estimation tools, you might ask? The answer has to do with keeping these goal-line objectives in mind, and recognizing the importance of calibrating a tool based on your own completed projects, and explicitly solving the issue of software sizing. Easy to use templates should be the order of the day on both items. In the event that you may not have ready access to historical projects, the tool should be able to access records from an up-to-date industry database to get you started.