IT projects fail for EVILL reasons

There are lots of reasons why projects fail, but specifically why IT projects fail – not technology, not budget. You may read in the press about massive IT projects spiraling out of control, costs are double or triple the budget, and technology is being blamed. However, the root cause of the problem is often not insufficient budget or poor technology.

So, what is it that causes IT projects to fail? Are there any consistent reasons why?

Most IT projects have problems due to EVILL reasons;

• Engagement
• Variations
• Integration
• Learnings
• Leverage

So, allow me to explain the EVILL formula;

Engagement

In the failure formula of EVILL, it’s common to see a lack of engagement with the new system / process / capability as being the cause of problems, and ultimately, failure. Lack of engagement and adoption of the new system or IT project can be a kiss of death, and often comes from the more entrenched mindset of “that’s not the way we do things around here” people. People may not like the way it operates or looks, people may find the product hard to use, or people may not like the authentication process. It’s people who make it a success – if you don’t engage with people at an early stage (the customers of the system), to find out what they want and what their pain points are – the project is much more likely to fail.

I have encountered many businesses that complain about IT implementing new technologies, and then just pushing them on to the users with little explanation, training, or consideration of their business needs. In recent cases, I have encountered 2  different businesses where IT have rolled out Skype – but for presence and chat only, no phone integration, and most PCs were thin clients with no headphone socket or accessible USB ports, so it could not even be used as a soft phone. The users (and business) saw little point, did not know how to use it, were never told about screen sharing, and they thought that they were having their presence monitored – it was a complete disaster. A similar case with an email archiving project that the IT department knew they needed – but the business just got concerned about email content disappearing, thought that IT were making decisions about what content was important to the rest of the business, and it caused a bad relationship between IT and the business, a loss of trust.

Variations

The V in the formula can be caused by many factors – when a customer changes their mind, when the project loses direction, when the application requires significant modification, when external factors make the original project go off course, or plain old scope creep. Classic Waterfall projects have an up-front definition of the project (in high detail), with little tolerance for coping with variations – and Agile projects are peppered with variations all the way through. It is all a matter of how the variations are handled by the project, and how long they carry on taking the project in a different direction. Chasing a problematic project scope with more money, or more technology, is often the technique used.

Variations in a project are not just an impact to implementation – they can also have long running, long term effects. If a COTS solution is customised, altered and adjusted – this can make future upgrades and enhancements more difficult to implement.

However, custom developed applications can also be problematic to vary – is documentation complete? Has the application been developed with standard methodologies and approaches that another developer could pick up – or would someone new consider they need to clean up the code first? Has the custom application evolved through many contracted developers, each with their own style/quality?

Integration

I am frequently amazed at the number of IT projects that are implemented in complete isolation of other projects and business processes. Enthusiasm for a technology or product’s capabilities in isolation is normally a predictor of a failure outcome. It may be seen as the magic pill that is going solve all the problems – but no-one has actually looked at the medicine inside.

In a similar vein to the above examples of implementation of a product in isolation of business needs, there are projects implemented where the information and processes are completely isolated from any other existing data repositories and sources. I have come across multiple Stealth IT projects where departments are going off and purchasing their own “solution” that creates an island of data and knowledge, often with a different username/password that is not accessible by any other team or department. It’s not just Shadow IT projects that create data silos – the IT department may also select a product or technology that seems great, but cannot integrate with other data in the business.

It’s not just authentication or data visibility that is affected – other areas such as enterprise reporting, big data analysis and even backup can impacted by lack of consideration of Integration needs.

Learnings

Yes, people don’t learn. Projects get implemented with what seems to be a rose-tinted view of ignoring past failures (or successes) and learnings. Project post-mortems and knowledge capture is often skipped, to go onto the next project. Errors such as;

• A supplier or external third party was slow to deliver? Consider it a once-off and don’t consider that in the project timelines next time.
• Integration was complex due to missing documentation? Don’t record the documentation that was found on the Internet to solve the problem – people will remember what was done, including the once-off script that was used.
• A manager in department X was resistant to change? He will be better now, just push another IT project on him at the last minute, and all will be fine.
• No data dictionary to integrate two systems before? We’ll work it all out again for the next project. Keep on developing point to point integration, and have multiple service bus systems that are only used to integrate two systems to each other.
• Custom ports used on the firewall? Nothing to worry about, the last project just opened up all ports “temporarily” between subnets, so we can do that again.
• Doing the same task again and again? Let’s just keep that person employed in that mind-numbing task, not re-deploy them to a more useful role, and keep all that nasty automation out!
• Insufficient permissions to run a client application? Just put an exclusion in the main Group Policy Object that applies to everyone and everything, instead of diagnosing the problem. Or, just give every user full Administrator rights. For the next project, just make another exception.

(note my sarcasm…)

A way forward is to have a repository of knowledge, to ensure that the outcomes of a project, both good and bad, both useful and ineffective – are recorded and able to be used. Build a culture where errors and mistakes are considered to be something that is to be recorded, not swept under the carpet.

It’s not just the errors that keep on being ignored and repeated, but also the positive learnings and outputs that do not get re-used. Did a previous project find a really effective way to engage with the users? Was there a trainer that people learnt well from? Positives can be built on, but too often, aren’t.

Leverage

In a pattern that is emerging through my above points, IT projects are too often implemented in isolation from each other, from the business, and from the end users. When an IT project implements a new technology, it is often only the IT benefits that are realised – other capabilities are not leveraged as much as they could be.

Take for example an implementation (that I was not involved in) of Office 365 and SharePoint Online. The existing sites were migrated, Office 2016 was installed on all user computers, and then the project was considered complete. The company did not get the full benefit from the IT-led project. There were opportunities to train staff not just on the tools, but also on changes to practice and procedure to leverage the new capabilities. Their ability to improve business practices through the technology was lost, and with a toolset that touches all staff (as the Office suite does), there were pockets of different approaches and practices that started emerging – individuals who used the same toolset in different ways.

An old example I recollect is of a printer roll-out, where multi-function devices were placed on each floor. However, it was not in the scope of the project to use the scan-to-email capability, or to connect the MFDs to the phone line to send outgoing faxes. People hated the complex devices, mostly because you had to switch the device to printing mode every time – even though that is the only function they were used for. Just a few months later, a project was approved to implement several high-speed scanners to replace some desktop flatbed devices – where the MFDs would have met the needs. And then they also went and bought 5 new fax machines…

Also, consider what other benefits an IT project can deliver – can it improve processes, methodology, training adoption, collaboration, engagement, relationship between IT and the business, integration?

Hopefully, as you have been reading through these reasons, you are seeing that there are areas that you understand how projects can fail for EVILL reasons.