“What is a blocker?” is the question any project manager should be able to answer. In fact, any type of manager should answer that question. Even further, she should be ready to answer all subsequent questions, such as “why is this a blocker?” and “how can we remove it?”. In this brief article, we explain blockers in project management – and you will find here all you need to know.
What is a Blocker?
Well, the name is pretty clear already.
A blocker is anything that blocks your project and prevents it from moving forward.
It doesn’t have to completely stop you, if it slows you down to the point that you may be unable to meet your original timelines or commitments, then it is a blocker, even if you are slightly moving forward.
Of course, a blocker can come in many form: unforeseen event, a dependency your project needs to rely on, missing equipment from a vendor, an adverse regulation that prevents you from doing whatever you are trying to do. Blockers are hidden everywhere, so it is important that you know how to spot them.
Now, if you come from a traditional project management background it may be the first time you hear the concept of “blocker”. This is because an agile term. In a waterfall approach, all activities are scoped quite well in advance and there are little surprises down the road (it goes without saying, this approach works well only for repeatable activities). If you work in uncertain industries, like in tech, agile is generally the preferred method. Here, activities pop out with little notice, and blockers do as well.
So, if a blocker is something that impedes your project, you need to know how to identify it in advance.
How to Identify a Blocker in Project Management
There is no easy way to identify blockers, because blockers are subtle, and not all blockers can be identified in the same way or with the same advance notice. Nonetheless, here are some ways I find useful to identify blockers.
Daily Standups
Daily standups are an important tool in agile. Every day, the team meets for 15 minutes and everyone answers three simple questions:
- What did you work on yesterday?
- What will you work on today?
- What is blocking you?
Of course, the question “what is blocking you?” is the key to identify blockers in a project. These are blockers at individual level, so what is blocking a person does not necessarily block the entire project. What you should be looking for here is a pattern: are multiple people blocked by the same thing? Does the same blocker continue to be mentioned over and over? That may be a symptom that it’s worth diving deeper to understand what is going on.
Use daily standups to sense blockers in advance, and then probe deeper.
What-If Analysis
Another important tool to identify a blocker is a what-if analysis. This is a sort of mental exercise (often executed in Microsoft Excel) that stress tests your project to potential events that may happen. Here, you can let your creativity go while. Start to ask yourself questions:
- What if the vendor is 2 months late?
- What if we run out of inventory?
- What if our ship sinks?
- What if we did the math wrong and we need to rebuild this part?
- What if this module does not work, what are the alternatives?
Try to construct a scenario for every case, and think what you could do if those unfortunate events were to happen. You will find that some can have an easy or at least feasible mitigation that won’t jeopardize your projects. Others, instead, may pose serious threats and should be monitored carefully.
If you know what would kill your problem in advance, you can pay close attention to that value so that you avoid the worst.
5 Whys
The 5 whys techniques is used for a post-mortem analysis: after a problem has occurred, you use it to find the root cause. The idea is, if you fix the root cause, the problem will never happen again. Of course, this works in hindsight, but the lessons you learn here will help you remove blockers in the future.
So how does it work? You keep asking “why?” whenever you come up with an answer, until you find you cannot dive any deeper. Let’s take a look at this example:
- (The problem we are trying to root-cause) I drove through a red traffic light. Why?
- Because I was late for work. Why?
- Because my alarm did not ring. Why?
- Because I did not check the batteries the night before. Why?
- Because I never check the batteries consistently. (Root cause)
Solution will be to ensure you check the batteries of your alarm every so often. So, you need to do something similar for your projects that have experienced a blocker to identify why this blocker came to be. In this way, you will be able to identify the root cause and the early signs early in the process, before similar blockers hit other projects you are doing.
Project Blocker in Summary
Unfortunately, there is not much to say – or there is too much to say – about blockers. Blockers are insidious, and you will never find a manual “if this happen, do that”, because blockers are different based on different projects, people, circumstances, and context. All in all, there is so much uncertainty that finding and removing blockers is a soft skill.
It is easy to describe, but hard to do. It’s easy to grasp: a good project manager will identify blockers in advance and remove them. How to do that, unfortunately, takes only practice.
But if you start with the mindset of searching for blockers before they come to hit you, will be halfway there. A good way to start is with clear ownership, and you can do that with a proper RACI matrix in place.
