What do failed IT projects and airplane crashes have in common?

I have often joked to colleagues and clients that I should write a book on why IT Services companies walk blindly into situations that lead to them having troubled accounts – and what they can do avoid such circumstances. Somehow, life kept getting in the way of this notion. However, having left my last company in July and taking the summer off (what there was of it), to spend time with my family, my mind returned to the subject. This article can be considered more of a White Paper or, if I’m feeling really ambitious, a Foreword to the as yet unwritten book.

I confess to being left bewildered as to how a situation could be allowed to get to the point where the supplier company and client were one or two steps away from the courtroom – or contract dispute/mediation/cancellation. After being parachuted into numerous challenging situations, it struck me that all of them had very similar ‘anatomical’ attributes.

For someone who has flown hundreds of thousands of business air miles, you would expect that Air Crash Investigation was not likely to be one of my favorite television programs, but it is. Stick with me here because there is a parallel between the television show and troubled accounts. Not one thing brings a plane down. It’s a sequence of events that combined, lead to disaster. Remove one of more of those events and the outcome would have been completely different. And so it is with troubled accounts.

Typically, most disasters occur on new accounts or what is often termed ‘new logo business’ – companies that have not previously been in a formal relationship. Don’t get me wrong, major programs with existing companies can still go horribly. The chances of that happening are less when you have an established team in place, a good account leader that will not sell, or be allowed to sell, something that is completely undeliverable – that’s just bad business all round.

So then, why is it that new logo business carries the greatest risk of disaster? In my experience it’s all about foundations. Think of it this way. Would you build a standard house without laying foundations? Of course not. What would you expect to happen if you did? Precisely. Neglect to lay foundations appropriately and the house will fall down. Here are the key foundations that will reduce the risk of you ending up with a troubled account:

1.  Develop a solution that can be delivered:

• ensure is meets the technical requirements of the client;
• confirm it meets the business requirements of the client;
• create a simple, solid mechanism for measuring success – technically & commercially;
• commit to timescales that are realistic – don’t get pushed into a delivery date that can’t be met;
• make sure the right skills and resources are available.

2.   Conduct thorough due diligence:

• become intimately familiar with the clients existing environment – there will plenty of nasties lurking deep in the engine room;
• ensure the bid plan has enough time to verify what you think you know – double what you think it should be and then double it again;
• if assumptions are made, get them out in the open so they can be either confirmed or corrected – you know what they say about assumptions being the mother of all …….you get the idea.

3.   Have a Governance process that works:

• so many governance processes are treated like a tick box exercise, a sales obstacle to be overcome or circumvented – wrong, wrong, wrong, wrong, wrong, wrong;
• it’s all about quality not quantity – individuals should not be on the panel/approval list if they have had no involvement with the in-flight deal.  That’s just like having the deluded leading the blind;
• constantly review the Governance process (this should be done against those deals that passed governance but failed in delivery. If this isn’t being done, that’s just plain stupid).

4.    How the Bid and Solution teams hand off to the Account and Delivery teams:

• the account and delivery teams should be an integral part of the sales process, not brought on at the 11th hour to be given a hospital pass;
• consider having the solution team form the core of the delivery team (ideally for 6-12 months depending on program duration). After all, they put the solution together. It will make them highly accountable and they will learn from their mistakes if they at the pointy end of the stick when things go wrong;
• If bonuses are involved, make a majority of that contingent on successful delivery – you’ll be amazed at the change in mentality.

5.  Don’t create an overly complex contract:

• ideally, you should not use the contract to manage the delivery of the service – Statements of requirement, technical and functional specifications (or their Agile equivalents) should the most used artefacts;
• have Service Level Agreements that are easy measure and report on – if it takes an individual days per month to create an SLA pack, you’re barking up the wrong tree;
• conduct a full contract handover with the account and delivery teams – it’s important the appropriate leaders understand the contract completely;
• succinctly define the definition of Done. Ensure everyone is aware of what constitutes success both in terms of initial delivery and ongoing service. The less ambiguity the less pain (apparently).

6.   Establish a partner ecosystem:

• ensure that the key roles on the supplier delivery side are mirrored on the client side;
• creating effective working partnerships across the piece helps build relationships and identify problems earlier;
• act fast if a particular partnership is not working. Some just won’t work, accept that will happen and plan for it.

7.   Is the business side bought into the IT vision and engaging you as a supplier?

• It is vitally important that you know the market in which they operate – how are they are positioned and what the future strategy is?
• What are the desired business outcomes – Is there a solid foundation for the business case and how it will measured?
• Ensure you are able and allowed to build relationships with the business stakeholders. If the Client IT department block this, this is a big red flag.

8.   Be Open and Honest:

• this is a difficult thing to pull off. Admitting when mistakes have been made is hard for us humans (especially the male of the species);
• deliver bad news quickly – don’t sit on an issue hoping it can be solved by sweeping it under the carpet. It will probably lead to grief initially but it will build trust when issues are resolved together;
• be sure to know what the client wants out of the relationship. Managing realistic expectations is a true art form. Don’t just say “the client can think what they like” and carry boldly on. It won’t end well, take my word for it;
• don’t be afraid to discuss profit, treating this as a taboo subject is foolish. First and foremost, this is a business transaction, a company is allowed to make a reasonable profit. If done properly, the client is buying at a price they can afford and the supplier is selling at price that makes money. If this balance is out of kilter too much one way or the other, one of the parties will seek a divorce and you’ll end up fighting over custody of the dog.

If all of the above sounds like an exercise in stating the obvious, it is. And yet here we all are, reminiscing and getting nostalgic about passed disasters and thinking “If only……….”.

Next time, take a moment to reflect and ask yourself; Am I about to do something that will bring the plane down?

Written by John Collier, who has been in Customer Operations, Accounts and Business Management in the demanding Information Technology (IT) sector for 25 years. This article first appeared on LinkedIn.

Tags: airplane, disasters, featured, IT