Implementing any kind of meaningful change in an organisation is rarely easy. Even the most successful project is likely to hit a rough patch now and again where something unwelcome and unexpected happens. Good risk management can minimise the problems, but even with this in place there can be unanticipated situations that hit us from the left-field.
Colin Powell is quoted as saying “Bad news is not like wine. It does not improve with age”. In situations where problems occur, it’s crucial that we assess the impact, understand the available options, engage and communicate with our key stakeholders, sponsor or client. This can often be a difficult conversation – but much better to have a difficult conversation early than an awkward conversation later! Bringing issues to the table early allows us to discuss a range of options that might not be available if we hold fire until the fire burns out of control. The longer we wait, the more time we burn – and the options we have start to evaporate.
However, when working as an internal business analyst, or even when working for a vendor or managed service provider (MSP) delivering a solution for a client, situations can be complicated. Some environments can be politically charged, and there might be the perception that speaking openly can be rather career limiting. When working with an external client there may be the added risk of losing an entire series of contracts—which would not land well!
Yet, in most circumstances it is best for us to heed Colin Powell’s advice. A diplomatic, open and honest conversation now, while the news is fresh, is better than an awkward and embarrassing conversation in six months’ time when the situation has festered.
So how can we ensure that these conversations are fruitful? The following tips can be useful:
One common activity to outsource is the development, maintenance and configuration of software applications. This might involve buying a standard package “off the shelf” and gaining help to customise it, or in other cases it may necessitate the design and development of a completely bespoke system from the ground up. The effort required can range from a small enhancement requiring a few hours development and testing, right through to gargantuan projects requiring large multi-disciplined teams.
I’m sure everyone reading this blog will have had some involvement in a project of this nature—whether on the supplier or client side. Perhaps you’re a developer, a business analyst, or a subject matter expert that helped input to the project. And if you’ve been on a project of this type, I’d bet that at some point something didn’t go to plan. In fact, if you’ve worked on a large and high-profile project, there were probably times of stress when unexpected problems emerged from the shadows like sinister spectres from a Hollywood horror movie. Whether waterfall, agile, incremental or iterative—the one certainty with projects seems to be that something unexpected and unwelcome will happen. And whilst good risk management may help us mitigate the impact, we’re unlikely to eliminate it completely. That’s before we start to talk about the unknown unknowns.
It strikes me that there are two very different ways an organisation can respond:
Response A: Play the blame game: When trouble emerges, a deliciously tempting option is to immediately apportion blame. Typically, the client and vendor or MSP blame each other. Things soon get heated. You can imagine a client saying;
“Why are there so many delays in getting this simple feature implemented? The supplier is in breach of contract!”
The vendor may have a different view;
“There are good reasons for the delays. None of their stakeholders were available for interview, we never got any requirements from them, and they forgot to mention the 27 other legacy systems we’d need to interface with!”
In reality, both perspectives may be valid. Yet, apportioning blame just entrenches people in a lose/lose turf war where political games are played for pure political gain. People start spending more time sending e-mails and writing extensive documentation to “cover themselves,” rather than undertaking productive work. Documents become unnecessarily heavier, communication becomes unnecessarily formal and this clogs up the development process. The schedule slips further…
Very soon, relationships deteriorate further. Dialogue becomes confrontational, and everyone works long hours. After several weeks working 14 hour days, the key stakeholders burn out and quality suffers. Everyone resents the project, everyone is blaming everyone else. The project is just about pushed over the line—and when it is the vendor and client walk away from each other. Both are left with a sour taste in their mouths, and all their staff are in serious need of a vacation.
Response B: Acknowledge the root-cause, pivot to deliver: This is at the opposite of the spectrum. When trouble emerges, the client and vendor or MSP have an open and frank dialogue. Each works to understand each other’s point of view. Discussions about blame might need to be held—but these are deferred. What is important now is to understand the root cause, generate options, get things moving and prevent problems recurring.
These conversations aren’t easy or comfortable—but, when carried out ethically and with integrity they work. Conversations are held often, allowing potential problems to be discussed as soon as they are identified. Problems are kept in plain view for all to see—nobody tries to subvert the truth or paint a better picture of progress for political advantage. There is no hiding of bad news.
Collaborative task forces work to resolve issues. When an approach isn’t working, the team pivot rather than doggedly sticking to an ineffective path. This pivoting happens at multiple levels—from the everyday detail (“That two hour status meeting is pointless, couldn’t we find another way of staying in touch that doesn’t burn our diaries?”), right through to the fundamental (“Our business environment has changed and we need a significant change to scope, but we need to manage it within our existing budget. What can we achieve within that constraint?”)
The culture and leadership directly cultivate the environment in which this choice is made, but as practitioners of change, we all have the ability and responsibility to ‘nudge’ our projects one way or the other.
I know which environment I’d rather work in…
So, what’s it to be? Response A or Response B?
How do you help avoid the blame game? What are your experiences and tips? I’d love to hear from you. Please add a comment below.
This post was brought to you by IBM for MSPs and opinions are my own. To read more on this topic, visit IBM’s PivotPoint. Dedicated to providing valuable insight from industry thought leaders, PivotPoint offers expertise to help you develop, differentiate and scale your business.
As many of you know, I’m enthusiastically believe in the value that good quality Business Analysis can bring, and I love speaking,writing and presenting on this and many other topics! In a break from my normal ‘blog style, I have a very quick update for you.
The conference is always a highlight of my year, as it provides a real melting pot of ideas. It’s a great place to meet other BAs and exchange knowledge. There are fantastic presentations from real-world practitioners, and there’s also the opportunity to relax and chat over a beer (or two) after the conference has closed. If you haven’t been before, I’d highly recommend taking a look.
The conference is being held in London, from 21 – 23 September. You can find full details of the conference here:
In today’s blog post, we break from our usual format to bring you an interview with Paul Ranson of Smash Thinking. I first met Paul at an innovative business conference a few years ago, and I’ve really enjoyed hearing about his innovative approaches to leadership and getting things done.
Paul has been managing development and programming of graphically rich applications (mostly video games) since the 1980’s. He has been the go to resource for blue chip organizations across the planet making innovations for companies as diverse as Nissan, British Aerospace and Tesco. He is a passionate reader of business books and has introduced new techniques such as Agile, Lean development or Visual Communication at the businesses he has worked at.
I recently caught up with Paul for a ‘virtual’ chat, and Paul shared some really interesting insight:
1. So your background was games design and development — that sounds exciting! What challenges did you face, and what techniques did you find to overcome them? Are these challenges specific to the video games industry?