Why IT projects go wrong: Confessions of an IT manager

Plaques. I hate them. There, I’ve said it. Such a weight off.

I accept that this probably isn’t the most controversial thing you have ever read on the internet. I also imagine that it’s not something you expected to read, so let me explain.

I started my professional life as a mechanical engineer, but soon hit two issues. One was that, whilst I could work out the flow of a liquid in a pipe, I didn’t care about it. I took the view that to get something working then I could just over engineer; a view those above me didn’t share. The other issue is that I was a lot better at the computer and programming modules, but I didn’t want to ruin the enjoyment of my nerdy hobby by being forced to do it for money every day.

On my course we often talked about famous engineers of old that built the important infrastructure we still use today. Think of the railway tunnels and bridges built by the Brunels, father and son. My problem with this lauding of the builders/designers is that they have been in use for almost a couple of hundred years, yet we only talk about people who built this infrastructure: not a word on the countless other engineers that have looked after and maintained this item and allow them to be still in use today.

There is only one plaque, and it has the original engineer and some notable worthy who cut a ribbon on it. Not those hundreds of people who physically built it. Nor those who maintain it now.

Legacy thinking

We still do this, with modern infrastructure being knocked down and rebuilt rather than maintained and adapted. I’m convinced that the root cause is someone being after a plaque to leave a “legacy”. And the issue isn’t just in engineering, it’s everywhere. In IT, what I eventually swapped to after mechanical engineering, it’s especially true.

If the IT team spends its days maintaining and looking after any business application – keeping it running every day, with no complaints – then your work won’t be recognised. It just works! This is no “plaque” you can put on your CV.

Build a new business application, even if it isn’t as good, and your boss is happy. You’re considered keen and go-getting, and you get a plaque you can put on your CV. I’m sure that it’s the same in other areas of industry too. I look at it as needless change for change’s sake.

When IT projects go wrong

Time to visit a more recent past. A little while ago, I took over a project to rewrite a global application that wasn’t used by my firm but by several our clients and their subcontractors, to message each other in a controlled way.

It consisted of an application installed on both sides; this application sent and received messages via a central server. As an allegory, think of it as a private email system.

This program was robust and had been in place for over ten years. One day, a group got together and decided that it was getting old and needed to be modernised. The project design boiled down to this: “Rewrite the application as a technical upgrade into Microsoft’s cloud platform Azure as cloud native.”

When I took over the project, it had been running for about two years and still wasn’t working. The first thing I do is review the documentation where I see two very early changes. The first, replacing a relational database a non-relational database. I can’t see a reason why, other than non-relational databases being “cool”, but this means searching won’t work correctly as this new database is case sensitive.

The second change was to replace the local application with a web page. Again, cool and modern, but this meant some existing functions couldn’t be moved to the new application. These design decisions appear to have been made by the project manager and developers without consulting the users of the application.

The cynic in me suspects this is because making an application with these features looks good on the CV. It took them another two years to write the new application to a point that our clients finally agreed we could move forward and out of testing.

When IT projects go really wrong

Then things went really bad: it turned out our clients haven’t spoken to their sub-contractors about how they use the application, just like the project manager and developers hadn’t talked to the clients to begin with.

The subcontractors, with ten years’ experience of playing and using this application, had modified and customised it to their needs. For example, sending automated messages. But this wasn’t how the application was supposed to work. They freaked to learn a webpage with not all the functionality was about to be used for communication; and no, it couldn’t be automated. As far as they were concerned, they already had a system that works for them, thanks but no thanks.

So, after two-and-a-half years, the new application had to be taken out the back to be put out of its misery. The original application stayed in place. This project became another in the serial tale from the file marked “IT projects that fail”, but it was driven to failure from the beginning by people who wanted a plaque on their CV. People who didn’t talk to those that use the application.

Think before you rip

The rip out and replace approach is too common in buildings and code. We should be thinking “how can we maintain this instead of replacing it?” Whilst the replacement may look simple and quick to do, that’s rarely true in practice. There will be something that makes it complex, even if that something isn’t immediately obvious.

The very fact that it hasn’t been replaced should be a warning that a process is important and complex, because otherwise a small maintenance change would be done already to fix the issue that the replacement is going to fix.

If you are building something new, build it as best you can with versatility in mind. Create buildings that can last forever, even if they start off as hospitals but become offices. In short, over-engineer. It’s more expensive, but with physical items it may even save the planet.

Oh look, I was right all those years ago.

My rules for successful IT projects

So, howe do you make a project successful? Here are my rules.

First, everyone affected must be there or represented. I tend to try to have a “tea and biscuits” line in the budget. Better drinks and biscuits encourage people to attend, and attending hopefully allows issues to be picked up, or at least the blame to be spread.

Following on from that, if you don’t turn up, you aren’t allowed to say later it doesn’t work.

There may be a list of improvements that must get implemented and these can be taken in mind during the first stage, but that first stage is only to get what we have now and working.

At this point we can have a pizza party and start on the new improved stuff.