Building a Foundation

Four ways to make an IT transformation project a success.

When IT transformation projects implode, the costs in time, money and morale can be devastating. Think it couldn't happen to you? Think again.

In a survey of 800 IT managers, research firm Dynamic Markets found that 62% of IT projects ran behind schedule, 49% ran over budget, 47% incurred higher-than-anticipated maintenance costs, 41% failed to deliver expected ROI and 25% were canceled before completion.

Though the survey covered all industries, there's no reason to believe the results are any better for insurance companies. In other words, one in every four insurance IT transformations will fail completely, and many others will fall short of expectations or waste company time and resources.

Turnaround specialists frequently are called in to rectify these types of troubled projects. More often than not, what they find aren't just failures, but spectacular failures. So how can you help ensure this won't happen to you? It's a combination of four central elements: team experience, solution and project architecture, an agile approach and executive oversight. Transformations with these components have significantly better odds of success. Now let's take a closer look at why failures happen and how they can be prevented.

1. Inexperienced Leaders

Well-intentioned insurance executives can stymie a transformation initiative before it's even begun, by choosing inexperienced project leaders – who in turn select the wrong rank and file – and sometimes by missing critical roles.

At first blush, the prototypical project leader looks like a sure bet: an exceptionally smart, personable, conscientious corporate administrator – someone to manage the calendar, the budget and the 2,000-line project plan. But large-scale IT projects demand leaders with personal experience on both the business and technology sides of the house, and who are willing to sink their teeth into the real problems while leaving the minutiae of time and task reporting to the administrators.

Typically missing from multimillion-dollar transformation projects are business visionaries who are high enough up the food chain – those who understand the business, appreciate the need for change, invite challenges to the status quo and possess the authority to make decisions. Often, there are no strong, experienced architecture visionaries dedicated to these projects, either. Instead, "fractional architects" who don't practice the contact sport of creating and implementing transformative solutions are assigned to ensure compliance with the so-called corporate architecture rule book.

In some cases, companies will attempt to "coach-up" inexperienced project teams by sending them off to a one- or two-week technology crash course. But someone trained on a mainframe in the 1980s can't possibly learn modern technologies and paradigms in a matter of days. And if you haven't "been there and done that" at least a few times, even rigorous boot camps won't help.

You wouldn't let a surgeon operate on your heart after two weeks of "surgery school," yet insurance companies seem surprisingly unfazed by placing inexperienced leaders and teams at the heart of complex, multimillion-dollar transformation initiatives.

Inexperience breeds inexperience. If project leaders and socalled architects are merely administrators or "compliance cops" who have never been in the trenches and aren't personally familiar with the applicable technologies, how can they hope to articulate the project's needs to their teams, or to distinguish between legitimate candidates and resume-rich imposters?

This is why inexperienced leaders turn to superficial, mechanical hiring and resource selection processes. Often, that means adopting ultra-specific job descriptions, or matching candidates based on titles and skill-set acronyms. The problem is that mechanical hiring generally leads to a massive team of "finegrained" specialists: technologists who know the intricacies of one or two specific systems, but are unable to grasp the bigger picture.

But today's technology systems are far too complex and interconnected for an insular team of specialists. In fact, a massive team of narrowly focused "experts" would be nearly impossible to manage, let alone redirect or redeploy to alternate areas of the project. Worst of all, an army of fine-grained specialists will tend to work in silos, lacking a solid understanding of how individual efforts impact the greater strategy.

The strategy that guides team selection is the true fruit of strong project leadership. And it's here that experience matters most – simply because seasoned project leaders and visionaries know how and why to invest in a winning architecture.

2. No Project Architecture

If there's one essential piece to any IT transformation project's success, it's a clear, comprehensive up-front architecture – a logical, elegant framework for decomposing and organizing complex requirements that describes, at the right level, the elements of the solution and how they interrelate.

Imagine hiring a group of construction workers to build a new skyscraper in lower Manhattan, but neglecting to give them clear guidance, strategic direction or the necessary blueprints. The result would be total anarchy. And sure enough, the strength or weakness of an IT transformation's architecture will almost always predict the project's success or failure.

Yet, instead of a well-articulated business and technical vision – distilled in a handful of key blueprints, schematics and pictures – most projects will produce either too much documentation (for instance, a rambling 200-page manual) or none at all.

It's nearly impossible for team members to assimilate the underlying strategy and architecture. Absent a well-articulated architecture, project teams will plod on with the best of intentions, but in directions that ultimately court disaster. Worst of all, projects often suffer from a false sense of architecture sufficiency Merely listing the hardware and software elements involved is not an adequate architecture. Likewise, simply knowing to use glass, concrete and steel will not – in itself – produce a new skyscraper.

Successful architectures must also provide clear definitions of a project's desired end-state. If the vision of a successful outcome can't be articulated in advance, it's highly unlikely to be achieved.

3. Inflexible Development Processes

Speaking of agility, when it comes to IT development, most insurance companies err on the side of overgovernance.The common belief is that well-defined processes and tight controls will ensure that commodity resources produce great software. So-called best practices encourage the creation of massive books of requirements, and then a series of nonnegotiable sign-offs that must precede even the smallest action items.

But apply this rigid process to a massive team of fine-grained specialists working in silos, and you'll find a transformation initiative that's carried by its mass and momentum in a direction that's difficult if not impossible to course-correct.

Efforts to protect the process through over-governance make it nearly impossible to separate a project's essence from its rituals and mechanics. Paradoxically, even companies taking the agile approach sometimes fall victim to an overadherence to the mechanics of agile methodologies – use cases and stories, index cards and Kanban walls, daily stand-ups that mustn't exceed 13 minutes, burnup and burn-down charts – while meaningful progress and business value get lost in the noise. When the rigid processes don't deliver, it only begets more control, more processes and a downward spiral.

Successful processes, on the other hand, remain open and flexible – emphasizing short bursts of activities resulting in testable and usable working software. By identifying and making continuous improvements and refinements to all aspects of the project, including vision, scope, team composition and development processes, the probability of ultimate success increases.

Some insurers might consider the Silicon Valley model, in which funding is contingent on a viable proof-of-concept, then a commercially viable stage and then expansion capital for the later stages of a product launch. Perhaps such an approach is a bit radical, but surely proving the success of individual stages makes sense in a high-stakes IT transformation environment.

Even if insurers don't fund largescale transformation initiatives the way Silicon Valley funds new ventures, surely insurance executives must become the discerning and dispassionate venture capitalists of these initiatives.

4. Lack of Involvement

Successful transformations rely on senior-level change agents and champions from both business and IT to enforce lines of accountability, challenge assumptions and make corrections on the fly. Yet senior executives don't always sufficiently engage, deeming transformation efforts to be merely "IT initiatives." This perception is only reinforced by checkpoints and updates weighed down by overdoses of technical-speak. To executives, these projects can seem impenetrable.

Worse, many executives will see only a technology problem, where in reality there exists a substantial business threat.

Hence, they'll only get involved when confronted with major capital decisions, or when the transformation train is clearly off the tracks – when the damage is typically beyond repair.

Indeed, a proper definition of the end-state – namely, what will change, how it will change and how we'll know it – is a strong basis for motivating and maintaining involvement from C-I eve 1 leadership. And this is particularly important when lower-level stakeholders get mired in the details of an implementation (design, integration, functionality etc.) while leaving the larger issues of profitability and long-term market impact in their proverbial blind spots.

Executive involvement is also necessary for creating a culture of accountability and healthy dissent throughout the chain of command. Lacking strong C-level project oversight, insurance initiatives tend to take on a "just-keep-working-and-itwill-get-done" mentality – in which hard work and effort supersede tangible progress and results.

What Finish Line?

When transformation projects are sick, pulling the plug and swallowing millions of dollars in sunken costs is typically a necessary action. Yet most project leaders will succumb to the "sunk cost fallacy" and inject more people, more capital and more time into a strategically barren operation with virtually no chance of success.

Such projects can drag on for years, draining millions of dollars and spanning generations. But the crudest irony is this: When a troubled IT transformation reaches fruition, it's usually obsolete on arrival, having languished in development while the industry pressed forward.

This fate can be avoided with the right team, the right architecture, the right agile process and the right executive involvement. With these elements, there's a better chance that the promises made will be kept.

Key Points

* The Big Picture: Many IT projects fail or waste companies' time and resources.

* What Needs to Happen: One essential piece of any IT project's success is a clear, comprehensive up-front architecture.

* The Payoff: The right architecture, agile process and executive involvement can lead to a successful IT project.

Lacking strong C-level project oversight, insurance initiatives tend to take on a just-keep-workingand-it-will-get-done mentality – in which hard work and effort supersede tangible progress and results.

Contributor K, Ram Sundaram is a senior principal of X by 2, Farmington Hills, Mich. He can be reached at ksundaram@xby2 . com.