SBA

Project Failures - I blame PRINCE !

In June the BCS published research work by Dr John McManus and Dr Trevor Wood-Harper into the nature and causes of IT Project Failure, failure being described as those projects that do not meet the original time, cost and (quality) requirements criteria.

Ultimately the authors attribute the major cause of project failure to inadequate pre-project due diligence - poor determination of requirements and poor design. This will come as no surprise to any student of IT projects. The major causes of IT project failure can be summarised as insufficient support from the business,  changes to the business requirements during the project, and under-estimate of project cost. All three are rife in IT projects and have well known causes:

Insufficient support from the business: a common problem when IT have sold new wizardry to the business but failed to engage the business to desire the new system / product with deep conviction, also common when an external player (CxO, board level consultant) has sold senior management on the need for new system and process without engaging the middle management and prospective users to the benefits the new system will provide, and less commonly when a business department under criticism has responded "we need a new system to do better" but has not been engaged into the imperative need to do better. Any of these will result in the eventual users being insufficiently engaged to the design process so that an insufficiently sound requirements specification is generated, dooming the project to failure before the first line of code has been written.

Changes to the business requirements during the project: most common when the project is commissioned by business management without understanding the processes that their people actually execute - with the result that part way through the project, when engaging with the eventual users of the system, additional requirements are revealed requiring additional or changed functionality. Also caused by poor quality business analysis within the (IT) development team.

Under-estimate of project cost:  either through blind optimism, incompetence, desperation to secure project funding and the jobs that go with it, or pressure by (IT or Business) management to reduce the "bid price", the cost of the project as presented to the commissioning authority is the minimum theoretical cost, totally unrealistic except with perfect conditions and a following wind.

Irrespective of how these problems are presented, and where in the project lifecycle the problems start to be exposed, they are all caused by insufficient pre-project preparation. To execute a project successfully, which is to say deliver a project within its QCDs (Quality, Cost & Delivery parameters), requires significant pre-project effort. It cannot be taken as given that business managers either want the project to happen, or know what functionality (quality) the project should deliver, and without strenuous verification of both there is a significant risk of failure. It can be taken as given that the project manager will be subject to high-level pressure on costs, and weaker project managers will succumb to this pressure - whether the project manager or the senior management inflicting the pressure are relatively more or less guilty is moot.

In short - project failures are almost entirely predictable before a project gets underway. Strong project managers will reliably deliver more successful projects than weak managers. The strongest will walk away from unsound projects before they start. On a personal note, I commonly refuse to provide budget and timescale commitments for projects when I believe the requirements are unsound or the functionality is not properly understood - after all, why should I risk being labeled a failure because another manager or director doesn't understand how his business actually functions? I have delivered many projects within their agreed Quality, Cost and Delivery parameters, but I am never going to commit to deliver a project within a determined timescale and budget if I don't believe the scope is as presented. I am sometimes unpopular for this, but if the business managers commissioning the project are so uncommited that they cannot engage their people to define the scope of requirements, why should any project manager commit themself to predictable failure?

Delivery of a project is a joint effort - both the Business and the Development Team must be fully committed - neither can be a passenger claiming that the other half is driving. Too often we see projects where the Business managers take the view that they have passed the project to IT, and it is now their responsibility, or where IT deliver the project exactly as specified by the Business, knowing that the specification is inadequate leaving gaping holes in the fuctionality that will actually be required. So "IT Project Failure" is a misnomer - it is Management Failure - Business Management and IT Management are jointly responsible. The lessons are fairly simple to learn - successful projects require strong, diligent management on both sides - IT and Business, and 100% commitment to success on both sides, if either side shirks or passes their responsibility to the other the project is probably doomed.

In mitigation, the original UK government endorsed project management methodology - PRINCE - did not even consider the pre-project phases where success or failure is pre-determined, and the reworked version - PRINCE 2 - only sets out a very lightweight level of pre-project activity, so many (most?) qualified Project Managers in the UK have never been formally educated in the criticality of the pre-project phases. Some of the proprietary Project Management methodologies employed in the major US based multinational corporates address the start-up phases very well, but these sit uneasily in a UK project management culture that is dominated by PRINCE.