What defines a “successful” project? The Standish report says it is “being completed on time and budget, with all the promised functionality”. In 2015, shockingly only 29% of the 50,000 projects analysed achieved these objectives. The remaining 71% (yes, 71%) either failed to deliver in at least one objective or were cancelled or abandoned.
What characterised the successful projects? Standish found these five common “success factors”:
- Realistic expectations
- Proper planning
- Clear statement of requirements
- Executive management support
- User involvement
Conversely, what characterised the failed projects? Standish quotes these, not-quite mirror image, “failure factors”:
- Technical incompetence
- Lack of executive support
- Changing requirements and specifications
- Incomplete requirements and specifications
- Lack of user input
Here we examine several different project management methodologies and consider how they support the project manager in delivering the ”success factors” and avoiding the “failure factors”.
What is a project management methodology?
Searose Project Management advise that the project manager uses a set of processes and guiding principles to run and deliver the project. These are collectively known as a project management methodology (PMM). Several different methodologies have evolved over time, some being specific to a particular industry or type of project (e.g. Agile) and others being more generally applicable (such as PRINCE2).
Waterfall
Waterfall was defined in 1970 in order to manage software development projects. It is completely sequential and heavily focused on documentation. The project begins by gathering requirements and proceeds through analysis, design, implementation, testing, deployment and maintenance.
Waterfall can work successfully where the project is small or simple, or where the requirements are clear and fixed. Each stage has to be fully thought through, which improves documentation quality but makes it difficult to go back. Changing requirements or incorrect assumptions can prove expensive.
Agile
Agile was defined in 2001, largely in response to the problems encountered in Waterfall projects. It is an iterative process, delivering working software quickly. Stakeholders can see and comment on features early in the project, giving them an opportunity to firm up or change requirements. Developers have the flexibility to experiment and the product grows through small incremental changes.
Agile’s flexibility is also its drawback. There is no fixed plan as such, making resource planning more of a challenge. It’s difficult to plan towards a fixed end date which is frustrating to senior management and customer-facing teams such as sales.
In terms of the “failure factors” Agile comes with risks around changing or incomplete requirements and specifications. It also puts a high dependency on the technical competence of the team and on support from senior levels in the business.
Critical Path Method (CPM)
In the Critical Path Method, all activities required to deliver the project are captured in a Work Breakdown Structure (WBS). The WBS is elaborated to break the activities into tasks, each with its own dependencies, duration and, possibly, resource. A scheduling tool is used to lay out the project based upon the activities that can proceed simultaneously. The critical path is the longest sequence of activities and so dictates the earliest point at which the project can be completed.
CPM is highly suited to projects with many interdependent tasks and resources. It is valuable for industrial projects with repetitive activities but requires detailed analysis of the whole work breakdown. This makes it unsuitable for projects where requirements and specifications are unclear.
CPM is a technique rather than a methodology; it demands a high degree of technical competence in scheduling the project and does not provide any guiding principles to counter the other “failure factors”
PMBOK
The Project Management Institute (PMI) identifies the key processes and knowledge areas used in defining and running a project. This is not a prescriptive methodology as such, but rather a generic framework for a project.
PRINCE2
The PRINCE2 methodology was initially developed as a UK government standard but since 2013 has been managed by AXELOS. It has been used to deliver successful projects in different industries worldwide. It can handle small, medium and complex projects.
It defines a set of principles, themes and processes for running a project. These provide a robust structure to keep the project on track and increase its chances of success. Using PRINCE2 reduces the risk of “failure factors” as follows:
- PRINCE2 Foundation training is available for project staff, while project managers can achieve certification as PRINCE2 Practitioners. By using trained and qualified staff, an organisation can ensure the technical competence of the project team.
- PRINCE2 requires roles and responsibilities to be defined and agreed. This brings executive support through the project sponsor and project board, as well as setting the terms of reference for stakeholder input, for example in reviewing technical documentation.
Summary
Choosing the right methodology is a key factor, perhaps the key factor, in improving a project’s chances of success. While Waterfall and more recently Agile have made their mark in software development, PRINCE2 remains indispensable for many different types of project, both software and industrial.
The project management methodology you opt for will depend on the nature of your project and what your lead PM has a background in. Whatever approach you go for, it pays to have an understanding of the options available.