TMCnet News
Visualise your IT systems vision; Dave Pepperell, CTO & Vice President for Innovation, Capgemini UK , discusses about having clearer visualisations in order to meet the objectives.(M2 PressWIRE Via Acquire Media NewsEdge) [This article appears in full at CIO.uk ] Let us start with some uncomfortable truths about IT projects, says Dave ; at a conservative estimate, 13% fail to meet any of the objectives set by IT or business management, while 40% 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%, the number of requirements related defects in acceptance testing reduce by up to 80%, and perhaps most tellingly, a reduction in system support calls of over 50%. 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. Firstly, and most importantly, move quickly. Identify the key objectives for each stage and don't over-deliver. This means that at the Visioning stage, don't spend time on system functionality - the purpose is to confirm the business processes. Similarly, during Definition, focus on confirming system functionality - 'look and feel' can come later. As part of the focus on speed, produce visualisation deliverables early and often. The more opportunity that stakeholders have to provide feedback, the more likely it is that the system will meet the requirements. To quote M. Lunt in the 2004 report 'Humans are very poor at saying precisely what they do want and extraordinarily talented at recognising what they don't want'. Apply design principles to the visualisation process. Consider the principles of user interface design, as well as compliance with accessibility legislation, and consult the real users of the system. It is also essential that the functionality and user interfaces being defined are validated by technical experts who understand the platform on which the system will eventually be delivered. As well as using the right process, ensure that you are using the right tools. Tools need to be selected which can effectively simulate user interfaces in the technology most likely to be adopted; this can mean imitating data flows through the system. Functionality can be simulated using the technology which will be used to support the end system, provided that the key principle of speed can be observed without comprising the stability of the production deliverables. Finally, use the right people - as well as business users, business analysts, technical architects and user-centric designers will all be needed to conduct an effective visualisation exercise. IT departments can effectively deliver timely, cost-effective solutions which meet the needs of the business if they use visualisation to confirm requirements. When visualisation is implemented rapidly and using design principles, one of the most intractable problems affecting IT delivery can be addressed. ((Comments on this story may be sent to [email protected])) (c) 2009 M2 COMMUNICATIONS |