02 Feb Project Management Methodologies and Frameworks
What are project management methodologies and frameworks and how did we end up with so many of them? To answer this, we first need to understand the roots of modern project management.
The Roots of Modern Project Management
People began formally managing projects in the 1950s. Before that, projects were managed on ad-hoc basis using Gantt charts and other tools. But in 1950s, corporations and the US government decided to manage project more systematically; so, they invented two project-scheduling models – CPM and PERT.
Both models were used for the same purpose (estimating and planning activity), but for different types of projects: if you had a project with a lot of moving parts and high unpredictability, you’d use PERT; otherwise, you’d use CPM.
The introduction of those two models is very important because it marks the shift of mindset from “every project can be managed using the same tools” to “each project is unique and requires a certain set of tools to be successful”.
Once we began studying project management as a science and discovering project archetypes, we were able to come up with recipes: if you are run a type A project, you should use these tools; if you run a type B project, use these tools instead.
Back then, there were no formal methodologies like today. Instead, you had a few approaches and you’d use one over the other, depending on what kind of a project you had.
As project management spread across a wide variety of industries, we had to tailor each approach to our specific industry and its type of projects. For example, agile methodologies are great in software development but they don’t work in construction or health care.
After some time, we began bundling methods and techniques into methodologies. You can think of methodologies as surefire recipes we follow so we can run our projects consistently on time and within budget – consistently being the key word.
Why there are so Many Project Management Methodologies
Just because some methodology worked on one project doesn’t mean it will work on another. So we customize a methodology, slap a new name on it, and begin selling it as a new silver bullet to all our problems – only to end up with the same problem: the methodology works on some projects, but not on others.
In addition to methodologies, we also create frameworks. They are more prescriptive than approaches (like waterfall or agile) yet more flexible than methodologies.
Each methodology and framework is suited for a different type of project. Because there are many types of projects, there are many types of methodologies and frameworks. It’s in our human nature to want certainty and magic formulas (in a field where that isn’t possible), so we continue creating new methodologies and frameworks each day.
Each methodology and framework comes with its unique set of strengths and weaknesses:
- some are great for enterprises, while others for small autonomous teams
- some are optimized for projects with a lot of variables and uncertainty
- some are for projects where requirements change frequently
- some are for developing a product while others for providing a service
- some focus on controlling costs and some focus on controlling time
- some are for software developers while others for other departments (eg. marketing)
The Difference between a Methodology and a Framework
In project management community, there is no agreed understanding whether something is a methodology or a framework. There is an agreement on definitions (what is a methodology and what is a framework), but when it comes to applying those definitions, there’s a big disagreement. For example, some experts label “Event Chain Methodology” as a framework even though the name says it’s a methodology.
To further complicate the whole thing, professional project managers use the words methodology and framework interchangeably.
Here is the main difference between a methodology and a framework (at least in theory):
A Framework provides structure and direction on a preferred way to do something, without being too detailed or rigid. They provide guidance while being flexible enough to adapt to changing conditions or to be customized for your company while utilizing vetted approaches.
A Methodology is an approach to doing something with a defined set of rules, methods, tests activities, deliverables, and processes which typically serves to solve a specific problem. Methodologies demonstrate a well thought out, defined, repeatable approach.
As you can see, the difference between a methodology and a framework is in the level of granularity: the more rules it has, the closer it is to being a methodology on the framework-methodology spectrum.
There’s a running joke in the project management community that illustrates the nature of methodologies: “The difference between methodologists and terrorists is that you can negotiate with terrorists”.
In contrast to a methodology, a framework doesn’t give you answers; rather, it guides you through a set of questions so you can develop your own solution and policy.
This all ultimately means there is no official classification which you can consult to get a comprehensive overview of all the project management methodologies and frameworks out there. And creating such a thing is impossible. Each classification you’ll run across is arbitrary (just like the one you’ll find here) and it’s your job to piece everything together and make sense of it.
How To Use Project Management Methodologies and Frameworks
In the end, whether something is a methodology or a framework doesn’t really matter. What matters is how far you take the concept and whether it works for your particular project.
If you take a method and create a system around it, you’ve created your own methodology. In that case, congratulations! Now you can promote it, teach it, issue certifications for it, and make a nice living as a project management consultant.
Methodologies/frameworks are only good if you’re practical about them and implement stuff within reason. If you take them off the shelf and force them upon the business, it will end badly. This happens all the time with ISO 9000, ITIL, and similar certifications.
On the other hand, if you actually learn and understand the methodology/framework, adapt it to fit your needs, and roll it out properly, you’ll end up with something valuable.
The main problem with methodologies happen when companies jump on board because something is a hot topic at the moment. You need to understand that implementing a methodology/framework takes years of hard work.
For example, the reason a lot of people think Scrum sucks is because a lot of companies jump into it head first, buy a ton of “Scrum products” and force everybody to change their terminology. Then things get broken, while the company keeps bragging how they are a Scrum shop.
Implementing a methodology/framework does not mean throwing all your existing processes out the window. Instead, it’s about slowly changing company culture and the way you think and work.
Note: when you hear someone uses waterfall or agile methodology, it doesn’t mean they use a methodology called waterfall – instead, they use word “waterfall” as a shorthand or an adjective, meaning they plan the whole project upfront and then execute.
General Project Management Methodologies and Frameworks
- Traditional Project Management
- PERT Network Chart
- Critical Path Method (CPM)
- Critical Chain Project Management (CCPM)
- Adaptive Project Management
- Extreme Project Management (XPM)
- Six Sigma Methodology
- Theory of Constraints
- PRINCE2 Project Management
Project Management Methodologies and Frameworks used in Software Development
Waterfall Project Management
Agile Project Management
Scrum Project Management
Kanban Project Management
Extreme Programming (XP)
Rational Unified Process (RUP)
Crystal Methods
Feature Driven Development
Joint Application Development
Author Activecollab Content Team
https://activecollab.com/project-management-guides/project-management-methodologies-and-frameworks