Projects can fail at the very start of their journey to implementation, right at the end, or anywhere in between. Not all troubled projects fail, but all failed projects were troubled projects. Troubled projects include some 'crunch mode' projects and all 'death march' and 'runaway projects' to use terms prominent in the literature. A project life cycle of six stages has been defined: project conception; project initiation/mobilisation; system design; system development; system implementation; system operation, benefit delivery, stewardship & disposal.

There are a number of sources of information on the root causes of troubled projects. These include some notable books on the subject of software risk management, surveys of troubled or 'runaway' projects conducted by management consultants, reports prepared by government accounting watchdogs and internal studies conducted by IT services companies. Root causes which can affect a project during the Project Conception and Project Initiation/Mobilisation stages can be detected during the planning or bid stage of a project. Guidance on how to achieve this is given in Part 2 of this book. If the vendor and the buyer fail to agree that one or more of these root causes is threatening the success of the project and that something needs to be done about it, the vendor can always walk away from the business. Sometimes this brave step does need to be taken. Root causes which can affect a project during the System Design and System Development stages can be detected during project delivery reviews, enabling corrective action to be planned and executed. Guidance on how to achieve this is given in Part 3 of this book. Root causes which can affect a project during the System Implementation and System Operation, Benefit Delivery, Stewardship and Disposal stages can be detected if ongoing project reviews are undertaken throughout the life of the project/system.

There are several high-profile IT projects in recent history which would be excel lent candidates for analysis in this chapter. These include the UK Passport Agency system replacement project, the Denver International Airport baggage handling system, and the Taurus project for the UK Stock Exchange. However, it would be hard to present an account and analysis of one of these projects without causing potential dissent and strong emotions in the community of the project participants, many of whom are still active in the industry. Taking a project example from another industry such as the Channel Tunnel or the Millennium Dome would not solve this issue. For this reason, I have chosen a historic project from a time well before the invention of the computer (with apologies to Charles Babbage who conceived his Analytic Engine in 1834 but did not live to see it realised). This example clearly illustrates that the same generic root causes which beset IT projects are equally troubling to other types of project.

An effective quality assurance (QA) function can detect many but not all of the potential root causes. But leaving QA to detect the issues and risks of a bid is an indictment of the professionalism of your business. It is everyone's responsibility to de-risk a project. The vendor should discuss buyer-induced root causes with the potential buyer and suggest ways of de-risking the project. Strategies might include: for a 'full scope' development, breaking the project into a number of phases, starting with a requirements definition phase; phasing delivery of a complex project to provide a number of software 'drops'. This provides usable functionality early and early proof of project viability; the concept of a 'pilot' or 'proof of concept demonstrator' to enable requirements to be honed or infrastructure to be proved before more substantial in vestment is made. 24 out of the 40 root causes of troubled projects can be detected and prevented at the bid stage, given a professional approach by all in the business. A strong and independent QA function can detect most but not all of these. The sales pipeline is a leaky one. Your sales people need to work hard at lead generation and opportunity generation to provide sufficient new business op portunities for your business to grow. You can't afford to rely solely on follow-on business. Good qualification of the potential opportunities increases your conversion rate and filters out many potentially troubled projects.

Qualification is not an exact science. It is a crucial process for filtering out potential troubled projects and increasing your conversion rate. Qualification is a formal business process in which all functions of your business must participate. Be honest with yourself: when qualifying an opportunity, a lost bid costs the same as a winning one. Play to win the opportunities you select.

This chapter shows the process of engaging a potential buyer in a business. The first stage is to establish the opportunity owner. The second stage is to form a bid team. The third stage is to understand the opportunity in detail. The fourth stage is to prepare an initial risk management plan. The fifth stage is to have a buyer meeting. The final stage is to de-brief and review the bids.

I once led a study to define a strategic LAN architecture for a whole government department. The Invitation to Tender (ITT) was clear about what was required. Divisions within the department were purchasing a variety of LANs from different suppliers and the IT Division felt that a strategy was needed to prevent the proliferation of LAN products from getting out of hand. The LAN architecture had to be compliant with UK Government Open Systems Interconnection Policy (GOSIP), which was attempting to promote open, rather than proprietary, protocols. This was in the days when TCP/IP was labelled 'proprietary'and was to be avoided at all costs by the purists. We found out which LANs were currently in use in the Department and what they were used for. We found that it was possible to define a range of typical LAN configurations for different types of workgroups. We then evaluated products to establish the degree of compliance with GOSIP requirements. This narrowed the field down substantially basically to one product, and a new one at that. Following the brief, we prepared a recommendation, submitted the report and waited for the accolades to roll in. They didn't arrive. The customer was unhappy with the recommendation. One large division, which had invested heavily in Novell networks, was very unhappy about the prospect of moving to a new 'strategic' network which did not offer many of the features of their existing network. It turned out that users were not prepared to sacrifice usability and functionality on the altar of Open Systems Interconnection (OSI) purity. Whose fault was this? It was mine! The fact that there was a basic disconnect between the demands of the GOSIP policy and the real day-to-day needs of users was a problem that I should have realised and discussed with my client. This was not my natural style. I did all the thinking and the client followed my recommendations. This was the way it was done and it had always worked. It was not until I joined a management consulting firm later in my career that I learned the value of the 'workshop' approach in securing the buy-in of the client every single step of the way.

This chapter discusses RC13. It defines project tasks, deliverables and acceptance processes. Regardless of whether a project is contracted on a fixed price or a T&M basis, handling the task of project scoping and planning by means of workshops with the client after the contract has been signed is commercial hara-kiri.

Vendor underestimation of the effort required to deliver a project is probably the most common of all the root causes of troubled projects. Activity-based software project cost estimation is the only approach that is sufficiently 'industrial strength' to be used as a basis for contract. Software sizing professionals are an essential part of a vendor's capability, providing valuable software sizing and estimating support to bid teams. Automated cost estimating tools provide more consistent estimates, more easily, than can be achieved manually. They are very valuable toprovide an early sizing of a software project, to support a detailed activity-based estimate, and to provide a 'sanity check' on manual activity-based estimates. The more effective your software development processes or the higher the level of the Capability Maturity Model your organisation has reached the more competitive you will be in the marketplace and the more accurate your estimates will be. Process improvement programmes to move from Level 1 to Level 3 are costly, but there is a substantial and ongoing return on this investment.

Quality plans and risk management plans must result in project tasks to be actioned, tracked and managed to completion, otherwise the vendor's quality plans and risk management plans are simply shelfware. One of the biggest causes of troubled projects is vendor over-confidence in their abilities. A vital role of an independent QA organisation is to detect this problem and ensure that plans are realistic and achievable. Quality is delivered through: specifying quality requirements in tangible, real-world terms; defining and using appropriate software development processes; controlling quality through the use of appropriate V&V processes; independent QA reviews to ensure that quality attainment plans and quality control plans are being executed; defining and using appropriate processes to preserve quality throughout the life of the software. All of the above are defined in the quality plan, a crucial input to project estimation and planning. The goal of risk management is to reduce project overspend and slippage, and thereby to maximise quality. Risks must be identified and analysed to determine their probability and impact. Risk reduction actions can then be defined to re engineer the risk profile. What is left is the residual risk. Residual risk can be examined using best, likely and worst case scenarios, and appropriate contingency strategies and plans defined. Automated statistical tools can indicate the residual risk contingency which should be set aside to provide the desired confidence level that the contingency will not be exceeded.

Proposals must be focused on the potential buyer and on how solution will help them to meet their business challenges. The focus must not be on the vendor and his superior capabilities. The proposal should be to convince the buyer.

The key objective of project delivery reviews is to provide ongoing project health assessment, enabling problems to be detected early, before the project becomes troubled. Clear and crisp findings and recommendations are required. Reviewers must be experienced, senior people who are independent of, and respected by, the project team. Reports must be visible to senior management in the vendor organisation. A set of 'focus areas' has been presented which will enable us to detect the majority of the root causes of troubled projects during the system design and system development life cycle stages.

This chapter is about review planning and preparation of a project. This chapter discusses two types of project delivery review: the project health check review and the troubleshooting review.

This chapter presents some hints and tips on how to conduct troubleshooting reviews and project health check reviews, and how to prepare the review report or presentation as efficiently as possible.

Fundamental to the success of an application development and systems integration project is the existence of a stable set of detailed system requirements. For this reason, full-scope, fixed-price projects are risky. The 'pecking order' of requirements documents must be defined to provide both Buyer and Vendor with clarity on what functionality will be delivered. Non functional requirements are an essential prerequisite of infrastructure design. RAD projects require tight management to avoid 'galloping elegance'. Also key to the success of an application development and systems integration project is the correct choice of technical platform or architecture. The next key requirement is that the design should be documented, 'frozen' as a baseline for the development, and subject to change management.

The most common reason why project plans are unrealistic is that they are based on unrealistic estimates. Often the vendor is influenced by the buyer's timescale and budget expectations and, as root cause RC05 tells us, the buyer's funding and/or timescale expectations can be unrealistically low. Once poor estimates are enshrined in a plan which has been presented to the buyer, a troubled project is more or less inevitable. All projects require a master project plan, prepared using an appropriate project planning and scheduling tool. The master project plan should be constructed at activity level. A plan constructed at a very detailed level cannot be maintained by one person and the plan rapidly becomes out of date. Separate low-level plans must be prepared for each area of project activity. These should be constructed at the task level and used to control progress. It is vital to establish whether the plans are being used to control the project. It is also important to establish whether the team members regard the plans as realistic and achievable.

The chapter discusses the quality plan. Good communication between subteams is essential. Team members should have access to sufficient development and test hardware and software to enable them to achieve high productivity. Work products should be inspected by peers and team leaders. The project team should have a clear, preferably documented, view on how the individual software components of the system will be integrated and tested. System testing should include both functional and non-functional testing. The quality plan must define the quality requirements of the system.

It is counterproductive to deploy a team substantially larger that the 'natural' size for a project in an attempt to compress the project timescale. The team structure should be documented and should suit the approach being taken to project delivery. An experienced software development manager or team leader is key to success. New joiners and less experienced staff require substantial supervision and coaching from their team leaders. There should be a single responsible owner of the project within the buyer organisation.

This chapter discusses the project management system, including project planning, resourcing, progress monitoring, contract management, financial management and buyer relationship management.

The most popular troubled project remedies in the literature are 'more time', 'more people', and 'more money'. Another remedy in widespread use is the motivation of the team to work harder and even longer hours of (generally unpaid) overtime. These remedies are not particularly effective. Recent UK Government reports, focusing on the reasons why projects be come troubled, correctly stress the value of modular and incremental approaches to development and the importance of a co-operative and open relationship be tween the buyer and the vendor. These considerations point the way to an approach to the development of a successful turnaround strategy it requires buyer and vendor teams to engage in an open, honest and collaborative manner, to consider how the project can be reshaped. This often means delivering less functionality, but delivering it earlier.

In this chapter, we briefly consider how complex we are as individuals and how this complexity can affect the way we learn as individuals. We note how important it is to develop 'soft skills' in addition to the normal competencies associated with our work. We discuss how groups can learn and how the learning of a transitory group like a project team can be lost at the end of the project. Other, more permanent groups or communities provide a means of promulgating learning opportunities. We look at how organisations can learn and propose a definition based on the detection of map mismatch. To learn, an organisation must be prepared to bring projects into line with its map. It must also be prepared to change its organisational map when this is indicated.

The following topics are dealt with: IT project design; project management and supplier relationships.