Lifecycle & Methodology | By Anthony Lewis | minute read
With an increasing focus on the quality of project management within both public and private sector organisations, and an increasingly experienced and qualified pool of project managers to choose from, why do a significant proportion of technology based projects continue to fail?
The Context of Project Failure
There are a number of increasingly popular project management methodologies aimed at standardising project management approaches, reducing project risk, and guarding against project failure. The three main accreditations - all of which have spawned subsidiary industries in training, certification, and consultancy, are as follows:
- PRINCE2 (Projects In Controlled Environments)
- MSP (Managing Successful Programmes) both MSP and PRINCE2 originating from the Office of Government Commerce in the UK
- The Project Management Professional (PMP) certification administered by the Project Management Institute in the US
To put project failure in context; Gartner, the world's most listened to analyst firm estimate that 66% of large scale projects fail to achieve their stated business objectives, are delivered late, or are substantially over budget.
The Standish Group, which exists solely to track IT successes and failures, defines project failure as projects abandoned midstream, and estimates failure rate at 15 percent, but that "challenged" projects (defined as projects with cost overruns, time overruns, and projects not supportable as delivered) represent 51% of all IT projects.
Looking at these figures in the post PRINCE2 / MSP / PMP world, you might be forgiven for asking yourself, "why then is project success so elusive?"
The Standish Group believes that the most important factors in a project's success or failure are, in order of importance:
- The degree of user involvement
- Executive management support
- An experienced project manager
There are probably few who would disagree with the points above, which all deal with the question, "how are we going to manage this project through its active life?"
Poorly defined deliverables and scope, lack of organisational buy-in, poor resource allocation and control of risk, poor project management, components that are not fit for purpose, and so on - any and all of these can cause project failure.
But what about the failing projects that should never have seen the light of day?
First Things First
One of the "jokes" that you'll hear at least once at any project management conference is that a particular organisation's project approval process goes along the lines of ready? fire? aim, which although rather lacking in actual laughs, does illustrate a key issue - that of focusing on outcomes.
The second of Stephen Covey's famed 7 Habits of Highly Effective People is
begin with the end in mind, which is an excellent guiding principle for project management approval as it is for life: if you don't define what you want to achieve, it's very unlikely that you'll do so. In consultant-speak, this is usually couched in the question,
what does success look like?
A broad aim is fine to start with:
- We want to provide world-class services to our clients
- We want to reduce the number of outages affecting our systems
- We want to take a higher proportion of payments online
- We want to increase customer satisfaction
But these need to be much more tightly defined in terms of why, what, how, when, and who, in order to establish the capability of the organisation to deliver them, the impact on the business and probable pain level involved in change management, the likely cost implications, and a best guess at the timescales involved.
This becomes a project charter, or project brief, or in PRINCE2 terms, the Project Initiation Document (PID), which can then be realistically and robustly challenged by the potential stakeholders, refined and re-issued, so that everyone knows where they're going, how they're getting there, when they're supposed to arrive, and what the organisation will look like when the project ends.
Speaking to many of my project management colleagues, and reading the industry press, it's clear that most projects do not start with this level of definition, and poor project definition stems from what I believe is the main cause of project failure from the approval stage onwards.
An insufficient level of accountability and responsibility at an appropriately senior level for the success of a project, through its lifecycle.
Take a moment to think through the project failures you've known, and ask the following questions:
- Who was responsible for the success of the project?
- Were there any consequences for the failure of the project?
If the answers are in any way vague, it would suggest that the senior members of the organisation in question need to look seriously at the way in which projects are commissioned.
Senior people are busy people, and tend to focus attention where attention is required. If there are no consequences for project failure, of non-attendance at Project Boards, or lack of preparation for them, or if Project Board members are insufficiently senior or influential, the Board doesn't function. If there is no customer driving a project, or at least heavily engaged with it, the chances are that it will fail.
The Road Map
There is always too much pressure on organisations to take on too many projects, and senior managers as well as project staff, are always spread too thin: managing competing interests and resources is invariably a delicate balancing act.
With this in mind, the following approach will help to ensure that a project starts off on the right foot, whatever befalls it later on:
- Sit down with the organisation's project customers and hammer out an agreement on project prioritisation, based on business requirement, business risk, available resources, and so on
- Publish the list of projects and their priorities and go through another iteration of the exercise if necessary so that everyone can feel that they've had their say
- Close the projects on the bottom half of the list - if they're already low priority, you're saving time and trouble stopping them at this stage
- From the projects that remain, identify those that have strong customer (in every sense) commitment, clearly identifiable purpose, and those that can be achieved within the context of the current organisation. Cut the projects that don't - you can always revisit them later
- Agree senior owners for the projects still in the game, making it clear that they will be closely identified with the project(s) they own, will be required to drive the project forward, and will lose credibility if it fails. If a senior owner (seniority being relative to the ambition of the project) cannot be found for a project, cut it
- You should be left with a handful of projects left that are important to the organisation, with senior commitment, sufficient resources (freed from the projects that aren't going ahead) and have a high chance of success
There may be little appetite in your organisation for the effort that such a rigorous approach implies, but if you look at how much project failure has cost the organisation over the years, it's much less effort than struggling to undertake every project, then going before the Chief Exec to explain why you haven't delivered.
All content copyright End to End Consulting 2007. All rights reserved.