Preventing IT project failure
The Dutch government (see conclusions of the Elias committee) has published an investigation report that the Dutch Government has no control over the majority of their own IT projects. At the start there are no reliable costs calculations, the proposed delivery dates are never met, and the delivered products are often not all needed products. In short our Dutch government is not in control. The Dutch government is not alone, the Standish Group says in their annual CHAOS report that 70% of IT projects fail or, better defined, are not delivered according to their first project calculation.
This does not correspond with our experiences from the Dutch software industry. Common sense also says that it would be curious that over 10% of all IT projects fail, while today’s society no longer function without IT. The difference can be explained by the fact that several (political) definitions can be used for the term success. Of course every IT project has inherent uncertainties and risks and projects do fail.
However, a professional understands the nuances of these uncertainties and knows how to deal with it. The main instrument used by a professional is a reliable project calculation. A reliable project calculation helps to determine which solution will be on time, within the maximum provided budget, provides a good quality system that complies with the essential requirements.
From our practical experience the most troublesome issues with an IT project calculation (and the definition of success) are:
Success definition
Some stakeholders abuse the estimations. By example at the start of a project / business case little is known of the requirements. Some stakeholders (mainly senior management and politicians) use the lowest value of a budget range indication for a fixed price contract, or even tell when a project should be completed and at what cost.
Product Size
An estimate should always include the uncertainty range (mostly described as minimum, most likely and maximum). This applies particularly for product size. Most senior management think that if the business requirements are known, that it also means that the product size is fixed (as senior management states: I will allow no scope creep ….), while in practice the product size is at that stage still very uncertain. It is therefore essential to be aware of what the approximate product size is in units that are relevant for all stakeholders and measurable (such as function points, but it may also be some interfaces, screens, reports, messages, etc.).
Productivity
Every project calculation should give:
- a clear description of where the estimated productivity is based on and which activities are included (realization, testing) etc
- on what similar projects the productivity is based and what activities / products for this project are unique (and where is the uncertainty)
Tooling
What tooling is used (for example Seer SEM or QSM SLIM Estimate) for the project calculation.
Planning
Only after the project calculation is made, a plan can be drawn up. A common problem is that the management beforehand mentions a deadline determined by a budget and then says that the project calculation must meet these conditions.
Monitoring and adjustment
A good project calculation is not only used at the start of a project, but also for monitoring progress. This makes it all the more necessary that the estimate is objective, repeatable, verifiable and defensible and that the original estimate may be used.
The Nesma solution : Basis of Estimate
The Nesma Basis of Estimate committee has created a practical (framework) guide, the Basis of Estimate, for project calculations of software projects, based on experiences in the field of IT project management. This guideline uses the generic model of AACE International‘s Total Cost Management (TCM) Framework as a basis. The Basis of Estimate is a manual for the preparation of an IT budget and registered members can download it for free from our website.
About the author
Marten Eisma is Information Architect at CGI in the Netherlands and is a member of the Nesma Basis of Estimate committee.