In the popular television game show Jeopardy, contestants are given short phrase answers and are challenged to pose the associated question. The half-hour show has been a mainstay on prime time television for many years and boasts millions of viewers.
While Jeopardy provides great no-risk entertainment for contestants and viewers, a real-life “game” of Jeopardy plays out daily in corporations throughout the world, only it’s called something else: Date-driven-estimating!
Here’s how it typically plays out:
Business executive: “July 15.” (The Jeopardy style answer)
Contestant / CIO (pondering): “Is that the date you announced that the software would be ready?”
Business executive: “Correct! Now make it happen.”
Poor project estimating is one of the pervasive issues in software development – and the situation doesn’t seem to be getting any better despite process improvement models such as the Capability Maturity Model Integration (CMMI(R)) and formal project management.
It doesn’t seem to matter how advanced or mature is the IT organization – good project estimation is elusive. When a project does come in according to schedule, it is often a matter of coercion – that is the project manager has cajoled, manipulated or somehow morphed the project schedule to match an often arbitrary end date.
Author Steve McConnell once coined the phrase “Date-Driven-Estimating” and stated that it was the most prevalent estimating method in use today. In Date driven estimating, management announces the project delivery date and then the project team works backwards to the current date. The worst-case (and not unlikely) result is when the project can make the date ONLY if it was started several months ago. The schedule is then retrofitted by piling on more resources along the timeline until everything is included between the start and end dates. Somehow, such artificial manipulation transforms the impossible schedule into one that can work…
In engineering projects where physical and scientific constraints are fixed (such as the days required for concrete to cure), it is easier to see that such practices are prone to create outright project failures before the project even gets started. For example, a road construction project cannot be sped up by adding too many resources – physical limitations of engineering construction prevail and building codes govern project progress. Not so in software development. In fact, just this evening I met someone from a major financial services company who told me of a software project where the coding commenced within two weeks of the project start – even before they had documented the requirements. (No, it was not an agile project!)
What can be done when there is a pre-set budget or firm schedule set before any requirements are documented? From an investment point of view, customers want to curtail costs during the development and still get the software they need to improve their business.
From a supplier point of view, the goal is to get paid for the hours expended delivering the correct solution while being flexible to the inevitable changes that will happen along the way.
The two approaches seem at odds with one another – customers want to be fiscally responsible for curtailing costs, and suppliers want to be responsive to their customers yet get paid for the work they are directed to do. Firm fixed price projects (even before requirements are known) have been the solution preferred by customers to minimize the risk of budget overruns but all the risk is assumed by the supplier – especially before requirements are known. But as in any partnership there is no such thing as a win/lose partnership – if the customer wins and the supplier loses – both sides ultimately lose.
So, what can be done to avoid such a dilemma and achieve a win/win scenario? One solution is to deliver bite sized, incremental 2-week software releases using Agile Methods (scrums) . A two-week timeframe is easier to manage and gain an accurate estimate than is a long-term development project.
Another approach is unit pricing…. Unit pricing is based on working with a cost per function point (software sizing) and is a promising and realistic option to reach success. This approach plus other evolutionary steps are contained in the northernSCOPE model – already successful in Finland, Australia, and other countries.
Watch this space for more about the northernSCOPE approach and upcoming US training workshops.
Meanwhile here’s a couple of earlier posts on the topics:
Isn’t it time we changed the channel and stopped playing IT Jeopardy?