Project Management Methodologies: Which one is better?

Somewhere during project planning, you need to make a serious choice. You need to select the most appropriate project management methodology. The problem is that it may be hard to make corrections later. So, you have only one chance.

The biggest problem is that all methodologies are commercial to some extent. Even if they are created by non-profit organizations. Therefore, you will always hear only about the benefits and advantages of a project management methodology.

It could have been a long and profound comparison. But I don’t believe we need to compare methodologies. It is like comparing a hammer and a saw. These are just different tools for different tasks. Let’s better define good and problematic areas of each one.

But before that, I want you to be precise with terminology.

Frameworks, Life Cycles, Methodologies

When you search for “Project Management Methodologies”, you will get into a mess. The terms framework, approach, methodology, life cycle, and processes are interchanged and confused. Let’s try to clarify this first.

A Project Life Cycle is a series of phases that a project passes from beginning to end. We usually divide a project into phases to meet our control needs. In other words, to make a project more manageable. The nature of a project and the industry also influence the life cycle.

A Project Management Framework is a set of concepts that are used to achieve a project goal. Each framework is based on a set of principles that give some advantages to a client, a project team, or both. These principles also introduce limitations.

All frameworks share common concepts like planning, executing work, and delivering results. On the other hand, frameworks designate a particular set of values. For example, an ability to adapt to changes or the ability to predict the scope, cost, and time needed to deliver a result.

Project life cycle can dictate the specifics of a framework. Does a life cycle or a framework take precedence? It depends on the nature of a project and an organization.

Project Management Methodology is merely a set of strict processes, roles, and artifacts. A methodology is aimed at implementing a project within a given framework. There might be several methodologies that work under one framework.

Most methodologies introduce a specific life cycle. There is no universal standard here as both a project management methodology and a company can modify it.

So, how to choose a project management methodology?

1. You need to understand how different methodologies work and their prerequisites. You should be clear about the strong and weak sides of each one.
2. You need to analyze how your organization works. Does it have a suitable environment, skills, and technical aids to implement any specific methodology? Identify what methodologies are already in use. Make a shortlist.
3. You need to analyze the nature of a project, specifics of the industry, regulations, and constraints. Additionally, you may consider the type of a contract you work with.
4. You need to analyze your ability to adequately define requirements for the end result of a project. It also includes the capacity to reach project objectives and stakeholders expectations. They may change during the project’s lifetime. So, you need to define the optimal way to manage changes.
5. Define the most suitable methodology that complies with the needs identified in points 1-4.

Underlaying Values

Traditional or Predictive approach focuses on identifying project scope, costs, and duration early on. Changes are actively avoided and closely managed. The project team follows the central principle – plan before you act.

The predictive approach helps to develop a project in a systematic way. Moving from project inception to planning, then to execution and closure. This method is preferred when the product to be delivered is clearly understood. Also, when a product only has value when delivered in full.

Adaptive, change driven, or Agile approach is based on principles described in Agile Manifesto. This approach is based on ongoing collaboration with stakeholders. It is intended to accept a high level of changes.

Agile is preferred when it‘s hard to define requirements and scope in advance when the environment rapidly changes, and when the value can be delivered in small increments.

PMBOK® Guide does not describe a project management methodology.

Plan-driven, Predictive, Waterfall, Traditional

I will start with answering a frequent question. No, the PMBOK® Guide does not describe a project management methodology. It is a set of good practices and processes. In most cases, they cover way more than any project would need.

There is an Annex A1 in the PMBOK® Guide. It describes a standard for project management. In general, you can consider as a plan-driven methodology.

Nevertheless, you can use all processes and tools of PMBOK® Guide in other methodologies like PRINCE 2. Or you can combine some of the practices into your own methodology.

GOOD

• Perfect for critical and high-value projects. Plan-driven approaches require you to perform comprehensive planning upfront. It includes collection of requirements, defining scope, developing budgets, and identification of risks. At each stage of a project, you will have a better understanding of your chances for success.
• Good practices cover all aspects of a project. Depending on nature, complexity, and size, you can choose an appropriate set of processes, tools, and techniques. PMBOK® Guide has all the necessary information.
• Traditional methodologies are scalable. With the same set of processes, you can manage small, medium, and large projects, programs, and portfolios of projects. The concepts and principles are the same.

DIFFICULT

• Changes are costly. In general, changes are actively avoided. It does not mean that you can’t make changes. You just need a comprehensive process to manage them to stay within constraints. Nevertheless, you can easily apply the rolling wave planning approach. Just manage unclear, ambiguous parts of a project on a higher level.
• Proficiency is required. You don’t need much knowledge and experience to follow an established methodology. However, plan-driven methodologies usually require monitoring and controlling activities. Which in turn may require changes in the methodology. Without proficiency in plan-driven approaches, it will be difficult to make educated decisions. Thankfully, you can find a lot of training in both PMI and PRINCE 2 approaches. And they provide them on different levels.

Scrum

There is so much talk and resources on Scrum that I don’t want to duplicate the general information here. I would suggest you visit the original sources for the basic introduction.

Here is a great video by Scrum Alliance that explains how Scrum works:

You can find more details in their Scrum Guide.

There are serious debates about whether you must follow Scrum and Agile prescriptions to the letter to get promised benefits. I believe that you need to modify the methodology to adapt to the project’s nature. However, you must have a bag of knowledge and experience for that.

So, I suggest to follow prescriptions to the letter. At least for a few sprints. Check this free book called Scrum and XP from Trenches. It has all the information you need today.

GOOD

• Adaptivity. It is much easier to introduce changes to the product. Well, it is the nature of this project management methodology. And it goes for both product requirements and project processes. Though changes can happen between iterations. Changes to the current sprint are not accepted.
• Iterations are time-boxed. You need to plan in detail for 2-4 weeks of work. It is much, much easier than planning a year-long project.
• Relative complexity estimation. In Scrum, the development team estimates the complexity of a task.
• Number of Role and Responsibilities is small. There are just a few roles in Scrum. It is easy to control work
• Short feedback loop. The Product Owner provides feedback on the progress and current state of a product at every iteration. Change Requests are obsolete in general. Therefore, you will have less amount of conflicts with a customer. His expectations can be closely managed.

DIFFICULT

• Hard to define real Product Owner. Scrum works best when a team can access real product owner. It is a person or a group of persons who will be using the results of your project.
• Scrum (Development) Team. The characteristics of the development team are very demanding. Team members should be self-organizing. This means they should be well-motivated as well as proficient, cross-functional, and mature. They all should be comfortable and willing to work on all aspects of product development.
• It is hard to safeguard Scrum Values. Scrum requires coaching of Scrum values. In fact, it means that a Scrum Master should be good at sales. He must be able to explain why Scrum is the right approach. Moreover, he should ensure that the customer understands why he should follow Scrum prescriptions all the way.
• Organizational environment should be Agile. That is something Scrum framework does not cover. Nevertheless, the performing organization should be ready for Scrum. Both technically and mentally. A Scrum project in the non-scrum environment is usually a disaster.
• Quality assurance may be difficult. By the end of each iteration, you need to provide potentially shippable (to the market) product. Clients and customers like this trait. However, implementing it is difficult. It requires technical aids, robust processes and skilled team. It all takes time. That is not something clients like to hear.

Kanban

Kanban is also an Agile methodology. It implements Lean approach. In essence, Kanban tries to match the work in progress with the team’s capacity.

There is much common between Scrum and Kanban. Nevertheless, these are different project management methodologies. Read this short and highly illustrated book Kanban and Scrum – Making the Most of Both.

GOOD

• Very straightforward and customizable methodology. It has only three prescribed items. The level of adoption is the lowest among other approaches.
• Very Adaptive. In Kanban, changes can happen anytime. Priorities can change in backlog many times per day. Nevertheless, the team will try to get the top priority task through the process as fast as possible.
• Kanban visualizes bottlenecks. With Kanban bottleneck in the workflow become apparent. The development team is focused on removing them by design. Therefore, you have an ability to improve your processes and workflow constantly.
• Kanban allows continuous delivery. You can continuously add features and value to the product. It is up to the team’s discretion when to include an increment of work.

DIFFICULT

• Kanban is too simple. The methodology speaks little about how to get a project from start to finish. It is all up to you. You will need to identify the workflow, definition of done, technologies that will support your workflow, etc. Everything.
• Kanban works best when mastered. Behind the simplicity, there is a sturdy workhorse. Though to get all the benefits, you need a lot of experience, trials and errors, and a good gut feeling. Nevertheless, it is an agile methodology I would suggest you to start from.
• Team should be proficient. As with Scrum, Kanban requires a certain level of skills, motivation, maturity, and personal responsibility. Working with an unmotivated or unskilled team might be difficult.

Which One is Better?

None of them are better or worse. Project management methodologies have particular implications where they perform best. It depends on circumstances, the nature of a project, and the environment of a performing organization.