Managing IT change in any organisation is not an easy task. During my 30-year career as a technology leader in various IT Director roles I have come across six common reasons why IT projects fail to deliver:

1. Lack of a feasibility study

Not carrying out a feasibility study can cause a team to embark on a project only to discover that they cannot deliver the targeted benefits. There are two common reasons for this:

• What you are setting out to achieve is simply not technically feasible. A current example would be the app that was developed for the UK government to monitor the spread of COVID-19. It was kicked off with a big fanfare, but then it turned out that the chosen technical solution could not deliver.
• The second scenario is that, although what you are setting out to achieve is technically feasible, there is a disconnect between the technical outcome and the business benefits that you are targeting to deliver. This is slightly more subtle.

One of the projects that I was involved in was replacing an existing system for property service management. The existing arrangement was that the operatives would go into their local centre at the start of the day, pick up their paperwork and then go off and do their jobs. The idea was that we would give the operatives a small handheld PC and transmit their jobs to this PC. Therefore, they would not have to spend time coming into the office, picking up paperwork and that slice of time (probably about half an hour) could be turned into productive time.

In principle, that sounded like a great idea, but the difficulty was that the time they were picking up their paperwork was around 7:30am and converting that half hour from 7:30 to 8:00am into productive time meant that they would have to be knocking on people's doors at 7:30am in order to repair their bath. Clearly, that is not going to be received well by the clients. So, even though we could technically deliver the system, in the sense that they would not have to pick up the paperwork, the business could not convert that half an hour into productive time. So, there was a disconnect between the technical solution and the business benefit.

2. Lack of clarity regarding the future strategic target operating model

Logical application systems architecture and physical IT infrastructure are of fundamental importance. When you set out you need to have a clear understanding of how the current “As Is” systems fit together. You then need to determine the shape of the future Target Operating Model (TOM) and the phased steps by which the “As Is” systems model is to be safely transformed into the TOM.

In my last carve-out project the existing system model comprised a SAP system supporting the commercial and financial processes of the business, interfacing with a Manufacturing Execution System (MES) that was effectively servant to the SAP system. The MES system orchestrated supervisory control and data acquisition (SCADA) systems that drove the manufacturing processes. Both the SAP system and the MES system needed to be replaced, but only the SAP system featured on the critical path to the carve-out.

One of our initial debates concerned the scope of systems we were to replace on “Day One”: Were we to replace the SAP system and the MES at the same time, or should we replace these two systems separately, in two phases? To replace the SAP system independently of the MES system required the replacement of the existing SAP <> MES interfaces, which was problematic. On the other hand, while replacing both systems at the same time avoided the replacement of existing interfaces, to replace the two business-critical systems coincidentally on the same day was a high risk, not least because the MES system was a complex beast. So, we chose the least risky option; to replace the SAP and the MES system in two discrete phases That was an important decision.

As far as the IT infrastructure was concerned, the IT operations manager was adamant he did not want to take on the existing infrastructure from the previous parent company because it was so old. But the more I considered this, the more I became convinced that to replace all the existing IT infrastructure in a “big bang” on Day One was a high risk. Additionally, there was no physical space in the cabinets to install new routers alongside the old ones. So, we opted to take over the existing IT infrastructure from the previous business owner: true, the infrastructure was old - but it worked! After the final carve-out we then replaced the old IT infrastructure carefully, piece by piece, no longer subject to the time pressures of an absolute drop-dead date.

3. Failure to define and then police the objectives of the project, leading to “specification drift”

The last project I was involved in was quite simple in terms of its objective: An IT service that was currently being provided by a third-party was to be brought in-house by a certain contractual date. The difficulty here is that once you start a project, everybody comes up with good ideas to add to it.

In this case, there had long been historic problems with the logical structure of the engineering data and the team suggested that, given we were changing the system, we should take the opportunity to restructure the engineering data and thus make the business processes far more efficient. We had quite a debate about this. Eventually, I said: “What you are trying to do is entirely reasonable and sensible, but it has nothing to do with the objective of this project. And I am not prepared to embark on a major data restructuring exercise between now and go-live that would put our end-date in considerable jeopardy. So, yes, we undoubtedly should re-structure the engineering data, but we will not do it on our critical path to go live.”

As Project Manager, part of your role is to make sure that the objectives of a project do not drift.

It is a very simple thing, but it is crucial to define the project objectives clearly at the outset and make sure everybody has bought into these so that in subsequent discussions you are able to say, “what you are proposing is sensible, but it isn't a precursor to achieving our set project objective.”

4. Lack of consistent project sponsorship

Inconsistent project sponsorship can lead to “moving goalposts”. You could be in a situation where you start off with a sponsor, a senior individual, who gives you the mission and as you start to move down the path, they start to change the mission.

One example I have of this is when I was working with an organisation that was based upon local admin centres and the business strategy was that we would close most of these local centres and have just one or two admin centres supported by a single centralised system. So, we moved down this path and then the sponsor changed his mind and started to consider retaining all the local admin centres.

Now obviously, this was a huge change in strategy - we were moving from the concept of a single central database with everybody connecting into it, to a set of individual databases for each individual centre. Fortunately, that discussion did not go much further but it is an example of the sponsor changing their mind completely.

Of course, some business changes are inevitable. For example, when a company is being acquired by another organisation. This can result in extensive business changes which you have to cope with. However, you should carry out an impact-analysis of the proposed change so that project stakeholders fully understand the consequences of the proposed change (time, money, resources) and that you obtain approval to these consequences before embarking on the changed mission.

5. Failure to assign strong business representatives

Projects need representatives from the key functions in the company assigned to them. For example, a finance representative, a manufacturing representative, a purchasing representative etc. These “Subject Matter Experts” (SME’s) are the people who will ultimately agree the functionality of a system and it is their responsibility to make sure that the functionality that is being developed will meet the business needs within their area of responsibility. Having strong SME’s assigned to the project is key because the Project Manager alone cannot and should not determine what functionality is in the best interest of the business: The Project Manager will not be the business process owner of the system once delivered.
The last project I ran was in Poland. The team were absolutely first-rate and outstanding individuals. The system implementation went very smoothly. We had problems, but we resolved those and there were not many. Ultimately, the success of that project related back to the fact that we had exceptionally good people assigned to the project from each of the business areas.

This does not come without pain though.

If you are taking very good people from the operation of the business and assigning them for a considerable length of time to a project, then, the day-to-day operations of the business are going to suffer in their absence. However, this is a bullet that the business must bite if project success is to be assured.

I compare my experience with the Polish project to a UK-based project that I was involved in. Here the business representatives assigned to the project included individuals that the operation of the business could most easily do without. These individuals were simply not of a calibre to express the needs of their business area within the project, and I had to have them replaced. After that we turned the project around.

Ultimately, what a business puts into a project is what the business get out of the project. If you put good people in, you get a good result. If you put poor people in, you get a poor result, it is as simple as that. The quality and the quantity of the team members are key. You need to have adequate business representation and they need to be people of the right calibre.

6. Poor choice of software and/or third-party software systems integrators

If you choose software that is inappropriate, you will find when you get further down the path that you end up with a huge amount of customisation. This is very risky and very expensive and, if you are not careful, you will end up with the worst of all worlds - a package software that has been so heavily customised that, when it comes to taking the next version of the software, you have a major problem on your hands because the customisation cannot be easily carried forward, if at all.

So again, you must make sure that you have a sound upfront definition of the functional requirements that the software package must deliver. This comes back to the SME’s defining what they require of the system and then carrying out an objective and quantified evaluation of various software packages to determine which software obtains the best match. Use a MoSCoW rating categorisation of business requirements and assign relative scores for each MoSCoW category.

The choice of third-party systems integrator is also important.

Ultimately, you are in the hands of your chosen systems integrator, and you must be confident that the system integrator is technically proficient. That is the first thing. The second thing is that you need to make sure there is a good cultural fit with the client’s user staff. In the case of a systems integrator on my last project they proposed a team of systems developers for whom English was a second language. Since these developers would be discussing business requirements with Polish users for whom English was also a second language, the opportunity for frequent misunderstandings, with consequent frustration on both sides, was immense. We eventually appointed a Polish systems integrator. This made life a lot easier.