When it comes to project management methodologies, there are just as many (if not more) opinions as there are actual methodologies—which is a lot.
Many of these opinions are around agile vs waterfall, but forward-thinking managers and leaders don’t adhere to a single project management methodology.
They become well-versed in many of them, and learn how to mesh together various practices in order to accommodate whatever the project calls for. In fact, 39% of companies have implemented hybrid project management practices.
In this article, you’ll learn to identify methodologies—and particular aspects of methodologies—that you can bring to your digital project delivery practice.
What Are Project Management Methodologies?
Let’s take a stab at a definition of what a project management methodology is.
In short, a project management methodology is a framework that outlines the way that work is completed throughout a project by providing procedures, rules, and practices.
There are many different ways to deliver projects. The methodology that you choose provides structure to the project and can impact project success. It's important to choose a framework that is suited to the project types and deliverables—more on this later.
4 Types Of Project Management Methodologies
Different project management methodologies use different mechanisms to define ways of working.
Some project management methodologies simply define principles, like agile. Others define a “full-stack” methodology framework of themes, principles, and processes, such as PRINCE2.
Some are an extensive list of standards with some processes, like the Project Management Body of Knowledge (PMBOK). Others, like Scrum, simply define processes.
Rather than debate what’s a methodology and what’s not, this article defines PM methodologies as the best practice frameworks we mash together to get projects done.
In other words, a methodology does not have to be a complete full-stack implementation “system” to be considered a methodology.
While simplistic, this definition is more realistic, as project managers use a hodgepodge of principles, themes, and processes tailored for our clients and projects.
And let’s get one thing straight before we start—while there are many project management approaches, there is no “right” methodology. Ultimately, the best methodology is what makes sense and is most suitable for the project, team, and client.
Let’s first take a look at some of the more popular project management methodologies and understand some of the valuable takeaways for delivering projects in the digital world.
What Are The 3 Most Commonly Used Project Management Methodologies?
At agencies, the 3 most common methodologies you'll find used are usually agile, Scrum, and Kanban (or some hybrid methodology that incorporates elements of different agile methodologies).
If you're working in a more rigid industry or governmental organization, you might find that traditional waterfall, PRINCE2, or PMBOK are used more often, although hybrids can be found here too.
I cover each of these methodologies in more detail below.
How Do I Use These Methodologies?
Get help using these methodologies optimally (and learn the fundamentals of project management!) with relevant, practical, expert-led training. Our online digital project management course provides expert instruction so you can lead happy teams and deliver high-value projects in the digital world.
The 9 Most Popular Project Management Methodologies
In this section, I’ve described some of the most popular PM methodologies. Each section includes links to learn more about each approach.
1. Agile: A Flexible, Iterative Process
Let’s start with everyone’s favorite buzzword: agile. The truth is, agile isn’t a methodology, but a set of principles for developing software. The agile manifesto outlines these principles:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Being agile is more of a philosophy and set of values to follow, rather than a process you can directly apply to a project. Even if you’re on board with the agile principles, you still need to define the processes you’ll follow to deliver projects.
When people talk about an agile project management methodology, what they’re usually describing is a flexible, iterative design and build process.
Agile projects consist of a series of tasks that are conceived, executed, and adapted as the situation demands, rather than a pre-planned process. Being agile helps teams respond to unpredictability through incremental, iterative work processes.
In much the same way that a good cook tastes the food as they cook it, adding missing ingredients as they go, an agile project management process requires project teams to cycle through a process of planning, executing, and evaluating.
Agile project management methods emphasize adaptability to changing situations and adequate and ongoing communication among the project team and between the project team and the client. Agile methodologies are great to use in dynamic environments where there’s potential to adjust and adapt estimates. Examples include software delivery and game development.
The downfall of Agile as a philosophy is that it leaves a lot of room for constant iteration. Which can lead to the project going off course and never reaching its desired destination.
Also note that agile is an umbrella term and encompasses multiple variations, including the Scrum methodology, eXtreme Programming (XP), Kanban, and Scrumban.
More about Agile | Agile Tools
2. Scrum: Quick Delivery Via A Self-managing Team
Within software development, Scrum is one of the most popular and simple frameworks for putting the principles of agile into practice. Scrum isn’t a project management methodology per se—it is more of a lightweight structure for developing and maintaining complex products.
Fundamentally, Scrum is about empowering a self-managing team to improve their communication, teamwork, and the speed of the development process.
Scrum defines a simple set of roles, meetings called Scrum events, and tools to efficiently, iteratively, and incrementally deliver valuable, shippable functionality.
Specifically, Scrum advocates for a small, cross-functional team of up to nine people who work on items in a backlog (a collection of user stories or requirements.) A “product owner” defines and prioritizes these requirements.
The team then divides the work into “sprints”, a development cycle of 2-4 weeks. They hold daily “scrums” where the team reports on project progress and impediments. At the end of each sprint, the team holds a sprint retrospective to determine, with the product owner, if the work accomplished passes the definition of done.
Scrum masters lead the Scrums, sprint planning sessions, sprints, demos, and retrospectives to ensure the team is continually optimizing and improving.
There are two main issues with SCRUM. One is deciphering who is leading the charge and the second is the constant need for meetings.
Scrum was originally designed for software development. Therefore, while there are agile artifacts from Scrum that can be used, Scrum doesn’t fit neatly into the typically more strategic and creative agency world.
That’s not to say it can’t work on agency web projects—agency project managers can act as Scrum masters and clients as product owners in one big happy hybrid team. But it’s normally more complicated than that, with fixed budgets and scope providing heavy constraints.
That’s why many agencies take some Scrum concepts—such as small, self-organizing, cross functional teams; daily stand-ups; progress demos; and retrospectives—and apply them in some kind of hybrid approach.
More about Scrum | Scrum tools
3. Kanban: Increased Visibility of WIP and Limiting Multitasking
Kanban is a project management methodology focused on lean principles and increasing efficiency.
It’s similar in many ways to Scrum—it’s about releasing early and often with a collaborative and self-managing team. But compared to Scrum, Kanban is less prescriptive and so offers a softer landing into the agile world.
The Kanban methodology is light on process, flexible, and doesn’t have prescribed roles. Its primary objective is to improve throughput by focusing the team on the things that matter. Kanban’s core practices include visualizing the workflow, limiting work in progress, making process explicit, and continually evaluating opportunities for improvement.
Kanban seeks to continually release work faster and with better quality. It’s great for operational or maintenance environments where priorities can change frequently. Kanban measures success using lead time—how long it takes, after being briefed, to deliver.
When deploying Kanban, project managers represent the team’s workflow on a Kanban board (this can be sticky notes on a whiteboard or digital cards using an online tool like Trello). The board uses categories like “To-do”, “Doing,” and “Done” to visualize what you want to do.
The goal is to limit work in progress (WIP) to improve the flow of work as you measure and optimize the average time to complete items. The Kanban board also lets the team see what’s coming up next so they can prioritize, uncover process problems, and prevent new tasks from stalling. It also helps them to see how new tasks may affect the ongoing work.
Kanban is well-suited to work that requires steady output, like production, support, or maintenance. Within the world of agencies, it can also be a helpful tool as it’s more accommodating to changes, and clients like to change their minds constantly. If Scrum seems too rigid an approach, but you want to “do agile,” Kanban is a simpler alternative.
Kanban is a great tool, however, if your team doesn't fully understand and respect WIP your project can have a lot of one thing and very little of another.
More about Kanban | Kanban vs Scrum | Kanban vs agile | Kanban tools | How To Use Kanban For Project Management | Kanban examples
4. Scrumban: Limits WIP and Adds Additional Structure & Processes
Scrumban methodology is a relatively new hybrid project management methodology that combines a mixed Scrum and Kanban approach to project management. It takes the flexibility of Kanban and adds some of the structure of Scrum to create a new way to manage projects.
Rather than working in potentially restrictive, timeboxed sprints, Scrumban uses a planning on demand principle to fill the backlog. Like Kanban, the team pulls in and assigns tasks as they can accommodate them, limiting work in progress. The development team thus stays focused on the task at hand rather than worrying about what they committed to deliver in the sprint.
Unlike Kanban, Scrumban retains the daily Scrum, but it holds reviews and retrospectives only when needed. The team also conducts planning on an as-needed basis rather than around a sprint, potentially saving time.
In short, Scrumban adds some flexibility to Scrum by removing sprints and allowing an adaptive approach to planning. Or, you could think about Scrumban as adding structure to Kanban with supplementary meetings to foster collaboration and further optimize processes.
Scrumban is useful in product development where there is an unclear vision and evolving requirements or no clear roadmap. It is also useful when a process includes support and maintenance work.
More about Scrumban | Scrumban Tools
5. Lean: Delivering More with Less
Lean methodology is a project management methodology focused on efficiency, or doing more with less. It identifies value and then seeks to maximize it through continuous improvement and elimination of waste.
Lean project management is a theme with principles, rather than a methodology dictating process steps. The lean methodology suggests you can do more with less by addressing the three dysfunctions that create waste—Muda, Mura, and Muri, also known as the 3Ms.
- Muda is about eradicating waste: removing anything that’s not ultimately adding value to the customer. In the world of digital, this could be eliminating rounds of revisions.
- Mura is about eliminating variations: removing the overhead that variances to the standard process create. This could mean standardizing briefs and approval processes.
- Muri is about removing overload: a team’s optimal capacity is 60-70%. Any more than that, and everything slows down. This could mean minimizing the number of projects an agency runs.
Lean wants to change the way we operate to be laser focused on delivering value. It’s about shifting the focus from optimizing separate technologies, assets, and vertical departments to optimizing the flow of projects through entire value streams that flow horizontally across technologies, assets, and departments to customers.
Lean can be a helpful mindset to adopt when reviewing your project delivery process. Think about how you can strip your project process back to the bare essentials that deliver value and cut out the things that are fluff, or tradition for its own sake, and you’ll be thinking lean.
Less is often more. However, with this methodology, things can get a little too lean. When cutting the fluff, you might cut a little of the good stuff too, which can leave your end product lacking.
More about Lean project management.
6. eXtreme Programming: Develop Robustly to Ensure Software Quality
eXtreme programming (XP) defines values and processes to improve software quality and ensure responsiveness to evolving customer requirements. XP values are similar to Scrum and revolve around simplicity, communication, feedback, respect, and courage.
Where XP deviates from Scrum is in defining rules, or prescriptive processes, specific to development projects. These rules include user stories, test-driven development, pair programming, and continuous integration, among many others.
More about eXtreme Programming | eXtreme Programming Tools
7. Waterfall: Predictability for Budget, Timeline, and Scope
The waterfall methodology, also referred to as the software development life cycle (SDLC), is a project management methodology with a simple sequential approach that values solid planning to do it once and do it right.
In waterfall projects, the project manager tends to be large and in charge. The team extensively plans the work upfront and then executes it, in strict sequence, adhering to requirements, to deliver the project in a single (and usually long) cycle.
At the top of the “waterfall” (i.e. at the beginning of the project), the team fully defines the requirements before any work starts. After the project sponsor approves the plan, there’s little scope to adapt the plan unless absolutely necessary, and changes that are needed usually require change requests.
Work then cascades, like water down a waterfall, through subsequent project phases (design, implementation, testing, and maintenance.) The team must complete each phase before the next phase can begin, with no overlap. Typically, the outcome of one phase acts as the input for the next phase.
Because of the single cycle approach, in a waterfall project, there’s little scope to reflect, revise, and adapt once you’ve completed something. For example, once you’re in the testing stage, it is difficult to go back and change something that was not well designed initially.
While the Waterfall methodology is clear and concise, this method can be a little too rigid and leaves very little room (if any) for adaptations. It can also take some time to get your project completed.
Another potential downside to the waterfall model is that there is nothing to show and tell the client as you go along. You complete the project with a big fanfare and pray the client likes it. That’s potentially risky.
Agencies regard waterfall with some disdain—they consider it an inefficient and passé traditional project management approach.
But, waterfall can be a useful and predictable approach if requirements are fixed, well documented and clear, the technology is understood and mature, the project is short, and there’s no additional value gained from “going agile.” A waterfall approach can offer a more predictable end result for budget, timeline, and scope.
More about Waterfall | Waterfall Project Management Tools | Requirements Management Tools
8. PRINCE2: Clearly Defined Processes for Large-scale Projects
The UK government created the PRINCE2 methodology in 1996 as a “full stack” waterfall project management methodology for IT projects. The acronym PRINCE2 stands for PRojects IN Controlled Environments.
PRINCE2 is a process-oriented methodology that divides projects into multiple stages, each with their own plans and processes to follow. The methodology defines inputs and outputs for every stage of a project, so that nothing is left to chance.
This includes six aspects to manage in every project, seven high-level processes to follow, and seven project management principles, the first of which stipulates a business justification for the effort.
PRINCE2 also includes a thorough governance structure. A project board owns the project, defines team structures, and is responsible for project success. A project manager oversees the progress of day-to-day activities.
As a methodology, PRINCE2 is incredibly thorough—it’s great for running large, predictable, enterprise projects.
It clarifies what will be delivered, emphasizes project viability, defines roles and responsibilities, and endorses management by exception (arguably an agile principle). On the flipside, the degree of process can make PRINCE2 laborious and onerous for small projects.
PRINCE2 is the perfect methodology for the perfect world. The problem is, nothing is perfect and plans change. This approach leaves nothing to chance, which protects the project but also means you might miss a great opportunity.
Although PRINCE2 is probably too complex to use in an agency setting, its emphasis on developing a good business case, defining clear roles and responsibilities, and managing change and risk are helpful considerations to apply to our own projects.
More about PRINCE2 | PRINCE2 Project Management Software | Enterprise Project Management Methodologies | More about the importance of change management
9. PMI’s PMBOK: Apply Best Practices to Optimize your Projects
The Project Management Institute’s PMBOK is not a true methodology but rather a framework of project management standards, conventions, processes, best practices, terminologies, and guidelines.
PMBOK refers to five process groups of project management (also known as the project life cycle): initiating, planning, executing, monitoring and controlling, and closing. It also describes 49 process management processes that it organizes into 10 knowledge areas.
Think of the PMBOK as a comprehensive reference guide—its best practices are useful as a foundation, but to implement it as a methodology, you need to determine which processes you’ll apply, when, by whom, and to what extent. You also have to factor in your organization’s structure, governance, and workflows to adapt the PMBOK to your specific circumstances.
PMBOK requires a lot of reading upfront, leaving less time for the actual project. For PMs who want to get a successful project completed on time and within budget, this might not be the right fit for you.
PMBOK doesn’t fly in an agency setting, but you can pick and choose from its standards to apply best practices to your own projects.
More about PMI's PMBOK | More about the 7th edition of the PMBOK
How to Choose the Right Project Management Methodology
Choosing the right methodology is important because it defines how we work. It provides the structures that guide us toward project success or failure. As there is no one-size-fits-all method that works across business types, sizes, or industries, it’s important that you put some time and effort into choosing the right project management methodology for your context.
Here are a few factors to consider when deciding which project management methodology to use in your project:
1. Degree of Project Complexity
This includes the project itself, the client, available resources and other project constraints (including the appetite for change and risk), timeline, tools, and people. List these factors and label them according to their simplicity or complexity.
2. Rigidity or Flexibility of your Work Environment
If you’re working in a dynamic environment where there’s an appetite for evolution and change, an agile methodology can work well for you. If you’re working within fixed requirements, timelines, and budgets, you might be better off with a waterfall approach or other traditional approach.
Along with this consideration of your flexibility, take a look at your constraints and risks. How can you enact processes that minimize your key risks and help your teams fit their projects neatly within your organizational constraints?
Regardless of whether you’re more flexible (ex. nimble design studio with a small team whose members wear multiple hats) or more rigid (ex. in-house agency with lots of internal regulations), now is also a good time to ask yourself whether your organization should remain as rigid or flexible as it is.
You can choose a methodology or hybrid methodology that pushes your organization in the direction you want to go—with the caution that you should choose methods that are realistic for your teams to implement today.
3. What Delivers the Most Value
Ask yourself what delivers the most value to the client (or the stakeholder, or the end-user). Make a list of their needs and use it to help you select a way of working that best meets those needs.
For example, if your clients tend to make ongoing requests and expect constant updates and changes, then an iterative methodology with short cycles will help the client feel like they are getting more value. Using this methodology will help you deliver value and maintain positive relationships with clients.
4. Alignment with Organizational Goals
Use the project goals or project objectives you’ve already created as a team or organization to guide your selection of a project methodology.
Clearly, your methods should be a means to achieve your goals—the best method is the one that guides you towards your strategic objectives most directly with the greatest gains and least negative impact.
5. Alignment with Organizational and Team Values
Lastly and perhaps most importantly, do a deep dive into your values. Team members are responsible for implementing the methodology you choose—don’t forget these team members are people with habits, opinions, and values.
Instead of adopting a trending methodology and hoping it sticks, use the ways your stakeholders think, relate, and work to build out a methodology that’s a natural fit.
Your organization’s and team’s values can give shape to a truly sustainable methodology that is less a theoretical standard (that you won’t meet) but rather a useful set of processes that are easy to maintain long-term.
Remember, no methodology is better than another. The strength of a methodology depends on how well it complements organizational goals and values; the constraints the project team has to deal with; stakeholder needs; risks; and project size, cost, and complexity.
Traditional Waterfall Vs Agile At Digital Agencies
Project managers at digital agencies are forever asking what the differences between agile and waterfall are and which to use on their projects.
The short answer?
It depends. There’s no right or wrong. It depends on your client, your team, and the project.
Here are a few points to consider when thinking about the best project management methodology for digital agencies.
The Pros and Cons of Using Waterfall in Digital Agencies
Almost universally, at an agency, putting your head above the parapet and suggesting that the waterfall method might be a good approach for a project is tantamount to painting a large target on yourself.
Waterfall is something no client or team wants to hear—we want to be seen as cutting edge, and waterfall is definitely not cool.
Not only is it not cool, but waterfall is challenging because it requires heavy upfront project planning before any value-generating work is done. Planning is sometimes necessary because clients need to approve a cost, timeline, and scope.
But clients are usually reluctant to pay for planning, and even in cases where agencies have successfully transitioned clients from waterfall to more agile contracts, what happens if your planning isn’t up to scratch?
In truth, in the digital world, we regularly struggle with making accurate estimates. We’re usually working with new technologies, on vague projects. Often, as soon as you start your project, your plan is already out of date. So while clients like the predictability of the deliverables, budget, and timeline, a waterfall approach is inherently inflexible.
So what about some flavor of agile?
The Pros and Cons of Using Agile in Digital Agencies
Between agencies and clients, there tends to be a pretty fluid understanding of the agile method.
Agile is largely lauded for “not being waterfall” and is widely misunderstood to mean “doing more, with less, faster and cheaper than ever before.”
Why wouldn’t you want that?
Clients tend to love the idea of agile because of its apparent flexibility to pivot a project, granting them more opportunities to change their minds continually throughout the engagement.
They often think that it means that they’ll get more work done for less—or that they don’t have to make a final decision on anything because they can change their mind until the last minute.
That’s sort of true, but not the whole story. Truth is, agile might be better, but agile doesn’t come cheap or easy. The catch is that that level of flexibility is expensive. Yes, you can change your mind—but it eats up time, and time is money.
Another challenge is that a successful agile project requires clients to make themselves available and be empowered to make decisions (which is rare in hierarchical and board-oriented organizations). They need to provide ongoing feedback and prioritization on the fly to keep the project moving, which is often tricky.
2 Project Management Methodology Examples From Real Teams
Enough with the theory, let’s talk about how to apply project management methodologies IRL. Here are some case studies from companies you’re probably familiar with.
1. Kanban Method at Vanguard
There’s an assortment of Kanban, lean, and agile-based practices in place at Vanguard, one of the world’s largest investment management companies with a portfolio of 5.2 trillion dollars in global assets. As of 2019, they’ve had some form of agile practice in place for 12 years, including 5 years of DevOps.
A case study on Vanguard’s lean operating model examines the benefits and challenges that 24 of the organization’s agile teams experienced. It also describes how Vanguard used the data these teams collected to continuously adapt and improve their Kanban-based approach.
Interestingly, the majority of Vanguard’s Kanban-based teams started with Scrum and eventually migrated towards Kanban. Many of them did so because of “Scrum stall”—what happens when a team of knowledge workers becomes chronically overburdened and bottlenecked.
What about lessons learned? The study reports that Vanguard was able to accelerate its flow of work, feedback, and learning by adopting the Kanban enterprise service’s planning (ESP) approach.
Monthly operations reviews across teams and replenishment meetings involving mid-level management were most effective in speeding up their flow of work.
2. Agile at Cisco
Multinational technology company Cisco has been shifting away from running waterfall digital IT projects, switching to an agile approach. In a case study on Cisco’s subscription billing platform and WebEx app development, they recorded the effects of adopting a Scaled Agile Framework (SAFe).
Adopting SAFe led to a 40% decrease in critical and major defects, along with a 15% increase in defect removal efficiency. Their employees were also happier, as this change eliminated the need for after-hours work and reduced the number of meetings and calls to attend.
Lessons learned from Cisco? In their study, they note the importance of adapting your project management methodology. For them, adjusting as needed meant the company didn’t mandate using SAFe on unintegrated or loosely integrated projects where it didn’t make sense to use it.
Other Project Management Methodologies
The list of project management methodologies above is by no means an exhaustive list—these are simply the most common methodologies in the agency PM world. Additional project management methodologies include:
Adaptive Framework Methodology
Project scope is variable, but time and cost are constant, making it possible to adjust the project scope during execution to maximize business value.
Six Sigma
Motorola developed Six Sigma to improve the efficiency of business processes. The Six Sigma methodology uses statistical tools to identify the cause of errors, eliminate defects, and reduce the possibility of future errors. Examples of Six Sigma statistical tools include cause and effect analysis, flow charts, histograms, and scatter plots.
Critical Path Method
Industries like construction, software development, and engineering use the critical path method (CPM) as a technique for modeling and scheduling project activities.
In this method, you determine the activities needed to complete a project, the time that each will take, the dependencies between them, and their deliverables or milestones.
You then use this information to calculate the longest and shortest paths to completing your project, which helps you understand key project activities—namely, which activities can be delayed without affecting your milestones and which activities can’t.
Critical Chain Method
Similar to CPM, critical chain project management (CCPM) is a technique for modeling and scheduling project activities. The difference between the critical path and critical chain methods is that CCPM considers resource availability when calculating the duration of project activities.
The critical chain methodology dedicates resources 100% to a project. If a task finishes early, you can proceed to the next task without bottlenecks.
PERT
Program evaluation review technique (PERT) is a method for modeling, scheduling, and coordinating tasks within a project. In PERT, project activities are represented as nodes on a network diagram, with their durations listed on the lines connecting the activities.
What’s Next?
Selecting the most suitable project management methodology can be tricky. It depends on many variables, several of which are outside of our control as project managers.
If you’re stressing about what to do, keep in mind that project management methodologies are tools to help us deliver projects. It’s not worth arguing over the final details of a methodology—we should be focusing on the bigger picture.
Are you working with Kanban, waterfall, or some other method? Great! Because it doesn’t matter too much which methodology you’re using. What matters is a commitment to doing quality work. Work that meets user needs and delivers great value to our clients.
The best methodology is one that improves organically, adapting and increasing the value of its output over time. And, adaptability requires that you be pragmatic, rather than dogmatic, about the methodology you use.
It's also worth reading up on the difference between task management and project management.
What Do You Think?
How do you choose your project management methodology? Is there a methodology you prefer over others? If so, why? Please share in the comments below.
Don’t forget to subscribe to The Digital Project Manager newsletter.
22 Comments