Why Tech Projects Go Wrong

I have been involved in a lot of tech projects across the years. I take a rigorous approach to projects that involve introducing new technology to a business. The idea is to reduce the inherent risk and this has worked well.

However, quite a few times I have been called to other people’s projects to act as an arbitrator. In these cases, travel businesses have fallen out with their technology suppliers for a variety of reasons. The projects are stuck. The travel company may have laid out money for technology that is not working. The technology supplier may be getting frustrated with an ever-increasing amount of resource required to keep a project on track. Usually, lawyers are about to become involved which will incur considerable legal fees, so I have been invited to act as an independent arbitrator to see whether I can get a project back on track.

I thought it might be useful to tell you about some of these projects that have gone wrong, what action was taken to resolve the situations and how the problems might have been avoided in the first place.

Beware of Undocumented Promises

A tour operator purchased a computer system from a very well established system supplier. The tour operator sold package holidays with charter flights. It ran its flights very efficiently, dropping of passengers at more than one destination. For example, a flight would take off from Gatwick, land at Nice to disembark passengers and then carry onto Rimini to disembark the remaining passengers.

The tour operator checked with the system supplier, “Does the system do double-drop flights?” The supplier’s sales director said, “Yes, it does.” You can guess what happened. The system was implemented at the tour operator’s offices and it was discovered that it did not handle double-drop flights. There then ensued a six month period where the tour operator had paid for the system but could not use it. Only when lawyers became involved did the system supplier agree to modify its system to develop the functionality the tour operator required. No doubt the supplier’s sales director believed that the system could handle the double-drop requirement but maybe he/she did not properly understand it.

The moral of the story is to document any functional requirements that are unusual or special to your business, describe these in sufficient detail and have the tech supplier confirm in writing that the requirement can be met.

The More Detail the Merrier

I have been involved in cases where functional requirements were documented but not in sufficient detail. This has resulted in a system supplier meeting the description of the function but not in the way the travel business imagined it should work. Clearly, there is a bit of fault on both sides, the travel business documented its requirements to loosely. The tech supplier did not ask for more detail. I have arbitrated in these situations looking for a financial compromise to be agreed that will allow the tech supplier to deploy resources to develop what is actually required, whilst not penalising the travel business too much.

Both in this situation and the one before, I often recommend that technology suppliers mock-up some screenshots of how a system will look when it will eventually be in use. This really helps the people within a travel business to properly visualise how a system will work.

Sometimes it’s the People …

I was called in to help in a situation where a new system had been implemented at a travel company but it just wasn’t working the way it should. The system supplier had put a lot of effort into trying to get the implementation on track. The travel company was frustrated that it had spent a lot of money and effort getting the system in and it was actually slowing business down rather than increasing efficiency.

When I looked into the situation, spending time at the travel company sitting down with members of staff and management as they worked, it became clear that the senior financial manager at the firm just could not get to grips with computer systems. Unfortunately, some people are just technophobes. I recommended that this person be redeployed and once this was done the system settled down beautifully and produced the efficiency gains that were promised.

… Sometimes it’s the System

Of course, I have been involved in arbitration cases where I have had to conclude that the system is never going to work. This may be, for example, when an existing system needs to be heavily modified. Travel systems are incredibly complex and sometimes they just cannot be modified to incorporate a particular function that a business might require. It would be much easier for all parties if a system supplier was able to simply acknowledge this but, in many cases, the supplier might not know that a system cannot be modified until it tries.

The course of action I have sometimes had to recommend in these situations is for the travel business to walk away from the system and, hopefully, receive a refund of the costs that have been incurred. The system supplier might be relieved to do this. It won’t like losing the money but it gets them out of an impossible project.

Incidentally, system supplier contracts will always have a clause that excludes consequential losses, otherwise one failed project could be so financially penalising that it might require the supplier to go into liquidation. Thus, a travel business should never expect to get back any more than what it has paid.

I could relate more cases but these four will give you a feel for some of the reasons tech projects go wrong.

I mentioned the importance of documenting a travel business’s most important or unusual requirements when procuring new technology. In my next blog, I will look at this in more detail.