"Fiscus", "Toll Collect", "Virtual employment market" - Why do many IT projects fail so dreadfully?
Cologne, 15 July 2004
After 900 Million EURO had been spent instead of the planned 170 Million EURO for the project "Fiscus" (IT support for consistent income tax management within all German tax offices), German Finance Minister Hans Eichel threatened to cancel the overall project.
(Computer Zeitung, 14, 29 March 2004) The project "Toll Collect" of the German government also collapsed and the National job agency eventually gave up on their "virtual employment market". The list of IT projects that either had to be cancelled or consumed a multiple of the originally planned budget with an output far below the expected is getting longer and longer.
Figures and facts are staggering
The risk of failure is underestimated within software development projects, especially in the public sector. According to estimates of the German research institute Fraunhofer IESE, 30% of all projects are cancelled and never reach any project output. But not only large IT projects fail or are subject to cost explosions. According to research of the Standish Group, similar figures can be found in IT projects of small or medium size. Standish Group estimates that only 16% of all projects stay in their planned time frame and planned budget. More than 30% fail completely and 50% are facing serious problems leading to cost explosions or significant cutback of defined outputs. Overall, the defined project time lines are doubled.
Reasons for failure of IT projects
Yes, there are many reasons for the failure of IT projects. From a certain size on, project managers are well advised to break down the project into transparent and manageable sub projects, in order to reduce complexity. Project planning and project management are also stumbling blocks on the way to success. Especially the competence to trace the progress of a project in order to apply subsequent corrective measures is underdeveloped.
Requirements management - the decisive factor for success or failure of IT projects
According to the research of the Standish Group, the majority of factors leading to exceeded time lines and budgets are related to the "mismanagement of requirements". The results of the research clearly show that in more than 40% of problem situations encountered in IT projects missing management of requirements was the original source. Strikingly, it is not only under-achievement of requirements that makes software products unusable for the targeted user group, it is also the time and costs consumed for functionality that has no underlying requirements and therefore no rationale at all. I.e., design of unneeded functionality eats valuable resources and also affects the usability of the product to be delivered due to unnecessary complexity and misleading functionality.
If this is all that clear, why do projects still fail and do not employ professional requirements management?
On one hand a clear distinction between contractor and supplier is missing in many projects. Rights and duties are mixed due to lack of commonly understood practices. In most projects a clear requirements specification (to be delivered by the contractor) is missing. Instead, the design specification delivered by the contractor is based on informal discussions and lacks clear rationales in terms of non-functional requirements.
On the other hand, the contractor lacks of competence to identify requirements, to analyze them and to specify them adequately.
Looking at procedures to test software products for usability, Germany has a leading position world wide. The test procedures of the German Accreditation body for technology (DATech) specifically aim at the specification of
Of course, the DATech test procedures have been available for several years and can be used pro-actively as part of the requirements management (which forms the basis for any test). The procedures support software development projects to reach the desired quality on a structured basis. Members of staff of ProContext have further developed the original test procedures to make them applicable to analysis & design. This led to the context-scenario-method for analysis and design which unveils unknown requirements in early stages of the software development process. What's missing is the determination to apply the context-scenario-method within all IT projects.
From the contractor's perspective, the context-scenario-method offers a cost-effective tool to specify requirements from the user's perspective with regards to essential requirements before the actual implementation project starts. Furthermore contractors can apply the process requirements delivered by the "DATech test handbook for compliance testing of usability-engineering processes with ISO 13407" for assessing the supplier's capability to deliver usable software to begin with.
Furthermore, determining the requirements from the contractor's perspective right at the beginning of an IT project allows subsequent validation of all deliverables produced by the supplier. Therefore foreseeable risks are taken out of the project, presumed the requirements have been identified and analyzed in a systematic manner, as e.g. prescribed by the context-scenario-method for analysis and design.
Conclusions
If requirements management becomes commodity as part of contracting and conducting IT projects, then projects like "Fiscus", "Toll Collect", "Virtual employment market" will no longer hit the headlines of the yellow press, but significantly improve the productivity of the German public sector.
Author:
Thomas Geis
ProContext offers professional requirements engineering and comprehensive requirements management as a service within development projects for software, web ware and interactive hardware systems.
(Computer Zeitung, 14, 29 March 2004) The project "Toll Collect" of the German government also collapsed and the National job agency eventually gave up on their "virtual employment market". The list of IT projects that either had to be cancelled or consumed a multiple of the originally planned budget with an output far below the expected is getting longer and longer.
Figures and facts are staggering
The risk of failure is underestimated within software development projects, especially in the public sector. According to estimates of the German research institute Fraunhofer IESE, 30% of all projects are cancelled and never reach any project output. But not only large IT projects fail or are subject to cost explosions. According to research of the Standish Group, similar figures can be found in IT projects of small or medium size. Standish Group estimates that only 16% of all projects stay in their planned time frame and planned budget. More than 30% fail completely and 50% are facing serious problems leading to cost explosions or significant cutback of defined outputs. Overall, the defined project time lines are doubled.
Reasons for failure of IT projects
Yes, there are many reasons for the failure of IT projects. From a certain size on, project managers are well advised to break down the project into transparent and manageable sub projects, in order to reduce complexity. Project planning and project management are also stumbling blocks on the way to success. Especially the competence to trace the progress of a project in order to apply subsequent corrective measures is underdeveloped.
Requirements management - the decisive factor for success or failure of IT projects
According to the research of the Standish Group, the majority of factors leading to exceeded time lines and budgets are related to the "mismanagement of requirements". The results of the research clearly show that in more than 40% of problem situations encountered in IT projects missing management of requirements was the original source. Strikingly, it is not only under-achievement of requirements that makes software products unusable for the targeted user group, it is also the time and costs consumed for functionality that has no underlying requirements and therefore no rationale at all. I.e., design of unneeded functionality eats valuable resources and also affects the usability of the product to be delivered due to unnecessary complexity and misleading functionality.
If this is all that clear, why do projects still fail and do not employ professional requirements management?
On one hand a clear distinction between contractor and supplier is missing in many projects. Rights and duties are mixed due to lack of commonly understood practices. In most projects a clear requirements specification (to be delivered by the contractor) is missing. Instead, the design specification delivered by the contractor is based on informal discussions and lacks clear rationales in terms of non-functional requirements.
On the other hand, the contractor lacks of competence to identify requirements, to analyze them and to specify them adequately.
Looking at procedures to test software products for usability, Germany has a leading position world wide. The test procedures of the German Accreditation body for technology (DATech) specifically aim at the specification of
- non-functional requirements (especially user requirements) for the product to be developed and
- process requirements for conducting the project itself.
Of course, the DATech test procedures have been available for several years and can be used pro-actively as part of the requirements management (which forms the basis for any test). The procedures support software development projects to reach the desired quality on a structured basis. Members of staff of ProContext have further developed the original test procedures to make them applicable to analysis & design. This led to the context-scenario-method for analysis and design which unveils unknown requirements in early stages of the software development process. What's missing is the determination to apply the context-scenario-method within all IT projects.
From the contractor's perspective, the context-scenario-method offers a cost-effective tool to specify requirements from the user's perspective with regards to essential requirements before the actual implementation project starts. Furthermore contractors can apply the process requirements delivered by the "DATech test handbook for compliance testing of usability-engineering processes with ISO 13407" for assessing the supplier's capability to deliver usable software to begin with.
Furthermore, determining the requirements from the contractor's perspective right at the beginning of an IT project allows subsequent validation of all deliverables produced by the supplier. Therefore foreseeable risks are taken out of the project, presumed the requirements have been identified and analyzed in a systematic manner, as e.g. prescribed by the context-scenario-method for analysis and design.
Conclusions
If requirements management becomes commodity as part of contracting and conducting IT projects, then projects like "Fiscus", "Toll Collect", "Virtual employment market" will no longer hit the headlines of the yellow press, but significantly improve the productivity of the German public sector.
Author:
Thomas Geis
| ProContext GmbH Deutzer Freiheit 77-79 50679 Köln Germany |
|
ProContext offers professional requirements engineering and comprehensive requirements management as a service within development projects for software, web ware and interactive hardware systems.