Menu
A tsunami of IT project disasters is on the horizon

A tsunami of IT project disasters is on the horizon

No garden-variety ‘over budget and behind schedule’ project failures here. We’re talking spectacular failures that disrupt supply chains, delay the reporting of financials, and blow up the careers of seemingly competent executives.

Credit: Dreamstime

It is never the popular position to take in the organisation to be the prognosticator of disaster and failure, so I write this missive with the full understanding the contents will fall on deaf ears and the potential benefits of my advice will be found on the pile of “I wish we would have….”

There is a tsunami of project disasters rapidly moving toward the enterprise shoreline and there is not much that can be done to stop it.

The type of project disasters I am talking about are not those that are over budget and behind schedule, but rather the spectacular failures that disrupt supply chains, delay the reporting of financials, and blow up the careers of seemingly competent executives. These are the types of failures that are created when enterprises “go-live” with an implementation that, in hindsight, will be deemed done in a reckless fashion.

4 harbingers of doom

Why am I so convinced that many projects are on a collision course with failure? Consider the following:

Double the volume: There are twice the number of big projects in flight scheduled to go live between May and September of this year compared to a normal year. When COVID-19 shut things down in early 2020, many companies put their large IT-enabled transformation programs on hold. 

In early 2021, the dam broke, and big programs scheduled to begin in 2020 got launched in 2021. At the same time, companies that had originally planned on launching programs in 2021 did so. Voila! That means double the number of potential project disasters. With initial deployment delivery timelines averaging 12-18 months for major initiatives, the table has been set.

Recency bias: When was the last time you read about a major project go-live failure? Organisational hubris is a powerful force that often counterbalances the reality of the real possibility of disasters. When there is no news of disasters, the potential threat fades. There is a reason we all drive more carefully after seeing a car accident.

Talent voidsAlmost all major go-live disasters can be traced back to a lack of experience on the part of the senior project team members. The ability to ascertain and communicate risks is obviously paramount to mitigating them.

With double the number of projects in play, the ability of the managed service providers (MSPs) and systems integrators (SIs) to bring highly qualified talent to all of the programs has been greatly diminished. Couple this with the “great resignation” and attrition rates that have doubled over the last six months, and businesses will see that the level of situational awareness on these programs has been dramatically reduced.

Untested methods: We have seen a lot of projects struggle in the areas of integrated systems testing during the pandemic. The source of the productivity hit is often traced back to the lack of colocation of the project teams. Without being together, team members are not as quick to learn from their neighbours and tips-and-tricks are not passed along as easily.

Now fast forward to after the deployment and consider the potential impact on thousands of users that may not have the super users in the next chair over to guide them through the start-up. There is no reason to believe that the same struggles we saw in testing would be miraculously cured following deployment.

How to avoid IT disasters

Are there ways to avoid the tsunami of disasters? The answer in aggregate is, unfortunately, no. The die has been cast. Are there tactics that can be implemented on individual programs to prevent a disaster? Fortunately, that answer is yes. Here are some simple recommendations for end-users:

Make it real: Customers must ask channel partners to put together a presentation on lessons learned from major program disasters. There is no need to be the ‘messenger that gets shot on the beach.’ Customers are ensuring this presentation gets to the steering committee sooner rather than later to demonstrate that they are taking appropriate actions to protect the business.

Establish go-live criteria early: Too many programs make up the gate criteria 2-3 months before the targeted go-live. When this is the case, the criteria then becomes, “what can we achieve before go-live” rather than, “where should we be?” This is particularly true for projects that are under budget stress.

Independent view: ‘Go-live’ or ‘summit fever’ is real — just ask any of the families of those that perish trying to reach the peak of a mountain. Good judgment is easily clouded by sunken cost assessments and unwarranted best-case scenario planning. An independent view can be very sobering.

I realise that this post is likely a bit of a downer or it can be perceived as simply sensationalism, but if it sets the wheels in motion for even one project to avoid disaster, it was worth it.


Brand Post

Show Comments