9 Of The Most Popular Project Management Methodologies Made Simple

Published in

The Digital Project Manager

18 min readJun 21, 2017

The ever-evolving project management methodology list of agile, scrum, kanban, lean, xp, waterfall PRINCE2 and PMBOK can be confusing. In this complete guide to project management methodologies, we’re going to make it all super simple to understand.

There are stacks of different project management methodologies you could apply to different projects, but knowing the differences between them, and how to know which is the right methodology to use can be tricky.

Read this guide to give yourself an overview of the most commonly used project management methodologies and consider how they can be best leveraged for delivering projects in the world of digital agencies.

Project management methodology overview:

Or just jump to discover:

Introducing Project Management Methodologies

Let’s take a stab at understanding what a project management methodology is. The PMI’s broad definition of project management methodology is helpful — ‘A methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline’ — but a methodology has to be rooted in something more fundamental that dictates why we choose to do things a certain way, so I’d suggest it should also include themes.

As project managers, there are many different ways to deliver projects. Broadly speaking, these ways are our methodologies — applying different principles, themes, frameworks, processes and standards to help provide structure to the way we deliver projects.

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 process, like PMI’s PMBOK, or XP and some are very light, and simply define process, like Scrum.

Maybe controversially, rather than debating what’s a methodology and what’s not, I’m using the broad (yes, mis)understanding of project management methodologies to mean simply the best practice frameworks we mash together to get projects done. I don’t think a methodology has to be a complete full-stack implementation ‘system’ to be considered a methodology.

It’s a good and helpful definition because in reality, as project managers we 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 methodologies, there is no ‘right’ methodology. There is no one-size-fits-all one methodology that is the methodology that should always be used for every project.

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 world of digital.

Common Project Management Methodologies

Agile methodology — collaborating to iteratively deliver whatever works

Let’s start with everyone’s favorite buzzword, agile. The truth is, agile isn’t actually a methodology at all, but a set of principles for developing software. The principles are outlined in the agile manifesto outlines four values — Individuals and interactions over processes and tools; Working software over comprehensive documentation; Customer collaboration over contract negotiation; Responding to change over following a plan — so being agile is more of a philosophy and set of values and principles to follow, rather than a process to apply to a project.

When people talk about an agile project management methodology, what they’re usually describing is a flexible, iterative design and build process. Agile projects are characterized by 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 along, an agile project management process requires project teams to cycle through a process of planning, executing, and evaluating as they go along.

Agile is different from other project management methods which usually assume that things affecting the project are predictable, and so it emphasizes adaptability to changing situations, adequate and ongoing communication among the project team and between them and the client. Agile methodologies are great to use in dynamic environments where there’s potential for changing or evolving requirements such as software and game development.

As a set of principles, agile is the Big Daddy, and tends to be used as an umbrella term used for flavours of agile including Scrum, Extreme Programming (XP), Kanban, and Scrumban. So in short, and to make things confusing, agile isn’t a methodology or process you can use — if you’re on board with the principles, you still need to define the processes for delivering projects.

More about agile | Agile Tools | Learning Agile: Understanding Scrum, XP, Lean, and Kanban

Scrum methodology — enabling a small, cross-functional, self-managing team to deliver fast

Scrum is a project management methodology with proposes principles and process to improve delivery. Within software development, Scrum is one of the most popular and simple frameworks to put the principles of agile in practice.

The goal is Scrum is to improve communication, teamwork and speed of development. If you hear people talking about sprints, scrums, backlogs and burndowns, they’re probably talking about Scrum, or some derivative of it.

Scrum isn’t really a project management methodology but a framework for the ongoing development and maintenance of complex products. Scrum is a light approach and defines a simple set of roles, meetings, and tools to efficiently, iteratively and incrementally deliver valuable, shippable functionality.

Fundamentally, Scrum is about empowering a self-managing team to deliver and defines roles and responsibilities to create a healthy tension between delivering the right thing, the right way, as fast as possible.

Scrum advocates using a small, cross-functional team of up to 9 people who work on items in a backlog — a collection of user stories (requirements) — that have been defined and prioritized by a Product Owner.

Work is divided into ‘sprints’, a development cycle of usually 2–4 weeks, during which, daily ‘scrums’ take place where the team report on progress and impediments. At the end of each sprint, work is then reviewed in a sprint review meeting to determine together with the Product Owner if it passes the Definition of Done (DoD).

Scrum is facilitated and served by a Scrum Master who enables and leads the scrums, sprint demo’s and reviews, leading the development team to do their best work as well as a leading a ‘sprint retrospective’ after each sprint, to ensure the team is continually optimizing and improving.

Scrum was originally designed for software development so while there are agile artifacts from scrum though that can be leveraged — scrum doesn’t fit neatly into the typically more strategic and creative agency world. Even on agency web projects, fixed budgets, timelines and scope provide a lack of flexibility for a scrum self-managing team, on a project with a defined beginning and end.

That’s not to say it can’t work, on development 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 of the concepts of scrum — small, self-organizing, cross functional teams, daily stand-ups, progress demo’s and retrospectives and use them in some kind of hybrid approach.

More about Scrum | Agile tools | Scrum: a Breathtakingly Brief and Agile Introduction

Kanban methodology — improving speed and quality of delivery by increasing visibility of work in progress, and limiting multi-tasking

Kanban is a project management methodology focused on lean principles and a strict process to increase efficiency. It’s similar in many ways to Scrum — it’s all about releasing early and often with a collaborative and self-managing team. But compared to Scrum, Kanban is a more evolutionary change, a softer landing into the world of agile as it’s less prescriptive.

Kanban is light on process, flexible, doesn’t have prescribed roles, and simply tries to improve throughput by increasing the focus of the team on the things that really matter. The core practices are visualizing the workflow, limiting work in progress, measuring the lead time, making process policies explicit and continually evaluating improvement opportunities.

Kanban’s focus is on work that is continually released, faster, and with better quality. It’s great for operational or maintenance environments where priorities can change frequently. Kanban focuses on measuring Lead Time — how long it takes, after being briefed, to deliver.

With Kanban, project managers typically use sticky notes on a Kanban whiteboard or online tool like Trello, to represent the team’s workflow, with categories as simple as ‘To-do’, ‘Doing’ and ‘Done’.

This visualizes what you want to do and limits work in progress (WIP) so that the flow of work is improved as you measure and optimize the average time to complete items.

It also gives the team a visual display of what is coming up next, which makes it easy to reprioritize, uncover process problems and prevent tasks from stalling. It also helps them to see how any new task may affect the ongoing work.

Kanban is well-suited to work that requires steady output, like production or support and 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.

More about Kanban | Kanban vs Scrum | Kanban tools | Kanban: Successful Evolutionary Change for Your Technology Business

Scrumban methodology — limiting work in progress like Kanban with a daily stand up like Scrum

Scrumban 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 and tasks are assigned by the team pulling in tasks as they can accommodate them, as in Kanban. This means that work in progress is limited and the development team stays focused on the task at hand rather than worrying about the sprint review meeting and what the team committed to delivering in the sprint.

It’s not all Kanban though — Scrumban retains the daily scrum with reviews and retrospectives to improve the process only used when needed. Furthermore, without the constriction of sprints, planning is done on an as-needed basis rather than around a sprint — which potentially saves time.

Scrumban really just adds some flexibility to Scrum by removing sprints and allowing an adaptive approach to planning. Or you could see it as adding some much-needed structure to Kanban with meetings that can help with collaboration and optimizing the process.

Scrumban can be good for product development where there is an unclear vision, where there are evolving requirements or no clear roadmap and if the process needs to include support and maintenance work in the process.

More about Scrumban | Scrumban Tools | The Scrumban [R]Evolution: Getting the Most Out of Agile, Scrum, and Lean Kanban

Lean methodology — streamlining and eliminating waste to deliver more with less

Lean is a project management methodology focused around the theme of efficiency. Arguably the Godfather of Agile — Lean is all about doing more with less. It starts by identifying value and then maximizes it through continuous improvement by optimizing the flow of value and eliminating wastage.

It’s a theme with principles, rather than a methodology dictating process and things to do. It 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 process or 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. For us this could mean standardizing briefs and approval processes.
Muri is about removing overload — the optimal capacity is working at 60–70%; any more than that and everything slows down. We could apply this to be minimizing the number of projects we’re trying to run through the agency.

Lean is focused on changing 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 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 just fluff, or the way you’ve always done it — and you’ll be thinking Lean.

More about Lean | Running Lean: Iterate from Plan A to a Plan That Works

XP — Extreme Programming methodology– doing development robustly to ensure quality

Extreme programming (XP) is a software development project management methodology which defines values and processes to improve software quality and ensure responsiveness to evolving customer requirements. The values, or principles are very similar to scrum, around simplicity, communication, feedback, respect, and courage.

Where it really deviates from Scrum is in defining rules or prescriptive processes. Some of these are similar to Scrum but there are rules around technical practices around designing coding and testing that make it specific for development projects. These rules include making mandatory; Including user stories, Test-driven development (TDD), Pair programming, and Continuous integration among many others.

More about Extreme Programming | Extreme Programming Tools | Extreme Programming Pocket Guide

Waterfall methodology — planning projects fully, then executing through phases

Waterfall, often referred to as SDLC (Software Development Life Cycle) is a project management methodology theme with a very simple approach that values solid planning, doing it once and doing it right, rather than the agile approach of incremental and iterative delivery. It’s simple to understand because you simply make a good plan, and execute on it.

The project manager tends to be large and in charge, and work is planned extensively up front and then executed, in strict sequence, adhering to requirements, to deliver the project in a single, and usually very long cycle.

Requirements are defined in full at the beginning, at the top of the waterfall, before any work starts. Work then cascades, like water down a waterfall through phases of the project. In a waterfall model, each phase must be completed before the next phase can begin and there is no overlapping in the phases. Typically, in a Waterfall approach, the outcome of one phase acts as the input for the next phase sequentially.

After the plan is approved, there’s little scope to adapt the plan unless absolutely necessary, and changes that are needed usually require change requests. The project then flows through the process from requirements, through design, implementation, testing and into maintenance.

Because of the single cycle approach, in a Waterfall project, there’s little scope to reflect, revise and adapt once you’ve completed something. Once you’re in the testing stage, it is very difficult to go back and change something that was not well designed in the concept stage. There’s also 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 very risky.

Waterfall is generally regarded with some disdain within agencies as an inefficient and passé traditional project management approach. But Waterfall can be a useful and predictable approach is 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 actually provide more predictable end result for budget, timeline and scope.

More about Waterfall | Waterfall Project Management Tools | The IT Project Manager: How to Manage Waterfall Projects

PRINCE2 methodology — controlled project management that leaves nothing to chance

PRINCE2 is a ‘full stack’ waterfall project management methodology that includes principles, themes and processes. It was created by the UK government in 1996 originally for IT projects. ‘PRINCE’ stands for PRojects INControlled Environments. It is a very process-oriented methodology, dividing 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.

The system emphasizes justification of the course taken by a business, and so the first step is identifying a clear need for the project, who the target customer is, whether there are realistic benefits, and a thorough cost assessment. A project board owns the project and is responsible for its success. This board defines the structures for the team, while a project manager oversees the lower level day-to-day activities. This methodology is based on eight high-level processes and gives teams greater control of resources and the ability to mitigate risk effectively.

As a methodology, it’s incredibly thorough — it’s a great framework for how to run large, predictable, enterprise projects. It clarifies, what will be delivered, ensures a focus on the viability of the project, clearly defines roles and responsibilities, endorses management by exception (arguably an agile principle) and similarly to PMBOK, provides a common vocabulary which we can apply to other methodologies. On the flipside, while the principles and themes are great, the process can make it laborious and onerous for small projects.

PRINCE2 is designed for large scale IT projects so would never work in an agency as a project management methodology. However, the emphasis on developing a good business case with KPI’s and value earned, clear roles and responsibilities, managing change and risk are helpful when we consider managing projects for our clients.

More about PRINCE2 | PRINCE2 Tools | Managing Successful Projects with PRINCE2

PMI’s PMBOK methodology — applying universal standards to waterfall project management

The PMI’s (Project Management Institute) project management methodology is not really a methodology but a set of standards which refers to the five process steps of project management, which they outline their Project Management Body of Knowledge (PMBOK). These are initiating, planning, executing, controlling, and closing.

This is not so much a methodology a framework of standards, conventions, processes, best practices, terminologies, and guidelines that are accepted as standards within the project management industry. It contains many processes and techniques of project management by which to evaluate or complete the way you run your projects or the methodology you use.

It is, therefore, more theoretical, a reference guide, which you can be certified in which although popular in IT, doesn’t really fly in the agency world. You can’t actually run a PMI or PMBOK project, but you can leverage the standards to create a universal language and best practice around a project. In comparing to PRINCE2, you could conceivably consider PMI’s PMBOK and PRINCE2 as complementary to one another rather than two different or separate waterfall approaches.

More about PMI | A Guide to the Project Management Body of Knowledge

This is by no means an exhaustive list of project management methodologies. There are methodologies like the Crystal Method, in which project processes are given a low priority, while team communication, team member skills, people, and interaction are emphasized; or the Adaptive Framework methodology in which the project scope is variable, but the time and the cost are constant, making it possible to adjust the project scope during execution in order to get the maximum business value from the project. Still others like PRiSM, Critical Path, PERT, and many, many more exist, but aren’t so relevant to the world of project management in agencies.

How to choose the right project management methodology

Choosing the right project management methodology is important because it defines how we work. Project management methodologies provide the structures that can guide us toward project success or failure.

So when deciding what project management methodology to use in a project, we need to consider the simplicity or complexity of the project, the client, our available resources and the project constraints (including the appetite for change and risk), timeline, tools, and people.

When it comes to project management methodologies, there is no one-size-fits-all that works for all business types, sizes or industries. Whether you’re working in a dynamic environment where there’s appetite for evolution and change, and so adopt an agile methodology. Or if you’re working within very fixed, rigid, requirements, timeline and budget and so adopt a waterfall approach, each project management methodology carries its own strengths and weaknesses.

Ultimately, the methodology chosen should be analyzed on the basis of its ability to deliver the most value to the client, with the least impact on those delivering it, how well it meets organizational goals and values, the constraints the project team has to deal with, the needs of stakeholders, the risks involved, the project size, cost, and of course, the complexity of the project.

What’s the best methodology for digital agencies?

The short answer is that it depends. There’s no right or wrong — it depends on your client, your team and the project.

That said, almost universally, at an agency, putting your head above the parapet and suggesting that Waterfall 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 all 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 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 if they do, what happens if your planning isn’t up to scratch?

In truth, in the digital world, we regularly struggle with accurate estimates. We’re usually working with new technologies, on vague projects. So unless you’re doing the same types of projects over and over again, as soon as you start your project, your plan is probably 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?

Between agencies and clients, there tends to be a pretty fluid understanding of agile. Agile is largely lauded for ‘not being Waterfall’ and 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 and provide them with more opportunities to provide feedback or change their mind continually throughout the project.

They often think that it means that they’ll get more work done for less or that they don’t actually ever have to make a final decision on anything because they can change their mind on what they want, even up to the last minute.

That’s sort of true, but not really the whole story.

The catch and the rest of the story is that that level of flexibility is expensive — yes you can pivot and change your mind but it eats up time, and time costs money.

Another challenge is that in order to be successful, and truly agile, clients have to make themselves available and be empowered to make decisions (which is rare in hierarchical, and board orientated organizations), and provide ongoing feedback and prioritization on the fly to keep the project moving. That is often very tricky.

In many ways, it comes down to trust. Do clients really trust the agency to deliver value and are they willing to pay for failure on the path to success? Fundamentally, agencies want to get paid for the work they do, and clients want agencies to do their best work, right, first time. There needs to be some happy medium.

Doing more for less and eliminating waste is a great Lean principle, but the challenge with the approach is often with the client-agency relationship; a lot of waste is caused by clients and without a truly embedded client, with real decision making power, and lots of mutual trust, no amount of agile project methodology can fix that.

But where there is mutual trust, and willingness to experiment, it can create the right conditions for magic to happen. Truth is, agile might be better, but agile doesn’t come cheap or easy.

So agile could mean applying a whole range of different approaches, from Scrum to XP — the best approach is to pick and choose what works best for you and your team, to deliver the most value.

It requires a maturity from our clients to understand that we can’t define exactly what they’ll get, or when, but with some healthy trust, we’ll work together to deliver the best we can.

In conclusion

Selecting the most suitable project management methodology can be tricky. It depends on so many variables, many of which are outside of our control.

But here’s what really matters — looking beyond the methodology ‘turf war’ in the industry. The project management methodologies are just tools to help us deliver projects. It’s really not worth arguing over the final details of a methodology — instead we should be focusing on the bigger picture. Whether it is Kanban, Waterfall, or some other method, it doesn’t really matter.

What matters is to a commitment to doing quality work, that meets user needs, and delivers great value to our clients.

The best methodology is one that’s continually and organically improving, adapting and through strong collaboration increases the value of the output so the sum is much greater than the parts.

It’s a methodology that surprises and delights the client by delivering value frequently, and getting it right. And to do this you need to be pragmatic, rather than dogmatic about the methodology you use.

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.

This article originally appeared on The Digital Project Manager.