IT projects: A wave of failure is coming

IT projects: A wave of failure is coming

It’s not about out of time and out of budget: we are talking about spectacular failures that interrupt supply chains and slow down careers. […]

Cassandra had no friends – it has never been a grateful and popular role in the company to predict disasters and failures. Therefore, I am writing this report with the full awareness that the content will fall on deaf ears and the potential benefit of my advice will be found in the pile “I wish we had…”. My thesis: there will be a tsunami of project disasters that is rapidly moving towards the shores of companies, and there is not much that can be done to stop it.

The kind of project disasters I’m talking about are not the normal cases where the budget is exceeded and the schedule is blown up. Rather, it is about the spectacular failures that interrupt supply chains, delay financial reporting and destroy the careers of seemingly competent managers. The kind of failures that occur when companies commission an implementation that turns out to be reckless in retrospect.

Why am I so convinced that many projects are on a collision course with failure? Here are four signs of the impending disaster:

Double the volume. Between May and September last year, twice as many large-scale projects were launched as in a normal year. When Covid-19 broke into companies at the beginning of 2020, many organizations put their large IT-supported transformation programs on hold for the time being. At the beginning of 2021, the dam finally broke, and large programs that were supposed to start in 2020 were started. At the same time, companies have given the go-ahead for their programs planned for 2021. Voilà! This means that the number of potential project disasters has doubled. Since the time span for the initial implementation of large initiatives is on average 12 to 18 months, the table is set for 2022.

The actuality distortion. When was the last time you read about a failed start of a major project? US projects such as Select Comfort, National Grid, Cover Oregon or the Los Angeles Department of Water and Power (LADWP) have been out of sight for several years – long enough to disappear from the memory of the management level. Organizational hubris is a powerful force that often acts as a counterweight to the real probability of disasters. If there is no news about disasters, the potential threat fades. There is a reason why everyone drives more carefully after seeing a car accident.

The talent gaps. Almost all major disasters during the go-live can be attributed to the lack of experience of the senior project staff. However, the ability to identify and communicate risks is crucial to mitigate them. Since the number of projects has doubled, the ability of system integrators to find highly qualified employees for all programs has been severely limited. In connection with the “Great Resignation” and the turnover rate, which has doubled in the last six months at least in the USA, it becomes clear that the situational awareness for these programs has fallen drastically.

Unproven methods. We have seen that many projects had to struggle with tests of the integrated systems during the pandemic. The reason for the productivity losses is often the lack of spatial integration of the project teams. If you do not work together directly, team members will not be able to learn so quickly from their side people, and tips and tricks will not be passed on so easily. Now think about the time after the launch and the potential impact on thousands of users who may not have the superusers in the room next door accompanying them through the launch. There is no reason to believe that the same problems we saw in the tests would be miraculously resolved after deployment.

Are there ways to avoid the tsunami of disasters? The answer, unfortunately, is the bottom line: no, because the die has already been cast. However, there are tactical options that can be used in individual programs to prevent a catastrophe. Here are some simple recommendations:

Keep your back free. For example, ask your system integrator to put together a presentation about the Lessons Learned from major program disasters. You don’t have to be the messenger who gets shot. Submit this presentation to the Steering Committee sooner rather than later to show that you are taking appropriate measures to protect the company.

Set start criteria early. Too many programs do not set the launch criteria until two to three months before the planned launch. If this is the case, the criterion is: “What can we achieve before the go-live?” and not: “Where should we be?“. This is especially true for projects that are under budget pressure.

Independent perspective. The “go-live” or “summit fever” is real – just ask the families of those who died trying to climb the top of a mountain. Good judgment is easily clouded by estimates of sunk costs (which will never pay for themselves again) and unsustainable best-case scenario planning. An independent point of view can be very sobering.

This article is based on a contribution from our sister publication cio.com.

*Moritz Iversen is a freelance journalist based in Munich.

Unity 3D Games Development | Unity APP Outsourcing Services

Ready to see us in action:

More To Explore

IWanta.tech
Logo
Enable registration in settings - general
Have any project in mind?

Contact us:

small_c_popup.png