Project Management Methodologies
Project Management has been around for millennia. The guys that built the Pyramids, the Parthenon, all the Roman aqueducts and roads must have used some kind of methodology. The medieval cathedral builders and the Victorian engineers must also have used a methodology.
Project Management Methodologies are not such a new thing and build on a long history of practical use. A Victorian engineer, if asked what methodology he was using would reply, “I’m doing it the way it’s always been done”.
First, what is a project management methodology, and are they suitable for all environments?
Essentially, a project management methodology is a guiding set of rules, policies, and principles for planning and executing a project. Because projects and project objectives can be so different, different methods are used in different projects.
It also means that the current push to believe PMs can be used in all circumstances is wrong. The practical experience of the project area is essential. When presented with a construction problem, a PM with experience entirely in another industry would struggle.
8 Popular Project Management Methodologies And What They’re Best Suited For
To look at the various methodologies, here are some common ones, though there are other specialized variants for specific circumstances, such as Lean and Kanban.
The waterfall is one of the older methodologies, first coming to prominence in the late 1960s, and was primarily developed for use in the then-new software development environment. It is a sequential series of activities.
Its main benefit is that by concentrating on user requirements, it assists the development process and goes a long way to preventing scope creep. It is easy to understand and to use.
Its primary disadvantage is that it is very inflexible and can’t easily cope with scope changes during the development process. Going back is not allowed.
Agile was created in response to the front-loaded inflexible Waterfall methodology in the early 1970s. As projects became more complex, the inability of Waterfall to cope became more and more evident.
Simply put, Agile is the opposite of Waterfall. Where Waterfall has a heavy front loading in collecting user requirements and writing them in stone, Agile favors a more nimble iterative strategy of small incremental steps.
A significant advantage of Agile is the involvement of the stakeholder in the development process. This reduces the risk of the project going off course. The flexibility also allows for easy (sometimes) accommodation of scope changes as they occur during the project.
On the downside, incorporating scope changes can lengthen projects and make the PM’s job of balancing tasks and resources much more difficult.
A common development of the Agile philosophy is Scrum. It has been said that “Agile is the philosophy, and Scrum the methodology. While Scrum is agile, agile isn’t Scrum.”
Scrum focusses on the project team, and in some projects, the team is self-policing with no designated PM. There is a concentration on communication in the project. Each team member is expected to be aware of the overall project context and to fit their priorities into the overall project priorities.
One particular aspect is that of “sprints”. A sprint is 30 days with concise daily progress meetings called “stand-ups” in which the project team concentrates on a wishlist of small chunks of the project achievable in the 30-day window.
Advantages of Scrum are that by having sprints, immediate issues can be identified and dealt with very quickly.
The disadvantages include that it is not suitable for all projects. The collaborative team environment might not work in complex projects with large work teams, especially if they are dispersed over several locations. The absence of a specified PM makes the management of scope creep difficult and increases overall project risk.
4. Critical Path Management (CPM)
All the methodologies discussed above are primarily focused on software development projects. They can be used outside that environment, but agnostic methodologies like CPM may be better suited as an alternative.
CPM concentrates on minimizing the critical path of a project. It identifies tasks and their dependent tasks and specifically looks for tasks that can overlap.
The advantage of CPM is that it allows for better scheduling and management of project slack time.
The disadvantage is that it is for experienced PMs only. The ability to accurately assess task duration and slack is a vital part of CPM, and if the PM doesn’t have the practical experience in that field, then the PM will miscalculate. Hence the earlier comment that PM skills are generally not wholly transportable.
It is also very front heavy and does not cope easily with scope change.
5. Critical Chain Project Management (CCPM)
CCPM is similar to CPM but has a much heavier focus on resource management. It leans heavily on mono-tasking, which is resources concentrating on one task at a time and avoiding multitasking as far as is possible.
Starting from the end product, tasks are started as early as possible with minimal resource requirements, and much effort is expended on keeping resources occupied and minimizing lost productivity. It is often used in resource-scarce environments.
The main advantage is that of resource efficiency. In projects using outsourced resources, this can reduce the cost of contractors. One often-quoted other advantage is that it does not strive for the ideal solution, but by concentrating on the “good” solution is more likely to result in the project finishing on time and in the budget.
On the other hand, the use of padding and slack time to eliminate resource inefficiencies as far as possible can backfire. If a resource knows that there are five days to complete a task, they will take five days, potentially delaying the project.
CCPM is only suitable for environments where a resource works on only one project. It cannot cope with resources working on multiple projects at the same time.
6. Integrated Project Management (IPM)
All the above methodologies are not great at operating in environments where the project deliverable is not a single entity but a part of a larger delivery, for example, creation and population of a website as part of a larger marketing campaign. In short, the creative environment.
IPM is an attempt to meet that shortfall. While adopting the development process common to all methodologies, that is defining and agreeing on project scope, preparing a project plan and executing it. Supported by management and change control activities. IPM emphasizes sharing standardized processes across the organization to cope with the integrated nature of the overall project.
The advantages include that of transparency. Everyone is involved in the project, so communications are enhanced, and to much reduce the chances of changes in one area negatively affecting the project.
The downside of IPM is that it needs comprehensive planning and communications during the planning stage. This will increase the overall project timescale.
What can we say about PMBoK? It has become the yardstick for measurement in the PM landscape. However, it’s not really a methodology, though most people think it is. It is more a compilation of the various elements of the PM landscape under one roof. It hosts standards, terminologies, best practices, and guidelines for effective Project Management.
So, it is usually applied in combination with one of the other methodologies to provide the framework for their operation.
Some elements, Risk Management, and Communications management, for example, can be applied as they stand from PMBoK to make up the full PM environment. In short, it is a template for a PM to develop the methodology best suited to the particular circumstances of the project they are facing.
8. Prince 2
Finally, we come to Prince2, developed by the UK government as a standard for project management in the Public Sector. It is mandatory in several areas of government in the UK.
Prince 2 is similar to PMBoK but has a greater focus on the doing bit of PM. It is built around 7 themes, 7 principles, and 7 processes, allowing the PM flexibility in defining the project environment and managing the project as it proceeds.
Apart from the obvious advantage of certification in Prince 2 being a great advantage in working as a PM in UK government projects, it has “Learn by Experience” as one of its 7 principles. Using Prince 2 will ensure that a growing PM learns on the project.
The downside is that, as with most government activity, it is hidebound by documentation.
This list is not comprehensive by any means but hopefully highlights the more common PM methodologies. Other methodologies like Six Sigma, Crystal, Feature Driven Development (FDD), Dynamic Systems Development (DSDM), Rational Unified Process (RUP), Kanban, and Lean Development (LD) are used, but as in the case of Six Sigma, more often as a part of a broader consultancy methodology.
What you choose depends upon several things, the environment in which you will be working, the type of project and it’s complexity.
Beware though there are fads and flavors of the month in PM methodologies. Project management methodologies are merely tools to assist with delivering projects. We should be focusing on the bigger picture – delivery and not on the often irrelevant details of one methodology over another.