As a project manager, it’s important to know your history, and it’s not just for the sake of knowing what happened. It’s good to know how methods were created and decide for yourself how they can be adapted in the work you’re doing today. So, if you’re looking to learn, you’ve come to the right place. This article will explore the many types of project management methodologies, including:
When it comes to project management methodologies, no method is "better" than another. You need to do what works for your team, your stakeholders, and your project itself. No matter what you do, make sure you outline and discuss your methodology with your team and be sure that everyone understands it and is on board. After all, the key to success is communication and nicely set expectations, not a process map or plan.
While it’s important to have a solid understanding of the many different ways to operate a project, you don’t have to feel as though you’re tethered to just one way of working. In fact, it’s very important to remember that you have to do what works for your team, your clients, and your project itself.
The fact is, a prescribed method may not always work the way you want it to. And you’ve got to have the right mix of people, budget, and deadline to truly make something work well (or as you intended). What it comes down to is that none of these methods are “better” than the others. Do what you can to understand them and adapt them to your situation.
Hey, you might find that parts of Agile work for your team, but not all of them—and that's okay too. Whatever you do, don’t overthink your process. Try something new, adjust when you see the need, and focus on solid communications and delivering quality work.
If you’re having a hard time deciding what steps in a particular project management methodology will work for you, think through these questions and scenarios:
Easy drag and drop features with templates for faster scheduling. Plan a project in minutes, collaborate easily as a team, and switch to calendar and list views in a single click.
Create your free plan
Some projects—or even industries—require projects to be run sequentially. So if you’re working in construction or something similar and do a lot of planning to ensure that the completion of a sequence of specific tasks gets you to the delivery of a final, finished product by a certain date and within a budget, you might be interested in mastering the traditional PM methods.
Traditional PM methodologies work well for industries that rely on a well-defined process to get work done. These may include construction, manufacturing, print design and production, marketing, editorial content, and IT, just to name a few.
Let’s take a closer look at 2 traditional methodologies you might want to use for your projects.
The Waterfall model was invented by Winston W. Royce in 1970. He wrote a scientific article that contained his personal views on software development and showed examples of why this process doesn’t work as well as more iterative approaches. But the Waterfall method does work in some industries. Here’s why.
Waterfall is certainly among the most widely known and practiced PM methodologies. The key ingredient in running a Waterfall project is to complete a task and hand it down for it to be used, or built on, in a following task or phase. This requires a fair amount of planning and requirement-gathering before work begins. Without that initial step, steps can be missed, incomplete, or even out of line. Further, any alteration to project requirements can cause a change in scope.
It’s easy to plan a project this way, but as soon as change occurs, you’ll be faced with scope changes, confusion, and pushed-out deadlines. Waterfall is known for the handoff—allowing resources to work in silos. It works in some places, less in others. It has worked quite well for software development projects, though you’ll find that many teams have moved on to more modern approaches. Since then, it has been adopted by other industries who find that preplanning and requirements help to organize their project needs and finitely plan out steps, tasks, and associated resources to meet timelines and budgets.
Learn more about the Waterfall methodology.
The Critical Path Method is complex due to the steps and analysis involved, but it is actually quite simple! When done properly, this method can provide great clarity into a project’s tasks and how long a project will take to complete, This project modeling technique was developed in the late 1950s by Morgan R. Walker of DuPont and James E. Kelley, Jr., of Remington Rand, who were working on similar project approaches. It has since been modified and is generally applied to any approach that breaks a project into several work tasks, displays them in a flow chart, and then calculates the project duration based on estimated durations for each task.
In essence, the goal of this method is to map out all of the tasks of a project, define what needs to be completed before each task starts, then estimate the time it will take to complete each task. From there, you calculate the longest path of the planned tasks to the end of the project, and the earliest and latest points each task can start without making the project longer. That’s how you determine what’s critical and what can be delayed (there can be more than one critical task). Essentially, you prioritize tasks to ensure you get the most important work done first.
You’ll find the Critical Path Method used for many types of projects, including construction, software development, research projects, engineering, and even product development. The first time CPM was used for major skyscraper development was in 1966 while constructing the former World Trade Center Twin Towers in NYC. Although the original CPM program and approach is no longer used, the term is generally applied to any approach used to analyze a project network logic diagram.
Easy drag and drop features with templates for faster scheduling. Plan a project in minutes, collaborate easily as a team, and switch to calendar and list views in a single click.
Create your free planAgile methodologies are based on the mindset that self-organizing software development teams can deliver value through iteration and collaboration. The Agile Manifesto for Software Development was formally developed in 2001 by 17 practitioners and is based on a core set of values of delivering value and collaborating with customers. The principles are:
While Agile originated in software development, any industry with some level of uncertainty can use Agile project management. For example, you may also find Agile approaches in product and service companies, digital agencies, marketing teams, distribution, automobile design, and design and engineering.
Over time, several Agile approaches have been developed, tested, and revised—just like the methodology itself. Below, you’ll find information about various Agile methodologies to research and try with your team. You might even come up with innovative ways to combine Waterfall with Agile for a hybrid approach, like using a gantt chart to manage your Agile projects.
Learn more about the differences between Waterfall and Agile.
Simply put, Scrum is the simplest—and likely most popular—of the Agile methods that exist today. There’s some confusion over who “invented” Scrum, but we’re excited about the ideas because it allows teams to get work done in iterative sprints without the added complexity that some methodologies introduce.
When practicing Scrum, a team self-organizes around central roles that suit them: Scrum Master, Product Owner, and Engineering/Development Team. The Product Owner sets the vision and priority for the project, and the Scrum Master removes any blockers from the Development Team’s way to get work done quickly.
Scrum calls for “ceremonies” (meetings for the uninitiated) to keep things on track. These include daily stand-ups, sprint planning, sprint reviews, and sprint retrospectives.
There is an art to finding the right pace for a team, but Scrum does a really nice job of defining your pace and expectations at the outset of the project—and at each sprint. You’ll have to work through it to make sure that the roles and ceremonies work for you, but again, you can always adapt if you’re working on creating products and can continue to refine and iterate it until your customers are happy.
See how Agile works using a Scrum framework.
In 1953, Toyota adapted supermarket inventory control process logic to their machine shop as a process and officially used a “signboard” or “billboard,” which is the literal translation of the Japanese word “Kanban.” This visual approach puts time and resources aside and focuses on tasks. In fact, Kanban helps teams make decisions on what to produce, when to produce it, and how much of it to produce. If you’ve used a tool that shows cards move through a progression of states to indicate where it is in process, you’ve used a Kanban board.
Many Agile teams use Kanban boards to remain transparent about where their work stands in process. The visual management of the board allows teams to quickly point out and understand project obstacles, discuss them, and collaborate on ways to get past them. You’ll find a lot of teams working on digital projects using Kanban methods to manage their workflow.
Learn the difference between Kanban and Scrum.
Want to take your method to the next level...or the extreme? Well, check out XP, which was created by software engineer Kent Beck in the 1990s during his work on a payroll project at Chrysler. This Agile methodology is intended to improve quality by responding quickly to change. If you’re working on projects that have shifting requirements and continuous feedback,and know change can happen—and is normal—Extreme Programming might be just for you. XP describes 4 basic activities that are performed within the software development process that allow for change and rapid revision: coding, testing, listening, and designing. Teams organize in shorter sprints and can immediately change the course of their work being done/planned.
This one may resonate for PMs who recognize that you have to adapt your methodology to the project’s goals. With AFP, you document project requirements, functions, sub functions, and features before determining project goals. The team then operates in iterative stages rather than sprints, but stakeholders can change the project scope at the start of each stage. So, truly, you adapt to the project—and its people.
Risks are inherent in all projects. You just know something will come up, and you want to prepare for them. These methodologies are meant for the PM folk who are hyper-focused on what could pull a project off the rails and come up with stable ways to get it back under control—or just roll with it and make sure the project gets done!
If Critical Path wasn’t enough for you, you may want to take a look at ECM. The 6 principles of ECM make up a technique that is focused on identifying risks and their potential effects on a project’s schedule. Think of it this way: The ECM PM is living in doomsday. Everything is a risk, and they know how to handle it. On one hand, it makes the team comfortable. On the other, it can be sort of gloomy to always think about the worst that can happen. After all, your control ends somewhere, right?
Not to be confused with Extreme Programming, XPM is all about embracing change and altering project plans, requirements, resources, budgets, and even the final deliverable to meet changing needs. You’ll find that most projects that follow XPM are shorter in nature—this isn’t the type of method to use on a long project that carries the risk of dragging out for months and months. Rather, it is fast-paced and requires short cycles of work and openness to feedback and iteration that can evolve the original intent of the work.
This method was developed by GPM Global for managing change focused on sustainability, or using existing organizational resources to reduce negative impact on environmental or social impacts. It follows 6 principles that are derived from the UN Global Compact’s Ten Principles. This is serious process work that can make our lives better in major ways, and they’re typically implemented primarily for large-scale real estate development or construction/infrastructure projects that may result in adverse environmental effects.
New ways of working materialize every once in a while and catch some traction. Sometimes these are more likely seen as business processes rather than methods, they certainly have the potential to grow into them. After all, based on history, that is how a lot of the aforementioned methodologies began. So, while not all of these may really be classified as “methodologies,” and they might not apply to you, they are worth mentioning because you might be able to lift an idea from one methodology to apply it to your own work.
Do more with less! This methodology is focused on removing unneeded steps, resources, and budget in order to deliver a product. If you’re in the digital space, you might have seen talk of Lean UX, which is mostly about about applying the Lean methods to user experience work, which has traditionally weighed heavily on project budgets due to an abundance of deliverables (sitemaps, wireframes, flow diagrams, content inventories, taxonomies, and so many more). Lean UX brings ideas and the actual design of the experience to the forefront of the process, with less emphasis on deliverables.
This is a disciplined, data-driven methodology developed by an engineer at Motorola that has been adopted by many large organizations focused on manufacturing. It seeks predictable process results to improve the quality of the final product by following a set of steps and removing the cause for defects. A Six Sigma process is one in which 99.99966% of all opportunities to produce some feature are statistically expected to be free of defects. That’s quality assurance—and profitability!
This methodology was developed for use by the UK government and has grown widely since, as it’s now being used all over the world. With this methodology, the project is tightly controlled and planned before it begins, with stages clearly structured. This process-based approach leaves very little room for questions, as it is based on 7 principles, 7 roles, and 7 process phases with direction on very specific documentation. The role of the PM is a bit different with PRINCE2, as they are responsible for basic activities like scheduling, while an appointed project board handles activities like resourcing, goal setting, and the team.
Learn how easy project planning can be with TeamGantt. Create your first gantt chart for free!
