Introduction To Project Management Methodology

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.


Scrum is a project management methodology which 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 of 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.


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.


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 optimising the flow of value and eliminating wastage.


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 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 actually provide more predictable end result for budget, timeline and scope.

Choosing The Right Project Management Method

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 organisational 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.

Request for proposal

A member of our team will review your request immediately and will respond within five business days.

To respond to your request, your details may be shared with our partners and transferred and/or stored across borders.

Submit RFP

Share This

Copy Link to Clipboard