Skip to main content

Beware The Inadvertent Project Saboteur!

Organizational change is a tricky business. There is seemingly endless ambition to progress change initiatives, but sadly practicalities like time and budget always appear to be at a premium. Having competent people on the team who are capable of getting on and getting things done is crucial.  Yet even with competent people on the team, one perennial challenge is the coordination of work. Even if there were world-class people on the team, if they are working in silos and there’s a lack of communication then there would be a problem.

I find it fascinating to watch how quickly Formula 1 pit stops take place (if you’ve never seen this, there are plenty of examples on YouTube). It’s clear that pit stops have been refined, rehearsed, and improved to the point where tires can be changed in just a couple of seconds. There are clear tasks, everyone knows when the car is coming in, and everyone knows what they are doing and how what they are doing fits in with the broader aim (the broader aim, presumably, being to win the race!). I can’t begin to imagine how complicated the technology and engineering that takes place in formula 1 is, yet still this process has been refined so that it consistently works.

Of course, our lives in projects are significantly different to Formula 1. We don’t have the complexity of tires and engines, but we do have complexity of stakeholders and existing processes. We won’t be changing tires, but we may well be making changes to a customer facing process, IT system, organizational unit, etc. Our work isn’t perhaps as repeatable as a Formula 1 pit stop, yet the coordination of work is crucial.  Imagine if a pit stop took place without the usual choreography, and if one of the engineers had to ask “umm, am I changing the front left or the front right tire…. Oh hang on, I thought you were on the back tires?” It would be far less slick, and possibly even hazardous as the car might come in before it was expected…

Advertisement
[widget id=”custom_html-68″]

The same is true in projects. A lack of communication causes blockages and problems: I suspect this revelation will come as a surprise to precisely nobody. One of the reasons that many agile teams prefer to be collocated (when possible) and have regular catch-ups is to ensure that people’s work can be synchronized.  Yet in just about every project context, one pattern to look out for is the Inadvertent Project Saboteur!

Sabotage With Good Intentions

It might sound strange to say an inadvertent project saboteur, so let me explain.  Sometimes situations occur where time is tight. There is a perception that there isn’t time to have meetings or discussions to synchronize work. Communication probably still happens, but it’s only the things that are ‘on fire’ that are discussed. Lots of email gets sent, but because everyone is so busy fighting fires, only some of those emails get read. How many of us can honestly say that we are always completely on top of our email?

A perfectly competent team member sees what they perceive as a gap. Perhaps they suspect some requirements or stories had been missed, or there’s some functionality that they are sure is required. It’s something that seems small, let’s say it is something like letting an online customer opt to receive a paper copy of their car (auto) insurance certificate. There’s no time to discuss it, no time to document it, no time to trace it back to the objectives/aim… we’re firmly in the province of “JDI” (“Just Do It”). So, with the best of intentions the person does it. They mean to email people and tell them, really they do, but they work late and they forget.

Then there’s feedback from testers. Something isn’t working as expected, there’s a sudden realization that an unexpected change was made. People spend time searching back through tickets and story cards to try and work out why, time is burned, nothing is found. By a chance conversation, the person responsible for the change says “err.. yeah, actually that was me”. Questions are raised over whether this was a good idea, but the sponsor is pressing to ‘ship it’, so it’s swept under the carpet.

All of a sudden the internal training team expresses significant concerns. The application they are training staff on seems different in a few key areas, not just this (seemingly small one), but others too. Again time is burned (and everyone is working even longer hours now) trying to find out why. It seems a bunch of things have been changed and even worse, customers start to complain, the new ‘feature’ works, but none of the supporting processes are there. They can request a printed copy of their insurance certificate, but nobody has built a process to actually send it to them. Urgent work is done to put this in place: then somebody asks “..how does this affect the business case? Wasn’t it built on a zero-paper and entirely online model? Doesn’t this change the entire business model and proposition?”

These are all crazy examples, of course, I’m sure such a plethora of miscommunications like this wouldn’t happen in the real world.  Yet, what this demonstrates is the danger that can emerge when communication subsides and when people get out of sync with why the change is being initiated in the first place.  Competent people with the best intentions will do their best, yet doing something that they genuinely think is best may have impacts elsewhere that they hadn’t envisaged. A Formula 1 engineer might well think that the car’s paint needs touching up, I can’t imagine they’d ever unilaterally decide to get out the paint can during a pit stop! To do so could affect the driver’s final position in the race. There is a parallel with badly considered insular decisions that are made on projects.

Of course, I’m absolutely not arguing for strict separation of duty and huge documents and arduous governance, nor am I arguing for centralized ‘command and control’. What is needed, however, is sufficient communication so that everyone in the team knows enough about what each team member is doing, along with the ability to easily communicate if things change. Cutting down communication at times of stress will often lead to a lack of synchronization, ironically leading to increasing problems and more stress!  We should all be on the lookout for inadvertent project saboteurs and should avoid falling into the trap of becoming one ourselves.

Have you ever seen (or been) an inadvertent project saboteur? What are your views? I’d love to keep the conversation going. Feel free to connect with me on LinkedIn.