Flash sale! 🎄
30% off annual plans
Save now
Monthly video updates are back by popular demand!
See what's new.
Guide to Project Management
Discover why companies like Amazon, Netflix, and Nike manage their projects with TeamGantt.
Create your free project plan
Free forever. No credit card required.
An image of the TeamGantt gantt chart.
Chapter 3

Project Management Methodologies and Approaches

Think about it for a minute: Project management has been around since there have been projects. That means that some form of PM has existed since ancient times when major projects like the pyramids were built. But it wasn’t until the early 1900s that things started to become more formal. In fact, Henry Gantt created (or adapted) a nifty tool called the gantt chart in 1917. One of the first major applications of the tool was in World War I by the United States. From that point forward, new methods and tools have been created to help teams keep projects on track.

Download this guide
Redirecting to your PDF
Oops! Something went wrong while submitting the form.

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:

Which project management methodology is best for your project?

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:

  • What is the intended outcome of your project?
  • Is it a product you’ll create? An experience? A specific deliverable?
  • What are the goals of the project?
  • Who needs to be involved in the project based on the answers to questions 1 and 2?
  • How do the people you’d like to assign to the project like to work?
  • Is anyone certified or really, really hardcore about sticking to a methodology?
  • If you’re working with a client, do they subscribe to a methodology?
  • Are you aware of how they work, and how will their way of working impact your team?
  • Are there any outside factors you need to take into account when planning? (Think about dependencies, project or client values, etc.)
  • What is already working for your team? What is working for your clients? Also, what isn’t working?

Traditional project management methodologies

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 method

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.

Critical Path Method (CPM)

The Critical Path Method is complex due to the steps and analyzation 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 or software 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.

Pros and cons of traditional methodologies

Every project management method has pros and cons. So let’s take a look at some of the reasons people choose traditional methodologies for their projects—and some of the downsides you should be aware of—using Waterfall as an example.

We’ll start with the benefits of traditional project management. Here are some advantages traditional methods bring to the table:

  • Clear and complete documentation paves the way for straightforward feedback and decisions. The fact that Waterfall produces detailed project requirements means every piece of your project will be well-defined and documented. If someone wants to change a requirement, discuss it head-on because scope and budget will always be affected.
  • Solid estimates set clear expectations. Most Waterfall practitioners will create a Work Breakdown Structure of all tasks and subtasks. That detailed estimate can then translate to a firm project scope that correlates to a detailed project plan, creating very clear expectations about timing and scope.
  • Visual project plans are easy to understand. Creating a Waterfall project plan is fairly straightforward because projects run in a linear manner with defined dependencies and responsibilities. Plus, the division of steps and tasks is simple to interpret. This makes planning your team’s time easier (and expected) and leads to a clear hand-off or end date.
  • It’s easy to measure the impact of project changes. While it’s difficult to make up for changes or missed deadlines, it’s easy to determine the impact of a change and quickly make adjustments (though that does usually mean your deadline will be affected).
  • Communicating progress is simple. It’s easy to measure the completeness of your project because all tasks and milestones are mapped out with dependencies.
  • Accountability is clear. Each person can see when they’re expected to do their part and what happens if there’s a delay.
  • Communications are easier. When everyone can visualize the project, you’re able to easily communicate with bosses, clients, and team members. Everyone can review the project plan together when it’s drafted and spot potential issues or areas that might require special attention.

Of course, traditional approaches come with a few disadvantages too. Consider these important factors before deciding if traditional project management is right for you:

  • Silos and lack of collaboration: Because team members work on specific tasks in phases and hand work off to someone else, it leaves little room for collaboration. Instead, it’s all about getting work done to documentation and ensuring the next person in line can use what was previously created or documented.
  • Speed to launch: When you build one thing at a time, it means you take a considerable amount of time to get just one thing done—even if you could be working on other things at the same time.
  • Ideation: If you don’t know what you want to build, traditional project management is not for you. The idea here is to receive or create project requirements and act on them—not iterate on them throughout the process.
  • Change and documentation: Things change in business, and when documentation is built at the beginning of a project, the project can’t always change with the business without serious impact. (Sometimes that impact might be to start over.) So, while the documentation is strong, it can serve as a risk on longer projects.

Agile methodologies

Agile 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:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

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, 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 blend traditional methodologies with Agile, like using a gantt chart to manage your Agile projects.


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 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 in order to get the work in 2-week cycles, or “sprints,” to get work done quickly. Scrum calls for “ceremonies” (meetings for the uninitiated) to keep things on track:

  • Daily stand-ups: A short (15 minutes max) meeting each day to discuss progress, what’s next, and blockers. You stand during this meeting in order to keep it short, because who wants to stand for that long?
  • Sprint planning: A creatively named meeting that is a bit longer (an hour max) and comes with the objective plan what will be done within the sprint.
  • Sprint review: A meeting to review all work done at the end of a sprint. In this meeting you might collect feedback, decide something is done, or decide on an alternate route.
  • Sprint retrospective: An often-skipped meeting held after the sprint review for up to an hour to discuss what might make future sprints more productive.

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.


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.

Extreme Programming (XP)

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.

Adaptive Project Framework (APF)

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.

Pros and cons of Agile methodologies

Now that we’ve covered common Agile methods, let’s break down the pros and cons of Agile. We’ll use Scrum as an example since it’s one of the more popular Agile methodologies.

Here are the big key benefits you’ll find in Agile project management:

  • Focus on quality: Because products are built collaboratively and tested during sprint cycles, the product has many eyes on it at all times. And the flexibility of the process enables teams to pivot and make a change for the better if something’s not working well.
  • Lightweight process: Scrum offers a light framework for helping teams work together. Lower-level documentation and collaboration through ceremonies means the focus is on rapid delivery and iteration.
  • Continuing evaluation and optimization: The measuring and evaluating of the work—and how it’s done—allows accurate and early visibility into the progress, or even problems, with a project. Plus, sprint reviews regularly open the door to act on feedback faster.
  • Reduced risk: Agile methodologies virtually eliminate the chances of absolute project failure—unless a team is just not performing well. But the fact that teams work in sprints toward releasing a working product means there is always progress. Even if that progress is open to change, a team is working toward goals set by the product owner.
  • High customer satisfaction: Because change is easy to adapt to in a Scrum framework, customers tend to be happy because they have a higher probability of getting what they want.

Despite its advantages, Agile’s not made for every team or project. Take these considerations into account to ensure Agile methods are a good fit for you:

  • Changing behaviors: Agile requires not only a project manager or team to buy into the values and principles, but the entire organization. And that can be difficult because change is hard for many people. In order to make a full “Agile transformation,” teams need to be trained and fully invested in the methods.
  • Understanding and embracing roles: Scrum roles are important, especially when it comes to the product owner and Scrum Master. And it can be tough to find trained individuals who can write user stories properly, manage conflicting priorities, and facilitate work successfully. Remember, training is necessary to make Scrum work well.
  • Lack of dedicated cross-functional teams: If your team is pulled in several directions or simply assigned to more than one project, they will not be able to dedicate themselves to a single project and the rest of their team. That will lead to a breakdown in process, collaboration, and team morale.
  • Collaboration: If your team doesn’t work in a space where they can freely meet and talk—or have the resources to do so remotely—you’ll end up in silos. And when that happens, the spirit of Agile breaks down.

Change management methodologies

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!

Event Chain Methodology (ECM)

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?

Extreme Project Management (XPM)

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.

PRiSM (Projects Integrating Sustainable Methods)

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.

Process-based methodologies

New ways of working materialize every once in awhile and catch some traction. Sometimes these are more likely seen as business processes rather than methods, they certainly have the potential to grow in to 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.

Six Sigma

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!

PRINCE2 (PRojects IN Controlled Environments)

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.

Plan your project in minutes

Learn how easy project planning can be with TeamGantt. Create your first gantt chart for free!