• Research »
• CIO 100
  • White Papers
  • Tech Tool Kits
  • Analysis

Let us start with some uncomfortable truths about IT projects; at a conservative estimate, 13 per cent fail to meet any of the objectives set by IT or business management, while 40 per cent fail to deliver the agreed Return on Investment.

At least half of project failures can be directly attributed to inadequate requirements gathering, definition and agreement.

The 2004 report "The Challenges of Complex IT Projects" from The Royal Academy of Engineering and The British Computer Society backs this up:

"Requirements definition is one of the most critical, and most challenging, stages of the project. Many projects fail due to flaws in the elucidation of requirements."

There are two fundamental reasons for this. Firstly, IT systems requirements are complex - they need to address the needs of different stakeholders. Secondly, software is inherently intangible, making it difficult to determine what exactly is going to be delivered. It is the combination of these two factors which make requirements definition so much harder for IT projects than for other types of engineering endeavour. And if requirements are not well defined, then IT systems are not properly specified leading, in turn, to projects being under-estimated and under-resourced.

For example, the warehouse holding spare parts for a commercial vehicle distributor will have a clear set of requirements understood by the various stakeholders. However, financial controllers, customer service agents and distribution personnel may have different views of what the inventory, sales order processing and logistics systems within the warehouse should provide. While it would be relatively unusual for a warehouse to be delivered late and over budget, the same cannot be said for the IT systems within it.

One proven approach to address this problem is visualisation. On projects in North America, Capgemini has seen the application of visualisation reduce time spent defining requirements by 50 per cent, the number of requirements-related defects in acceptance testing reduce by up to 80 per cent, and perhaps most tellingly, a reduction in system support calls of over 50 per cent.

Visualisation can be used effectively just about anywhere in the system delivery life-cycle, from the initial stages when the project vision is being established, through to the point at which deployment, and any resultant business change, is being planned and managed.

Visualisation can help determine the business processes during the initial feasibility and Visioning stage. It can be used to help select the appropriate product where a package implementation is required; and if a package approach is not suitable, it can help define what form a custom development might take.

During the Inception stage (terms will vary depending on the type of delivery life-cycle) visualisation helps establish the manner in which systems will support the business processes. Simulations of the systems are used to confirm requirements, achieve buy-in from key stakeholders, support detailed planning of subsequent phases and the refinement of estimates.

During Elaboration (or Detailed Design or Blueprint depending on lifecycle), precise simulations of system user interfaces can be produced to confirm "look and feel". During Construction (or Build or Realisation) simulations are used to provide unambiguous specifications for development teams, reducing the need for re-coding and re-testing; this is especially useful when development is offshore.

Finally, simulations are also used to specify test cases, facilitate and accelerate user acceptance, understand business change implications, and design and accelerate end-user training.

Although the benefits of visualisation are obvious, there are a number of pitfalls to be avoided, and it is important that visualisation is carried out in a tightly managed manner.