In a previous article, I wrote about how outsourcing and utilising the skills of specialist firms, vendors and managed service providers (MSPs) can be an excellent way of gaining access to additional capabilities and expertise. It avoids the need to develop all capabilities in-house, and can enable focus to be retained on those areas where true competitive advantage can be gained.

 

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?”)

 

Conclusion

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.

 

If you’ve enjoyed this article don’t forget to subscribe.

 

 

---

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.