What are project management methodologies? A project management methodology is essentially a set of guiding principles and processes for managing a project. Your choice of methodology defines how you work and communicate.
So how do you choose a project management methodology?
What methodology you choose will depend on your team, project-type, and project-scope. Choosing project management methodologies (PMM) is one of the first decisions you’ll have to make as a project manager. What methodology you pick will have a profound and ongoing impact on how you and your team works. Different project management methodologies have their own pros and cons for different project types. Some are geared for speed, some for comprehensiveness.
In this article, I’ll give you a complete overview of different PMMs and how to choose them.
Types of Project Management Methodologies
On paper, PM methodologies are tool agnostic, i.e. you should be able to use any methodology regardless of what PM tool you use.
In reality, most project management tools are specialized to use a handful of methodologies. This will be a factor in what methodology you eventually choose to use.
The question now is: what are the different types of PMMs? What are their advantages and disadvantages? What kind of projects are they best suited for?
Below, I’ll take a look at 9 of the most popular project management methodologies.
The Waterfall methodology is the oldest methodology on this list. It was first outlined by Dr. Winston Royce in 1970 as a response to managing the increasingly complex nature of software development. Since then, it has become widely adopted, most prominently in the software industry.
The Waterfall methodology is sequential. It is also heavily requirements-focused. You need to have a crystal clear idea of what the project demands before proceeding further. There is no scope for correction once the project is underway.
The Waterfall method is divided into discrete stages. You start by collecting and analyzing requirements, designing the solution (and your approach), implementing the solution and fixing issues, if any.
Each stage in this process is self-contained; you wrap up one stage before moving onto another.
Graphically, you can represent it as follows:
The above is from a software development perspective. Individual stages would be different for creative project management, but the approach remains the same.
As Mike Wang, our Director of Training and Support, mentioned earlier:
“One of the driving factors behind waterfall management is that by investing time in the early stages of a project, managers ensure design needs and other requirements have been met—thus saving the time and effort generally associated with retroactively correcting problems”
Thus, the Waterfall method has several advantages, such as:
- Ease of use: This model is easy to understand and use. The division between stages is intuitive and easy to grasp regardless of prior experience.
- Structure: The rigidity of the Waterfall method is a liability, but can also be a strength. The clear demarcation between stages helps organize and divide work. Since you can't go back, you have to be "perfect" in each stage, which often produces better results.
- Documentation: The sharp focus on gathering and understanding requirements makes the Waterfall model heavily reliant on documentation. This makes it easy for new resources to move in and work on the project when needed.
- Higher risk: The rigidity of this methodology means that if you find an error or need to change something, you have to essentially start the project from the beginning. This substantially increases the risk of project failure.
- Front-heavy: The entire Waterfall approach depends heavily on your understanding and analyzing requirements correctly. Should you fail to do that - or should the requirements change - you have to start over. This lack of flexibility makes it a poor choice for long and complex projects.
The Waterfall methodology is most commonly used in software development. It works best for the following project types:
- Short, simple projects
- Projects with clear and fixed requirements
- Projects with changing resources that depend on in-depth documentation
Agile, another software development-focused PM methodology, emerged as a response to the failure of Waterfall method for managing complex projects. Although Agile PM ideas had been in use in the software industry for quite a while, it formally came into being in 2001 when several IT representatives released the "Agile Manifesto"
In approach and ideology, Agile is the opposite of the Waterfall method. As the name implies, this method favors a fast and flexible approach. There is no top-heavy requirements-gathering. Rather, it is iterative with small incremental changes that respond to changing requirements.
Graphically, it can be represented as follows:
- Flexibility and freedom: Since there are no fixed stages or focus on requirements, it gives your resources much more freedom to experiment and make incremental changes. This makes it particularly well-suited for creative projects.
- Lower risk: With Agile management, you get regular feedback from stakeholders and make changes accordingly. This drastically reduces the risk of project failure since the stakeholders are involved at every step.
- No fixed plan: The Agile approach emphasizes responding to changes as they occur. This lack of any fixed plan makes resource management and scheduling harder. You will constantly have to juggle resources, bringing them on/off on an ad-hoc basis.
- Collaboration-heavy: The lack of a fixed plan means all involved departments - including stakeholders and sponsors - will have to work closely to deliver results. The feedback-focused approach also means that stakeholders have to be willing (and available) to offer feedback quickly.
The flexibility of the Agile approach means that you can adapt it to different types of projects.
That said, this methodology works best for:
- When you don't have a fixed end in mind but have a general idea of a product.
- When the project needs to accommodate quick changes.
- If collaboration and communication are your key strengths (and planning isn't)
The Hybrid approach, as the name implies, is a combination of the Waterfall and Agile methodologies. It takes the best parts of both Waterfall and Agile and combines them in a flexible yet structured approach that can be used across different projects.
The Hybrid methodology focuses on gathering and analyzing requirements initially - a nod to the Waterfall method. From thereon, it takes the flexibility of Agile approach with an emphasis on rapid iterations.
By combining attributes of Waterfall and Agile, the Hybrid method (sometimes called "Structured Agile") gives you the best of both worlds.
- Increased flexibility: Past the planning stage, the Hybrid method affords you significantly increased flexibility when compared to the Waterfall method. As long as the requirements don't change substantially, you can make changes as they're requested.
- More structured: By borrowing the initial planning phase from Waterfall, the Hybrid method addresses one of the biggest complaints about the Agile approach - lack of structure and planning. Hence, you get the "best of both worlds".
- Requires compromise: Since you're essentially reconciling two polar opposite approaches, both sides will need to compromise on requirements and flexibility.
- "Best of both worlds" approach robs you of the flexibility of Agile and the surefootedness of Waterfall. Any iterations you make will have to comply with the budgeting and scheduling constraints set up front.
The Hybrid approach is best-suited for projects that have middling requirements when compared to Agile and Waterfall, i.e. they require structure as well as flexibility.
Mostly, this would be medium-sized projects with moderately high complexity but fixed budgets. You would likely have an idea of the end product but you are also open to experimentation. You will need close collaboration, especially past the planning stage.
Scrum isn't a fully-featured project management methodology. Rather, it describes an approach to Agile management with a focus on project teams, short "sprints" and daily stand-up meetings.
While it borrows the principles and processes from Agile, Scrum has its own specific methods and tactics for dealing with project management. As Mike put it earlier:
The Scrum approach places the project team front and center of the project. Often, there is no project manager. Instead, the team is expected to be self-organizing and self-managing. This makes it ideal for highly focused and skilled teams, but not so much for others.
- Scrum "sprints": The Scrum approach is heavily focused on 30-day "sprints". This is where the project team breaks down a wishlist of end-goals into small chunks, then works on them in 30-day sessions with daily stand-up meetings. This makes it easy to manage large and complex projects.
- Fast paced: The "sprint" approach with its 30-day limit and daily stand-up meetings promotes rapid iteration and development.
- Team-focused: Since the project team is expected to manage itself, Scrum teams have clear visibility into the project. It also means that project leaders can set their own priorities as per their own knowledge of their capabilities.
Besides these, it has all the benefits of Agile - rapid iteration and regular stakeholder feedback.
- Scope creep: Since there is no fixed end-date, nor a project manager for scheduling and budgeting, Scrum can easily lead to scope creep.
- Higher risk: Since the project team is self-managing, there is a higher risk of failure unless the team is highly disciplined and motivated. If the team doesn't have enough experience, Scrum has a very high chance of failure.
- Lack of flexibility: The project-team focus means that any resource leaving the team in-between will hugely impact the net results. This approach is also not flexible enough for large teams.
The Scrum approach is best for highly experienced, disciplined and motivated project teams who can set their own priorities and understand project requirements clearly. It has all the flaws of Agile along with all its benefits. It works for large projects, but fails if the project team itself is very large.
In short: use Scrum if you're developing complex software and have an experienced team at your disposal.
5. Critical Path Method (CPM)
The above four project management methodologies emerged from software development. While you can certainly use them for non-software projects, there are better alternatives at your disposal.
One of the more popular alternatives is the Critical Path Method (CPM).
In the Critical Path Method, you categorize all activities needed to complete the project within a work breakdown structure. Then you map the projected duration of each activity and the dependencies between them.
This helps you map out activities that can be completed simultaneously, and what activities should be completed before others can start.
- Better scheduling: The emphasis on mapping the duration of activities and their interdependencies help you schedule tasks better. If task X depends on task Y to be finished first, CPM will help you identify and schedule for it.
- Prioritization: The success of the CPM methodology depends on identifying and mapping critical and non-critical activities. Once you've mapped these activities, you can prioritize resources better.
- Scheduling requires experience: As any experienced project manager will tell you, things always take more time than you expect. If you don't have real-world experience with scheduling, you are bound to miscalculate time for each activity.
- No flexibility: Like the Waterfall method, CPM is front-heavy. You need to plan everything out at the very start. If there are any changes, it makes the entire schedule irrelevant. This makes this method unsuitable for projects with changing requirements.
The Critical Path Method is best-suited for projects with interdependent parts. If you require tasks to be completed simultaneously, or for one task to end before another can begin, you'll want to use this methodology.
CPM finds a lot of application in complex, but repetitive activities such as industrial projects. It is less suited for a dynamic area such as creative project management.
6. Critical Chain Project Management (CCPM)
Critical Chain PM is one of the newer project management methodologies out there. It was developed as an alternative to the Critical Path method with a focus on resource management.
With CCPM, you work backward from the end goal. You recognize the deliverables, then use past experience to map out the tasks required to complete the project. You also map out the interdependencies between resources and allocate them accordingly to each task.
This graph from TrackerSuite shows the difference between a traditional vs. a CCPM project schedule.
CCPM emphasizes resource utilization and minimizing lost productivity. It is heavily reliant on "monotasking", i.e. focusing on the task at hand and avoiding multitasking.
For resource-strapped project teams, CCPM can be a powerful methodology.
- Resource-efficient: The entire focus on proper resource management makes CCPM one of the most resource-efficient project management methodologies around. The emphasis on monotasking is also well-aligned with our modern understanding of the detrimental effects of multitasking.
- Focused on end goal: CCPM doesn't obsess over the "optimum" solution to a problem. Instead, it prioritizes "good enough" solutions that can help meet the end-goal. Since you also work backward from the end-goal, CCPM usually yields better results for complex projects.
- Not appropriate for multi-project environments: CCPM's resource-focused approach can only work in single-project environments. In multi-project environments, projects might share resources. CCPM can't plan for resource distribution in such a scenario.
- Delays common: CCPM allots a gap or padding between tasks to derive a task time length. In theory, this is supposed to make up for resources overestimating their own efficiency. In reality, resources, following Parkinson's Law, fill up the padding with inordinate delays.
CCPM works best in environments where resources are devoted to a single project. If you have a dedicated team for a project, it works great. If your team is spread across several projects, you'll struggle with resource planning.
The resource-focused approach of CCPM is also ideal for resource-strapped project teams. If you find yourself constantly overworked or missing deadlines, the CCPM methodology might be for you.
7. Integrated Project Management (IPM)
Integrated Project Management (IPM) - sometimes also called "Integrated Project Delivery" - is a common project management methodology in creative industries. This methodology emphasizes sharing and standardization of processes across the organization.
The IPM approach came about as a response to the increasingly integrated nature of creative campaigns. You don't just produce a single ad; you integrate the ad with microsites, digital content, etc. Most creative projects are a piece of a larger campaign.
An integrated project has the following components:
By integrating processes across the organization, IPM gives project managers better insight into the project and access to the right resources.
This makes IPM particularly appropriate for creative agencies.
- Transparency: Integrating processes across the organization improves transparency within the organization. The IPM approach focuses on team members documenting and meeting regularly, which helps keep everyone in the loop.
- Accountability: The integrated nature of the IPM approach makes the entire project team responsible for the project. Since no team member can operate in a silo, IPM improves accountability.
Requires extensive planning: With the IPM approach, you will have to plan extensively upfront and ensure that all processes are well-integrated. This increases your burden significantly and can lead to delays.
Large agencies with diverse teams and processes benefit the most from Integrated Project Management. It works best for complex creative projects where you need resources from multiple teams and departments to interface with each other.
PRiSM (Projects integration Sustainable Methods) is a project management methodology developed by Green Project Management (GPM) Global.
As hinted by the creator's name, the PRiSM approach focuses on accounting for and minimizing adverse environmental impacts of the project. It is different from traditional methodologies in that it extends beyond the end of the project. Instead, it factors in the entire lifecycle of the project post-delivery to maximize sustainability.
Here's an overview of how activities are organized in PRiSM:
The PRiSM approach is very pertinent for modern projects where environmental costs and sustainability are key success criteria. For large projects where reducing energy consumption, managing waste and minimizing environmental impact is critical, PRiSM offers a viable project management ideology.
PRiSM is unsuitable for projects where environmental impact is not a concern (such as software or creative projects).
Success with the PRiSM approach also requires every part of the project team - including outside contractors and stakeholders - to be onboard with the sustainability principle - a hard ask in most organizations.
PRiSM is mostly suited for large and complex real estate and industrial projects where sustainability is a key concern.
PRINCE2 (Projects IN Controlled Environments) is the official project management methodology of the UK government (which means that most UK government projects use it). You can even get a PRINCE2 certification to make working as a project manager in the UK easier.
PRINCE2 is based on 7 principles, 7 themes and 7 processes. The 7 PRINCE2 principles, for instance, are:
- Continued business justification
- Learn from experience
- Defined roles and responsibilities
- Manage by stages
- Manage by Exception
- Focus on products
- Tailor to suit the project environment
Wikipedia has a great introductory article on this methodology. I suggest you start there if you're interested in PRINCE2.
Running a PRINCE2 project requires extensive documentation. Additionally, one of the guiding principles of PRINCE2 is to "Learn from experience". This focus on documentation and past experience can help reduce risk.
The disadvantage of PRINCE2's extensive documentation is that changes can be hard to accommodate. If the requirements change, you have to redo the documentation and re-allocate resources, which can hamper project pace.
This methodology is best-suited for large and complex projects with fixed requirements. If you're in the UK, you'll likely want to know the PRINCE2 methodology. It is widely used in the country and is a requirement for government projects.
There are several other PMMs besides these, such as Six Sigma, Crystal, Feature Driven Development (FDD), Dynamic Systems Development (DSDM), Rational Unified Process (RUP), Kanban, and Lean Development (LD).
For the most part, however, you’ll choose from one of the methodologies described above.
How to Pick the Right Methodology
From the above section, it is clear that different PM methodologies are better suited for different projects. You wouldn’t want to use PRiSM for a software project, just as you wouldn’t want to use Agile for a big real-estate development.
When you’re picking PM methodologies, here are a few things to keep in mind:
1. Evaluate the Project
Focus on gathering initial requirements. If the requirements suggest that you need a large and diverse team, pick a methodology that supports flexibility.
Similarly, if you have a clear idea of the end result, pick a more structured methodology such as Waterfall. If the end result is vague (common in case of in-house projects), pick an iterative methodology like Agile.
Some other things to consider when evaluating the project are:
- Project budget
- Size and complexity
- Stakeholder expectations
- Project type and industry
2. Evaluate Your Team
Your project management methodology is essentially a blueprint for the project. It tells your team what to create and when to create it.
For this to happen, however, your team should be able to read the blueprint itself.
In other words, if your team isn't familiar with the project management methodology of your choice, you will struggle to get results. You will have to devote time to learning the methodology (which some of your team members might be resistant to), leading to delays.
Also consider your team composition. Identify its strengths and weaknesses. If the team thrives on collaboration, you can pick a less structured approach like Agile. If the team is highly motivated and disciplined, a SCRUM approach can work well. If you have limited resources, pick a resource-efficient approach like CCPM.
Here are a few things to consider when evaluating your team:
- Team experience
- Self-organization capabilities
- Team preparedness
- Team location (remote, on-site, etc.)
Essentially, pick a methodology that fits your team, instead of forcing your team to fit the methodology.
3. Evaluate Your Organization
How your company is organized, its culture and its past records will have a big impact on your choice of project management methodology. Some methodologies only work with large organizations with established hierarchies. Others are more suitable for smaller, leaner outfits.
For instance, if your past records show that all your Agile projects have been delayed AND poorly received, it's a good idea to avoid this methodology in the future.
A few things you should consider when evaluating your organization are:
- Past records and experience with different methodologies
- Organization hierarchy
- Level of flexibility
- Organization maturity level
- Organization size
- Available resources, including external resources such as freelancers and contractors.
- Your industry
4. Evaluate Your Stakeholders
When choosing a PM methodology, factor in:
- Stakeholder involvement: Some methodologies demand that stakeholders be regularly involved at every stage of the project. With Agile, for instance, you need stakeholders to be regularly available for feedback. If the stakeholders are busy, pick a methodology that requires lower stakeholder involvement.
- Stakeholder requirements: How do your stakeholders work? What do they require from the project manager? If the stakeholders are known to change project scope frequently, pick a more flexible methodology. Similarly, if the stakeholders require daily updates, pick a methodology that can accommodate this demand.
Given the importance of stakeholders in the project’s success, keeping their requirements in mind will make for happier stakeholders and more successful projects.
5. Evaluate Your Tools
Project management tools are seldom methodology-agnostic. They are usually designed to work well with a specific methodology.
Hence, the software tools you have existing access to and expertise in will impact your choice.
To do this:
- Make a list of all software tools you currently use
- List their limitations and capabilities
- Compare their capabilities against the requirements for a specific PM methodology.
Ideally, the methodology you choose should work with your existing toolset. If you have to buy new tools, you will not only have to spend more but will also lose critical time in retraining your team.
Doing this in-depth evaluation will help you choose a methodology that aligns with your goals, your team’s capabilities, and your stakeholder’s requirements perfectly.
As a project manager, you have several project management methodologies to choose from. Each of these methodologies has its own strengths and weaknesses. Picking the right one will make running your project faster, smoother and more efficient.
Pick from one of the several methodologies listed above. Then evaluate your project, team, organization, stakeholders and existing tools to pick methodology that aligns with your strengths and requirements.
For questions and doubts, drop us a comment below.