logo_nesma

Preventing IT project failure

The Dutch government (ver 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 controlar. 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.

© Standish Group 2014This 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) definiciones can be used for the term success. Of course every IT project has inherent uncertainties and risks and projects do fail.

sin embargo, 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) son:

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 tamaño del producto. 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 (como puntos de función, but it may also be some interfaces, screens, reports, messages, etc.).

Productividad

Every project calculation should give:

  • a clear description of where the estimated productivity is based on and which activities are included (realization, pruebas) 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 (Por ejemplo Seer SEM o QSM SLIM Estimate) for the project calculation.

Planificación

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, repetible, verifiable and defensible and that the original estimate may be used.

The Nesma solution : Bases de Estimaciónpictorial_nesma.png

el nesma Comité de base de estimación has created a practical (framework) guía, la Bases de Estimación, for project calculations of software projects, based on experiences in the field of IT project management. This guideline uses the generic model of AACE Internacional‘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.

 

Sobre el Autor

Marten Eisma es arquitecto de información en CGI en los Países Bajos y es miembro de la norteesma Comité de base de estimación.

 

Una publicación de blog representa la opinión personal del autor.
y puede no coincidir necesariamente con las políticas oficiales de Nesma.
Comparte este artículo en:

Deja una respuesta