A tsunami of IT project disasters is on the horizon

It is never the popular position to take in the organization 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 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?   Projects like Select Comfort, National Grid, Cover Oregon, or Los Angeles Department of Water and Power (LADWP) have been off the radar for a few years—long enough for them to fade from the memory of the C-suite.  Organizational 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 voids.  Almost 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 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 6 months, and you’ll 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 neighbors 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 startup.  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:

• Make it real.  Ask your SI to put together a presentation on lessons learned from major program disasters.  There is no need for you to be the ‘messenger that gets shot on the beach.’  Get this presentation to the steering committee sooner rather than later to demonstrate that you 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 realize 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!