Skip to main content

Author: Adrian Reed

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…

[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 “ 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.

The Importance Of “No”

I can vividly remember a time at school where a careers guidance counselor gave a lesson on the importance of saying “yes”. They explained that opportunities come and go, they are like items passing by on a conveyor belt. If you don’t grab them, they’ll be gone, and you might regret passing them by.

In general, this is probably good advice—it’s certainly important to deliberately consider opportunities as they arise—but like all advice, taken to an extreme it may actually cause as much harm as good. Saying “yes” to absolutely everything will probably mean that few things get finished, work days expand and become exhausting, and resentment grows (“why am I the only one working at 9pm?!?”). Perhaps you’ve been there…

As analysts, it’s important that we build rapport and good relationships with our stakeholders. One seemingly easy way of doing this is to say “yes” a lot, after all “yes” is the path of least resistance, and it also implies agreement (which is a way of avoiding conflict). Being the person that always gives positive news is a good way to be liked… at least in the short term.  It’s also quite comforting and comfortable to say “yes”, there’s no need to argue or face hostility.

I recently heard a story from a front line worker who had been seconded into a subject matter expert role. An external consultancy was working on requirements for a major replacement system, and they were there to represent their team’s needs. Every time a requirement was mentioned, the consultant would write it down and say “yep, we can do that” and wouldn’t mention it again. When the system was actually delivered, few (if any) of these requirements had actually been met. We might speculate that there was a contractual scope that had been agreed previously, and some of the requirements that were raised were outside of this scope. Whatever the reason, the outcome was a very frustrated user base who felt they had been completely ignored.

[widget id=”custom_html-68″]

Avoiding the “mindless yes” trap

Mindlessly saying “yes” like this might buy some short term gains, but it does so at the expense of long term pains. Saying “yes” to every story, feature or requirement without a discussion about necessity, feasibility or priority will quite understandably lead to an expectation of delivery. As the backlog gets bigger and bigger disappoint and trust issues might emerge. It’s easy to imagine a frustrated stakeholder exclaiming “why is nothing I suggest actually being delivered?!  The tough prioritization conversation hasn’t been avoided, it’s just been deferred. When it happens it’ll probably be even more difficult. Or, like in the example I mentioned above, it might just lead to disappointment and disengagement. The complete opposite of what was intended!

It’s often perceived that the only alternative to saying “yes” is a cold, hard, permanent “no”.  However, this is rarely the case. As business analysts we can often say yes, but at a cost! Surely a more ethical thing to do is to make that cost visible?  Here are some possible examples:

  • “That’s certainly a possibility, but it’s outside of the objectives of the program. It’s possible that the world has changed, and we need to revisit the objective though… shall I book a call with the sponsor to revisit this?”
  • “The initial guestimate from the developers is that this is huge. It’s absolutely possible, but it’d delay the first public release by a month, and it’d impact the testing plan which increases cost. What’s your view with that in mind?”
  • “I can absolutely take that task on. I’m already at full capacity, so the impact would be to delay work on my other projects, and slip the deadlines for the BA work. Are you and the other teams OK with this?”

Here we aren’t saying no, we are providing options, and providing information that will help the decision maker choose.  Of course, each of these examples are simplified, and in reality there would be more discussion, and there will be cases where a flat out “no” is appropriate too.

In summary, whilst saying “yes” might make us popular, it may lead to long term over commitment. We shouldn’t be afraid of saying “no”, or even better saying “that’s possible, and here are the consequences”.

Information Security Isn’t Just About IT

Information security is a crucial consideration for just about every organization in existence today. 

In a world where there is an increased expectation for transparency, privacy and that security breaches will be strictly punished, security should be at the forefront of our minds not just with what our projects deliver but also how we run our projects.

Customers often expect to be able to interact with organizations digitally and this creates additional concerns and risks.  Whilst we should of course keep the clear and present cybersecurity risks front of mind, we shouldn’t ignore the broader information security risks which might have nothing to do with the particular technology or process that we’re working on.  In fact, it’s an opportunity to ask some crucial questions about existing processes that may have emerged years ago that are no longer fit for purpose.

When The Website Is Secure But The Phone Line Is Not…

More years ago than I like to admit, I worked on a project for a company that was developing an online portal for its customers.  Understandably there was a lot of interaction with security experts and architects, some very robust non-functional requirements, and lots and lots of testing.  However, in retrospect we probably made the online processes so secure that even authorized users couldn’t access them!  Having a password that expires after (say) one month is probably pretty irritating if an ‘average’ customer accesses their account once or twice per year…

[widget id=”custom_html-68″]

This created somewhat of a dilemma in the team.  There was a group of internal stakeholders representing customers who wanted to focus on ease of use.  There were another group of stakeholders who had an interest in ensuring compliance and managing risk who wanted to focus on impenetrable security.  The challenge, it turns out, is to find a sensible balance between the two.  Perhaps you’ve experienced this on your projects too?

In examining this dilemma, two very pertinent questions were asked:

  • “How else can customers engage with us?”
  • “What security protocols are there via those channels?”

This turned out to be a very enlightening line of inquiry!  A bit of digging found out that if a customer (or someone purporting to be the customer) rang, they’d be identified based on pieces of information that were held on file—typically things like full name, address, postal code, date of birth and so on.  This sounds sensible, doesn’t it?  But think broadly: who knows this information about you?  Probably many of your neighbors (particularly those who you’ve invited to your birthday party) and a proportion of your colleagues too!

This wasn’t even the worst of it.  The second channel of communication was post.  This was a good few years ago now, and post was regularly received from customers.  It turned out there was no validation whatsoever on instructions sent by post.  “Ah, but we have their signature!” a stakeholder might say.  “Great, and what do you compare that against, is there a master signature for each customer…?”. Awkward silence.

Cybersecurity Is Crucial: But Don’t Forget Broader Information Security

Here we were in a situation where new processes were being subjected to very sensible checks and balances that didn’t exist on other channels.  This creates a useful opportunity to ask: “are we being too risk averse here?  If not, do the same risks exist for other channels? And if so, shouldn’t we strengthen them too?”.

In many cases, it’ll be completely sensible to continue with a focus on cybersecurity on new stuff whilst also tightening up older processes that might not have been examined for many years.  In doing so we help promote a more holistic view on risk, and help reduce the risk of fraud or information leakage.  Whilst large-scale IT system breaches might mean that a huge quantity of data is compromised, and of course we should protect against this, we shouldn’t underestimate the reputational damage of one or two personal records being misappropriated for fraudulent reasons.

As with so much of what we do as business analysts, ensuring a systemic and holistic approach, working with our stakeholders to zoom out and see the ‘wood’ as well as the ‘trees’ is where we earn our crust.