Best practices for massive IT projects start in planning phase, experts say

For many organizations, IT modernization feels like ascending Mt. Everest: a steep climb that must be completed in too little time, with dangers at every turn.

Rather than panic, experts suggest, organizations should clearly define the scope for any modernization project, and ensure that new IT projects are helping increase business value.

Derek Hanson, field CTO at Yubico, told IT Brew that teams starting on a modernization project should ask themselves whether they are upgrading infrastructure for new business capabilities and an improved experience, or just upgrading services for the “sake of IT.”

“When evaluating when to do an IT project, it needs to be a situation where the scales are heavily tipped in favor of either reducing risk or improving the actual business outcome of the IT system,” Hanson said.

Fabian Pfau, VP of solution architecture at SNP Group, told IT Brew that, for IT departments seeking to overhaul their tech stacks, challenges include condensed timelines, legacy technology, and the need for cost-effective products and services.

“There’s a lot of old data in the systems,” Pfau said. “There’s a lot of old configuration in the systems, and eventually, as an outcome of this, you have a lot of stuff that you want to change.”

Decisions, decisions. Jean-Philippe Avelange, CIO of Expereo, told IT Brew that it can be hard to move past the initial buzz and excitement surrounding a new project, especially when implementing something exciting like an AI initiative.

Avelange suggested that professionals consider a smaller approach to innovation before a major project kicks off. For example, introducing a new capability rather than trying to “control and plan everything through massive programs.”

The first step, Avelange added, is understanding a problem is worth solving, the deliverables, and the expectations for any overhaul.

“You should only focus on: ‘Is it still the right problem to solve, and what is the next iteration that we want to inform?’” Avelange said. “But if you start up front with saying, ‘This is the scope and this is exactly what we’ll do,’ you constrain yourself in your creativity or ability to be discovering and to be pragmatic in those approaches.”

Establishing the scope. Professionals can become enamored with adding more capabilities or tooling to a massive project, but they should be careful of the breadth of an overhaul.

Pfau said he sees projects fail most when a company decides on the size of a project and broadens it after the fact, or “an immense scope creep.”

“That’s really where we do see customers and programs struggle because timelines get moved, cost gets up, business gets unset,” Pfau said. “It’s a slew of things that unwinds if you’re not keeping your scope within the timeline.”

Instead of adding to a project’s scope, Hanson said that professionals should try to deliver on the initial promises before integrating additional tools and capabilities. This can help IT professionals manage executives’ expectations for the cost and timeline of a project.

Additionally, Hanson said that focusing on smaller, bite-size deliverables within modernization and migration projects, especially those that chip away at technical debt, can help increase trust from executives and enable more innovative projects.

“Ultimately, it comes down to the advice we got as kids of eating your vegetables before your dessert,” Hanson said. “It’s not very much fun, but it’s what gives you that credibility to go after some of those more interesting and intriguing projects.”