For many of us who are immersed in the world of project management it is common to hear the term project management methodology. However, the term "methodology" is not my favorite, and I feel it comes across more as a failed attempt to make all projects the same. But what is a project methodology? Why is a project management methodology a double-edged sword? Is there no standard?
First, we need to agree on what methodology means. So let's get started.
What is a project management methodology?
Methodology (...) refers to the set of rational procedures used to achieve the objective or range of objectives governing a scientific investigation, a doctrinal exposition or tasks requiring specific skills, knowledge or care.
Definition of Methodology in Wikipedia - February 3, 2021
https://es.wikipedia.org/wiki/Metodolog%C3%ADa
The term methodology refers to a set of "sequential steps" or even orderly procedures that must be followed to achieve a goal.
When we talk about project management methodologyWe are talking about a sequence of steps that must be followed in order to run a project correctly - which does not necessarily mean the same thing as successful.
Important! Good project management is not the same as a good project. Sometimes the best thing a great manager can do is to request early termination or suspension of a project. For example, if something changes in the context that invalidates the assumptions or hypotheses on which the project provides value - it's rare but it can happen.
Many people perceive the methodology as a kind of instruction manual that defines how to manage projects in a certain context - such as an organization or an area within the organization.
Advantages offered by a project management methodology
Methodologies in general offer structure and order. So then, those who start in the world of project management see in methodologies, a sort of path to follow. However, this is not the only benefit. Among the advantages of a project management methodology we find:
Concepts and terms: Clarity
Methodologies offer a common language. Something very necessary in the corporate environment. Many times project terms can be confusing for people and even result in ambiguities due to other definitions in the company.
The first benefit of a methodology is the creation of a "shared understanding".
2. Life Cycle: Definition, Stages and Controls
Methodologies, by their structured nature, must define the project life cycle. Although each project is different and unrepeatable, the life cycle is almost always the same within an organization.
For example, for a consumer goods company that carries out some projects for operational improvement, you can define the following life cycle.
- Formulation or ideation - initial definition of the project.
- Validation - seeks to answer how important it is to carry it out. Sometimes it validates how aligned this project is with the strategy and how much impact it has on the advancement of one or more of the strategic objectives.
- Feasibility - financial and technical evaluation of the project to determine if it is feasible to do so.
- Planning - how is the project to be carried out?
- Execution
- Closing
3. Best practices: Lessons learned
The methodologies also provide solutions to the most common needs of projects within an organization. Among them: how communications should be managed, how tactical project objectives are established and followed up. Just to name a few.
4. Management tools: Organizational assets
Similarly, methodologies offer a list of tools - often including templates - that can or *should* be used in the management exercise itself, ranging from innocent recommendations to obnoxious formal budget requirements in specific spreadsheet formats or formats with useless headings such as "date of format" and "date of preparation of document" that, far from being useful, only add space in text documents.
A good methodology reminds project managers what tools are available - such as what platform we can video call on or what tools we have to track tasks assigned to project teams.
5. Control Mechanisms: Metrics, Indicators, Control Limits and Gate Controls
Many methodologies delve into control models. A clear legacy of command-and-control organizational models. In my opinion, most organizational methodologies exist for the sole purpose of strengthening control and visibility over progress and risks. Thus, they define metrics - things to measure, indicators - relationships of metrics against expectations or plans, and control limits - when an indicator goes from "doing well" to "concerned" or "doing poorly" and often associated with the color of a traffic light (green = doing well, yellow = concerned or under observation, red = in trouble).
Among the mechanisms, which I could also include among the practices or tools, we will see a set of performance indicators - many of them linked to earned value, or plan vs. progress.
Likewise, many methodologies, promote gate controls - gate check – or mechanisms for evaluating a project as it moves from one stage to another in the life cycle.
Project life cycle
To the untrained eye, it may appear that the life cycle is related to the waterfall paradigm, or waterfall. Be careful, projects are temporary instruments and, therefore, projects have a beginning and an end, i.e. a life cycle. Even projects managed under an agile paradigm are temporary.
It is possible that the phases of a project managed under the Waterfall paradigm are seen as the same as the stages of the life cycle. But they are not. The life cycle goes beyond the very existence of the project.
Something similar happens with the product life cycle. This can be managed under the agile paradigm. Thus, projects will compete with each other for access to the resources that manage the product. In the "most agile" operational models I've seen, project requirements are broken down into the products to be modified and thus compete within the backlogs. This topic requires a bit more, so I promise an article on the subject in the near future.
Relationship of Project Methodologies and Management Paradigms
But wait a minute! Are methodologies the same as management paradigms? Definitely they are not. There are paradigms or contexts where projects (or phases thereof) are "defined and executed" and there are management methodologies. To explain the difference with an example let's suppose you are a renowned chef and you want to open two new restaurants.
The first is a new location of its most renowned restaurant, with its famous dishes already defined and a sort of replica of the others. This is a problem that, without many unforeseen events, already has a predictable outcome. The best you can do is to take your experience (and that of your staff) and repeat, with some adjustments and improvements, the process you have taken in the past to set up other locations.
Conversely, your other project is to open a restaurant, outside of your comfort zone, in a new country, or in a new format, such as fast food, food truck or something you consider radical. While it's good to have a plan, the process of experimentation you should follow to create something new can't be pre-written.
If you want to know more about the paradigms in project management I invite you to read my article Which one is better agile, predictive or hybrid?
Most popular project management methodologies
Well, this topic of methodologies and paradigms is very interesting, but let's see which are the three most popular methodologies for project management at the moment.
PMI Project Management Methodology
If Mr. PMI existed, he would be ashamed of the above title. There is no such thing as "PMI methodology".
Today, the PMI - Project Management Institute - is globally recognized for its work in formalizing and specializing the work of project management. In this work, one of its products - or most outstanding results is: The Project Management Fundamentals Guide, which in English is known as PMBoK Guide -. Project Management Body of Knowledge (pimbok in Spanglish and not pimbuk).
Although historically, the PMBoK was initially a very prescriptive document, today it is a document that is divided into two main "blocks".
The first, a sort of explanation about the profession, the roles within the context of project management and some organizational structures that can enhance the exercise and the results of the projects, and the second, a sort of structure of practices and tools ordered by "context" and "domain" that serve as a tool to understand "what is done" in project management.
The release of PMBoK version 7 is pending, which is undoubtedly a major transformation and evidence of a wonderful evolution within PMI itself - as an organization and as a voluntary association - that speaks of values and guiding principles, and de-emphasizes the hopeless idea of "the steps to run a project".
PMBoK process groups
An important clarity, process groups are divided into initiation, planning, execution, monitoring and control, and closure. Again, the careless eye will say "the phases" of the project, but NO! NO! NO! NO! and NO! Why?
- Monitoring and control cannot be a phase. Imagine that you in your restaurant leave the new location ready and go away for a week and come back to "monitor and control" how the launch went. Regardless of whether the launch went well, regularly or badly, it has already been done! What control can you exercise over something that has already been done?
- It's the tasks you perform on a daily basis that you could "classify" in these contexts, for example: a) planning meeting for the week's work, 8:30 a.m. (guess which group of processes we could be talking about); b) at 9:30 a.m. a new supplier joins the project, just at the scheduled time, and it is necessary to launch that participation (kickoff); c) at 2:00 p.m. you must perform a performance evaluation of your team members, since the cycle in the organization is completed and it is time to assess the progress in the career plans of some members.
As you can see, these are two particular reflections that clearly explain why the process groups are NOT the project phases.
Why is PMBoK not a methodology?
As I said earlier, PMBoK's heritage is strongly prescriptive, but for several years now the guide has become more of a sort of "dictionary" of practices and tools (in part 2) and a sort of "reflection" on the purpose of management in part 1.
Nowhere does it tell you what steps you need to take to structure, plan and execute a project. You or your organization should assess what practices the PMBoK documents and whether, within their business or personal paradigm and context, that practice brings value to their project and the project management exercise itself - something we call tailoring.
If PMI is not a methodology, why is it listed first?
To Caesar what is Caesar's. Although PMI today does not offer a methodology in its PMBoK - perhaps it suggests them in other documents - it is undeniable the influence of this document in many methodologies implemented in organizations today. Hence the famous expression "PMI methodology". These "methodologies" are, at best, a serious and consistent work of analysis of practices to apply "some" in the company and its projects.
Side note: Unfortunately many people did not study well the PMBoK and instead of understanding and adapting, they used copy and paste, and created methodologies where you had to apply each of the practices presented. What a real stupidity! Can you imagine buying a dictionary and trying to write a document forcing yourself to use all the words in the dictionary? You can't imagine how many times I've seen that scenario in real life.
Scrum Methodology
Scrum fanboys are going to jump with this title. And they are partly right.
Unlike PMBoK, Scrum is much more prescriptive. It is so prescriptive that to deviate from the norm is considered a Scrumbut. The parents of Scrum call it a ".Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems."if you don't understand that last part, you can read this article.
Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.
The 2020 Scrum Guide
Scrum Events
Scrum defines some events and a sequence for their execution. And although they are few, in my opinion they are like a method (that's why it appears in this list of methodologies).
Some people call the events "ceremonies" or "rituals," but in truth they are just making up words to differentiate themselves.
Scrum, however, leaves many things undefined, and this "lack of information" can be a great power and a great responsibility. For example, what is and how is the backlog managed? Why are there idiots who say that backlogs can only have user stories? What are user stories anyway, I don't see the term in the official guide? What are story points, why are there idiots who say that only with points I can use stories? Again, what are user stories?
As you can see, Scrum is simple to understand and, without a doubt, one of the work models that I like the most. However, is it good for everything? OF COURSE NOT!
PRINCE2 Methodology
In the context of PRINCE projects it is an abbreviation for "PRojects IN Controlled Environments". And, of the three mentioned it is the only one that considers itself a methodology.
Although not very popular in America - due to the influence of PMI itself - PRINCE2 is the norm in the English context and in its former colonies and other territories with strong UK influence.
PRINCE2 sets out, in a clear and prescriptive manner, principles, aspects - themes - and processes.
If you are new to the project context and allow me to give you a tip, read the official guide to PRINCE2 can be liberating - the opposite happens with PMBoK versions 4, 5 and maybe 6 which seems more like torture.
Agile Methodology? LEAN Methodology?
Well, if you were looking for a list of potential methodologies, you won't find it here. Surely you can search the Internet for titles like Agile Methodology in your projects and you will find many results, but remember that giving it the title does not make it a formal and popular methodology.
Apply principles and values in project management methodologies.
Now, these terms are created by people trying to apply - right or wrong - the principles and values of a line of thinking (like LEAN or AGILE) to the context of projects. And of course it is possible, you can define your own Agile methodology, but that does not make it a Global methodology.
What's more, PMI itself, with its 50+ years of history finally understands the value of principles and values over prescriptive processes. Something that in the "agile" world was laid out in the Agile Manifesto 20+ years ago.
Useful tips for defining a project management methodology
No methodology, in its prescriptive nature, can anticipate the needs and challenges of projects in organizations. However, not having a methodology - or framework as they try to call it as they become more flexible - can be a headache for management itself.
For this reason, I leave you with these tips dictated to me by my experience in management consulting and project, program and portfolio management.
5 key tips for defining a project management methodology
- Avoid reinventing the wheel. The standards and guidelines have been there for many years and are the result of the work and experience of hundreds or thousands of people over decades. Assuming they are wrong is a mistake.
- Seek community support. Professional associations of project managers, both global and local, are very active and collaborative. You might be surprised. I once said at a conference that it was easier to ask for help from someone in the association - in my case PMI - than to go to an embassy for logistical support. There is more likely to be a group of volunteers where I am, than an embassy or consulate.
- Read, apply, learn and adjust. This is just a tweaked version of project management's favorite cycle, the PDCA cycle. Defining a methodology is a continuous process of learning and consolidation. Abandon the idea of designing - at the first attempt - the perfect methodology.
- Move away from absolute prescription. Having room for divergence in management will allow project managers - who know each particular project better than anyone else - to decide on the best management tools.
- Categorize the projects. I am not a supporter of the "one size fits all". By definition, projects are unique. Why insist on the idea that all timelines or work plans look the same?
Did I miss one, do you want to suggest another one, do you agree or disagree, leave your comments and let's open the debate!
