The technology business is one of those industries that comes jammed packed with its own set of jargon. You would think that the use and misuse of this jargon is a contributing factor to the reason why so many software development projects are “challenged”.
Not so! In fact, one of the biggest problems with software projects is the collective agreement around what the term “estimate” means.
The English oxford dictionary defines estimate (noun) as:
“an approximate calculation or judgement of the value, number, quantity, or extent of something”
That seams pretty reasonable to me. It is clear that even though you’ve sized something up, it is only an approximation. Unfortunately what others sometimes hear is:
“a binding contract of cost and time, in which every other variable (often scope) can change, but which cost and time cannot”
To be fair, here is what a software developer might be thinking when they hear the word estimate, or provide an estimate:
“a optimistic guess about how long something might take given the incomplete and inconsistent description of something that needs to be built. I don’t ever expect to be held to this.”
I think that the oxford description is probably the fairest, where those doing the estimation need to give their best estimate, and take reasonable steps to clarify unknowns, but those receiving the estimate need to acknowledge that given imperfect knowledge, the resulting estimate will also be imperfect.
The real question is – given an imperfect estimate, who carries the risk and reward when the estimate is wrong. In our industry many customers believe that vendors should provide fixed-price estimates, and that any additional costs should be worn by the vendor.
In some cases the vendors accept this if only to avoid the uncomfortable conversation about the true nature of risk in software projects and structure in punitive change control clauses.
I prefer to get a good collective understanding of what an estimate is, and in the case of a particular estimate put some boundaries around what the estimate includes and what its relative strengths and weaknesses are.
Further, we have to acknowledge that way more than the envisaged scope for a project goes into producing an estimate. More often than not there is a critical business event which sets a deadline for a particular project (e.g. a legislation enforcement date), or a budget constraint (we can only afford 12 months of development at a certain team size).
Budget is usually the big one. A customer will typically only have a finite budget, so the project simply can’t cost more than that. The question then becomes what can you fit within that budget.
The challenge then becomes producing something of value in that budget. And that is also where the real risk is. You see if you can produce something that returns sufficient value for the money spent. If you can balance money spent, with value received as you progress with a project then there is very little risk of the project being classified as challenged.
For this reason I prefer T&M style projects where the project team has to actively work with the customer to provide value. When the value stops arriving, then the project either stops or changes direction.
At the end of the day, software development isn’t about estimates, and the vendor and customer getting one over on each other, it’s about trust. Trusting that the vendor is bringing the right technical skills to the table and working as fast as possible whilst achieving the quality outcomes the customer expects, and trusting that the customer will be engaged enough to direct the scope and priority of the project, and that the money that is being spent is going into something worthwhile.