Taking the Risk Out of Big IT

For insurance companies, moving to a new policy administration or claims processing system is usually a major forklift operation that requires a huge investment of time, money and human resources--no matter how smooth the eventual cutover may be. Such is the nature of the IT beast, which has reached a scale of enormous complexity and inter-dependency between systems.

However, in recent years, there has been momentum for doing things a little easier--of breaking down IT task and migrations into more manageable “chunks”--to be done iteratively, in concert with the business. IT, with its big systems, big networks and now big data, is an ideal candidate for this strategy. The big question, of course, is: is it realistic? Yes, says Brad Power, writing in Harvard Business Review, advocating chunking as the best way to manage ever-expanding and ever-complex IT projects.

Unfortunately, chunking runs contrary to the way enterprise software tends to get packaged, delivered and installed. “Computer systems often don't come in a multitude of small parts; they generally come in huge packages,” he says. “Typically, large software packages are rolled out without modification to take advantage of embedded best practices in either a 'big bang' or a 'rolling implementation' across multiple geographies.”

The larger and more expensive an IT project is, the more likely it is to fail, Roger Sessions, CTO of ObjectWatch, once said in an interview. A system that costs less than $750,000 "has a good chance of succeeding," but a system or project exceeding $2 million "has less than a 50 percent chance of succeeding... by the time it gets much larger than that, the chances of success drop to near zero."

Many aspects of cloud computing and its older sibling, service-oriented architecture, are all about chunking--breaking applications into bite-size chunks to be delivered when and where they are needed.

And there are workarounds, Powers says. He urges the breaking up of technology-enabled processes into “a series of small, reversible experiments.” How can this be done? He outlines three steps:

1. Jointly map the workflows before you implement the technology. The technology should fit into the business requirements, versus trying to shoehorn or truncate a business process to adapt to the technology.

2. Break the new system into chunks for implementation wherever possible. As one IT executive put it, get around the big bangs by using "joint application design/rapid application development" sessions that engage front line workers, data modelers, programmers, analysts, and technical designers in designing a mockup. “Rather than follow the traditional 'waterfall' approach of defining big chunks of requirements upfront--which always proved problematic--we would do it in smaller, bite-sized chunks. And we replaced quarterly releases with biweekly or monthly ones."

3. Create boards to share plans and progress. Cross-functional teams, drawn from both the business and IT, turn over control of the rollout “to the business, rather than driving it from IT as an IT project.”

There's nothing new about the chunking concept--Henry Ford broke automobile assembly down into chunks with the creation of the assembly line. Tom Peters, co-author of In Search of Excellence, and author of Thriving on Chaos and Liberation Management, advocated chunking as a strategy for modern-day companies, breaking up complex tasks and projects into manageable components. The ability to break up difficult tasks into the manageable chunks is a well-proven tenet of management, and certainly can go a long way to making the best of IT. Remember the saying: “Mile by mile, it's a trial, inch by inch, it's a cinch.”

Joe McKendrick is an author, consultant and blogger specializing in information technology. He can be reached at joe@mckendrickresearch.com. This column originally appeared on Insurance Networking News, a sister publication of Health Data Management.