Today we’re going to talk about the major flavors of project management. This doesn’t mean various approaches and techniques, but instead, a broader view on how to even select the proper project management techniques for a new project.
Projects have a quality that dictates everything about them: they are supposed to deliver something unique. As such, getting from idea to the objectives is often an uncharted territory. This is the reason for project management’s existence in the first place. Otherwise, we could use the same processes and resources we use for Operations and things would be very simple.
It should be mentioned that this uncharted territory has a varying degree of unknowns. It’s one thing for a car manufacturer to design a new steering wheel, and a completely different thing for a bike manufacturer to do it. In the first case, there is some institutional knowledge there that makes this project less scary: the car manufacturer already knows how the steering wheel works in principle and how it connects to the car’s other systems, whereas the bike manufacturer will have to do all that from scratch.
So, perhaps a good question to help us select our project management approach would be: “how much of an unknown is this project, really ?”. The answer to this question will dictate what kind of approach the project manager will take in dealing with the project. Let’s take a look at the possible answers, below.
Question: How much of an unknown is this project, really ?
First answer: We know exactly what we’re supposed to deliver OR how we’re supposed to deliver it.
There are two scenarios here, but they belong in the same category because both of them will prompt the same approach from the project manager.
So we know exactly what we’re supposed to deliver. This is the most straightforward case in project management. The organization decided on a very very specific result of the project. Our job as project managers is to map the path from the organization’s current situation to the one in the future, which will contain the result of the project. While potentially complex, this is nonetheless a straightforward matter. Yes, we must take into account time or resource constraints, we will have risks, but since we have a shining beacon at the end we will always know what to aim for. The biggest consequence of this is that we can actually plan for how to get from where we are to the future position where the project’s result actually exists. Here, “we can plan” is key.
So we know exactly how we’re supposed to deliver. The second flavor of this situation is that we work in an industry that is heavily regulated or has a specific way of doing things. For instance, in drug research, even though the end result is not really known, the process to get there is made of well defined steps. We would never have to handle human trials before making sure the potential drugs are relatively safe for human consumption, so the approach is incremental. In construction for instance, there are very clear standards and regulations that will dictate the materials to be used or mandatory quantities and qualities per load. In this case, we have some acceptance criteria for the final result (be it a drug that is supposed to help with something or a building of a certain volume or height), and we have some guardrails that guide us on how to get there. In this case, as well, we can plan for it, since we have a clear goal and some loosely defined path to get there.
In both cases above, we can say that the project is plan-driven (because well, we can plan it). This means that the project manager must establish the scope, schedule and cost of the project quite early in its lifecycle. Based on this, the project manager will then make sure that the project goes according to plan - or as close as possible to it. This is the realm of projects that have months long planning phases and where each minute detail is sought and documented before the actual work starts. You might know this as the Waterfall approach, named so because each project stage is supposed to end before the next starts. A classic visual representation of it is the Gantt chart.
Second answer: We know exactly what business benefits we’re looking for, but we don’t know what implementation will get us there.
In this situation, we’re focusing on something other than what the project delivers. Here, we’re focusing on our organization’s or our customers’ needs, while leaving the path to get there blank. This approach is often used in software and innovative projects. Because we decided on the benefits, those become the “fixed” part of the project. We need someone to make sure that value keeps being delivered, by matching the project’s results with the business objectives we established at the beginning of the project.
In this approach, the person responsible for the business objectives will have to periodically check that the delivery is on the right path. To do that, they establish a cadence of verifying the value delivered. Should the value be satisfactory (matching the business objectives of the project), the effort can move forward. However, should the value be unsatisfactory, then the delivery method is examined and adapted.
Because this verification interval is so short, usually two or three weeks, the project can be steered in the right direction very often. So, although the project is mostly exploratory in nature, by having regular checkpoints it can be brought back to the path that delivers most business value.
One thing to mention with this approach is that these types of projects are usually a source of conflict and will test the project manager’s soft skills. The organization or the customer will have some benefits in mind. They may not be able to articulate them well enough for the implementation team to get it right from the beginning, so some work will probably be done without actually delivering business value. In these cases, the friction will appear in the form of “well this was wasted effort, this wasn’t what we needed at all”. The mechanism to control this “waste” is the frequency of the checkpoints when the project manager validates that business value has been delivered. If the frequency is “weekly”, then at most one week of “waste” has been produced. If the frequency is “monthly”, then the potential of “waste” is much larger. We’ve used “waste” to refer to work that has not delivered business value because the project manager must be mindful of it - this is how the organization or the customer will perceive it. It is the role of the project manager (or product owner - a specialized role) to handle these expectations and to remind the stakeholders that this was not waste, but instead expected effort because the project is exploratory in nature.
This is the Agile approach. There are many frameworks that help the team and the project or product manager handle this type of project, and most of them are focused on software development.
Third answer: We know some of the things we want to deliver, but others are new or unknown to us.
This case is a clear combination of the first two answers. For the known portion of the project we can actually plan, so the approach there is Waterfall in nature. For the unknown parts of the project, however, we can leverage our Waterfall plans to clearly describe the Agile approach we would use.
For instance, we could say that we allocate two months of Agile delivery for a key result, along with resources and people, and once that stage is done, we will compare what we achieved with our plans and decide if the rest of the project needs to be adapted or modified in any way.
It should be noted that any project needs to be evaluated periodically, but projects that have both the Waterfall and Agile approach even more so. This is because the Agile part will deliver something that can’t be planned, so whatever plans we made for the Waterfall part will most likely not be correct, once the Agile part was delivered. Because of that, plans that include results from Agile parts of the project should use “degrees of success”, rather than binary “achieved” or “not achieved” for the Agile parts. This way, plans can still be made which remain relevant and would need minimal modifications in the future.
This is the Hybrid approach. One could argue that all projects have at least some unknown pieces of scope and thus an Agile part, but what makes a project Hybrid is the fact that the project manager will actually plan for the Agile approach to use.
Conclusion
This has not been a description of what methodologies of frameworks to use inside your projects. Instead, it was a description of projects’ different types. Based on that type, you can now select an appropriate methodology or framework for your project and have the confidence that it is the right one.
