Major IT projects are great, provided you like high risks and a low chance of success, says the Naked CIO.

A recent report from’s CIO Jury found that IT leaders think big projects are here to stay. In that case so is dismal failure, dwindling business confidence and over-budget, under-delivered systems.

The challenges with large-scale IT projects that take years to implement are greater than those in any other business function because the tools, capabilities and the business we support change significantly in the time it takes to implement major initiatives.

Furthermore, why close an entire motorway when you can shut small sections of road and reduce congestion?

Major overhauls need to be undertaken but they should be planned for, implemented and deployed in chunks that encourage flexibility, adaptation and changes along the way, ensuring that any system evolves with business and the technology.

That is why I like agile methodology and why I think more IT leaders need to be able to articulate a strategy based on evolution as opposed to back-breaking change. Granted, it isn’t always that easy. Often extensive dependencies exist that propagate big, risky projects.

motorway traffic

Naked CIO: “Why close an entire motorway when you can shut small sections of road and reduce congestion?”
(Photo credit: Shutterstock)

I have a similar situation in my business right now.

Over the years, one of our primary systems has been customised beyond its capabilities. The workarounds and non-logical customisation imposed on it have produced a sluggish and costly system that is increasingly difficult to manage.

I realise that the system itself may not be sustainable and may need to be replaced – one of those large-project nightmares. But I haven’t decided yet if this is the case. Instead, I am advocating a process review, with a view to simplifying all user-level interactions with the system, possibly lifting them above the application to end the complexity behind all the grief.

My goal is to remove as many of these interactions from the system as possible and disperse them through a variety of means including other tools and small flexible applications development.

Once we have reached that point, I will be able to determine if the system really does need to be replaced. This process also serves to pave the road for less radical, less large-scale migration away from the dependencies and constraints that this environment is creating. The goal is to make any future initiative less costly, time-consuming and risky.

All too often we make our lives harder by addressing the problems in our environments. Instead, we become fixated on solutions that may not even address the underlying causes of frustration.

My suggestion is become less hung up on systems and more focused on solving the underlying problem. We should also try to prepare a plan that doesn’t seek to build Rome in a day. Start with a street, add some houses and then eventually you will have your new city.

Vendors in this case are part of the problem. They salivate when faced with a no-win scenario and their cash-register brains go into overdrive and prepare you for a long-term initiative that sees their quarterly targets hit for the next two years.

Don’t buy what they are selling. It will not help you solve your problem and adds complexity and risk to what you are trying to achieve. Sell them your approach and do not commit. Sell them the opportunity to be a partner over time. If they perform and adapt along the way then in all likelihood everyone will benefit.

Ever wonder why vendors want a long-term commitment for these types of projects upfront? It’s because that way they have the money and reduce any and all accountability for success. Large projects should only be tabled when every other option has been exhausted.

Large projects are a high-risk way to operate IT in today’s world, with a low probability of success. If you want to set yourself up for failure, advocating these types of initiatives is the best way to proceed. My advice is simple: don’t.