Ministry of Technology
Show Menu

Optimising Project Delivery - Blockers

Optimising Project Delivery - Blockers

In my first article in this series I tackled the topic of how conflict between client representatives and empowered teams can be used within an agency to increase profit and improve product quality. I then looked at how an agency can adapt it's resourcing model to create an environment where empowered teams can thrive. In this article I am going to address another key element of inefficiency - blockers (or, more accurately, the communication of them).

Throughout this article I will use the term 'makers' to refer to developers, designers, UX experts and other creatives and the term 'specifiers' to refer to product owners, account managers or any other form of business stakeholders.

What is a Blocker?

A Blocker is any factor that comes into play when attempting to deliver something that gets in the way of that delivery. Some examples are...

  • A piece of work has been provided by Specifiers but there is inadequate information for Makers to proceed with the task.
  • A piece of work requires the creation of another piece of work before it can be completed and this has not been accounted for.
  • A piece of work requires unexpected additional training.
  • A piece of work is on-hold awaiting agreement for an alteration from a client or 3rd party.

There can be many reasons for blockers but the end result is always the same. A task, which the Specifiers would like completed, cannot be progressed until the blocker is removed.

The Importance of Visibility

Blockers need to be communicated as quickly as possible to individuals that are capable of resolving the blocking issue, allowing the work to continue to flow. It is important, as these issues often exist across individuals and teams, that the state of all blockers are quickly and easily visible to all relevant parties including more senior members of the business. This minimises the need for escalation in the event of unresolved blockers as issues are visible to everyone and can be checked up on at any time. This allows the individuals responsible for blockers to be able to focus on removing the blocking issues rather than dealing with other individuals chasing them up.

Techniques for Highlighting Blockers

Aside from the traditional Agile highlights for blockers, which are generally highly project focussed rather than suited toward a multiple project agency environment, there are several options available.

  • THE BLOCKER BOARD - Whether this is an online resource or a physical board is completely dependent on the nature of your management tools and techniques for tasks but the principle is the same. You maintain a board either separate to or alongside your main task board which highlights any blockers.
  • NOTIFICATIONS - With a technical system you can set up notifications via email, messaging or any other communications tool used within the organisation to keep key people updated on the state of blockers.
  • DAILY MEETINGS - This is the SCRUM approach for highlighting Blockers and is quite valid if the organisation has a variety of daily Stand Ups whether or not SCRUM is practised. In SCRUM the SCRUM Master will liaise with the team and others capable of resolving the situation to alleviate the blockers as soon as possible.

Kanban

Kanban applies a different strategy to blockers. Using it's techniques of restricting work in progress, it enforces a scenario of pushing the Makers to aid with the removal of the Blocker in order to clear the production pipeline. This is a laudable goal and, as an organisation becomes more fluid and is structured in such a way that pain points are allocated to individuals capable of rectifying issues (the subject of my next article) it is achievable but until then it can be an ineffective strategy for an agency with teams working across multiple projects.

I'm Blocked - What Can I do?

It is important to have a process to follow when a blocker is identified. Once the issue has been raised and the affected task has been highlighted as blocked in a way that best suits your systems or tools then the blocked Maker can do one of two things.

  1. Create a new task to unblock the blocked task if the blocker is something that they can fix. In this case, the impact of this task needs to be assessed and communicated back to the Specifiers so they are aware of any potential delays introduced and the likely impact. If there are multiple potential solutions then it should be the Specifiers that make the final call on how to resolve the blockage.
  2. If the blocker cannot be resolved directly by the Maker then the blocking issue must be communicated back to The Specifiers with recommended guidance as to how to proceed. The Specifiers will then be able to plan a way forward to remove the blockage. In the meantime the task should remain blocked and the Makers should move on to the next available piece of work until the blockage has been cleared.

Once cleared the time at which the blocked task is then picked up again depends on the nature of the management techniques used within your team for tasks. My recommendation would be that the next available qualified team member picks up the task when their next piece of work is complete, which follows a simple principle from Agile Methodologies of making sure that tasks are completed before moving on to something else. Dropping one task to move onto something else is inefficient and reduces product quality. 

What Next?

In my next article in the series 'Optimising Project Delivery' I'll be looking at pain points and how you can adapt your structure and workflow so that project delivery pain is directed towards the groups or individuals most capable of solving the problems that are the cause of the pain. This is a key feature of an organisation designed to maximise efficiency.