Why ‘rip and replace’ IT projects are worth the effort
But for some CIOs, a so-called “rip and replace” effort just might be the least painful solution for old systems that have past their prime. Sure, the stakes are high, and the cost is usually huge. But the timeframe for which the business is disrupted is far shorter – and that can mean the difference of life or death in some markets.
Rip and replace is exactly what the name implies – replacing an old, complex, unreliable system with one that is modern, fully functional, flexible, and responsive to changing business needs. It is often a last resort strategy – when no other approach will effectively bridge the gap between what is possible and what is needed from an organization’s computer systems.
But whatever the situation, a rip and replace effort should always be driven by the business, not by IT. This is a business process and efficiency strategy first and foremost. Business is the driver. Technology is the enabler.
[Related: Rip and replace: When it pays to make a total systems change]
“It’s all about the business,” says Jody Albright, currently the interim CIO at Providence Health Plan in Seattle, who previously led a rip and replace effort at Overlake Medical Center. “A rip and replace project is right in the middle of the business processes and what they do. So if you’re ripping and replacing for technology reasons and the business doesn’t have any functional reason to do this, it is going to be very challenging.”
Overlake Medical had a very real business need for a rip and replace strategy.
“We had so many desperate systems that didn’t integrate well,” Albright explains. “Electronic medical records didn’t ‘talk to each other’. That meant that physicians would have to access multiple systems in order to get complete patient histories, and still “hope that they got everything covered.”
The healthcare provider also wanted to grow, and the legacy system stood in the way.
“We were expanding our outpatient and specialist practices at Overlake and the number of different platforms just continued to grow,” Albright recalls. “So it came down to, how much were we willing to spend on sub-optimal integration, because that is about all you could get with the different products – versus, stopping the madness, so to speak, and go for one integrated platform.”
So in 2012 executives at Overland Medical decided that what needed was essentially a total systems transplant, and they sought out a solutions partner to help with the operation. The process that Overland Medical went through offers invaluable lessons for other CIOs faced with this daunting project.
“We went through an RFP (request for proposal) process to identify who would come in and help us with the system selection and the due diligence,” Albright explains. “The company [selected] had some experience – which is obviously one of the reasons that we chose them – in looking at current systems and then moving to an integrated large solution.”
“We looked at everything,” Albright recounts. “We met with the executives at the two major companies that we were looking at. That told a lot. Our whole executive team went, and they helped assess who we would want to have our future strategic direction with.”
“Then we looked at the functionality between the different products and what each would get us in terms of additional functionality,” Albright says.
Among the questions that Albright and team asked were the following:
Albright and team polled everyone on which solution they preferred -- especially on the business side in terms of features and functionality; and on the IT side in terms of implementation, support and staffing impact.
“We went about it in a very conceptive manner,” Albright says. “The implementation of a product like this was so far reaching – it impacted revenue cycle, as well as ambulatory, as well as primary care, all the specialists – it was much bigger than just an ERP project.”
“When ultimately we made the decision to go forward with this ‘big bang’ and get rid of the old system, we looked to the vendor to really understand what it would take to get it up and running – both the implementation part of it, and then what’s the ongoing support and maintenance.”
Selecting the right vendor is a key part of a successful rip and replace effort, says Joe Shumaker, manager of the Mississippi Windstrom Underwriting Association, which began a rip and replace effort in 2012.
Windstrom definitely has a unique strategy – its goal is to eliminate the need for its very existence. The association was created in 1972 following the devastation from Hurricane Camille in 1969. That storm caused record property damage and resulting insurance claims, far beyond the impacted region’s ability to deal with them.
“Around the country, when the voluntary carriers have a market that they don’t really wish to write in, we’re kind of an assigned risk type plan,” Shumaker explains. “In fact, we refer to it as that. We’re a statutory created nonprofit corporation. We are a statutory-created residual market pool.”
To understand the systems dilemma faced by Windstrom you need only do the math. Following Hurricane Camille the association was dealing with approximately 16,000 policies. Then came Hurricane Katrina in 2005, and that number skyrocketed to nearly 50,000. The old system simply couldn’t keep up or provide the functionality that the thousands of insurance agents needing to access it required.
For Windstrom, the most important factor in embracing a rip and replace strategy was simple – speed. The stakes here couldn’t be higher – the people filing claims had in many cases lost everything they owned. They needed to be served as fast as possible. The old system wouldn’t make that happen.
[Related: How to succeed at digital transformation]
“Long story short, it was a custom system, which we were hosting it ourselves” Shumaker explains. “It did have a claims aspect, but it did not act well or integrate well with accounting software. It was also not web-based, which was restricting us. We needed something that was web based that we could push out to thousands of claims adjustors, and hundreds of claims examiners.”
A deciding factor in vendor selection was knowledge of the insurance industry and what agents and examiners really needed in terms of functionality.
“We were fortunate to have a great vendor,” Shumaker says. “One of the things that led us to them was their knowledge of our business.”
“Our previous system was built by smart programmers and technology people, but they weren’t as familiar with the insurance business,” Shumaker stresses. “Insurance is a very unique business and you’re really got to understand the business. [The vendor] had the insurance knowledge. They gave us a lot of expertise. They set down with us, looked at our unique rules and what was unique about our business, and then they began to build [the new system] using the agile process. There was great communication back and forth.”
Not to be understated, “they were on budget and on time,” Shumaker concludes. “They were often times waiting on us. They grasped the changes and the uniqueness of our business. They probably waited on us more than we waited on them as far as our testing; for our signoff; asking if this seems to be functioning; if this is correct; if this needs tweaking; or whatever. They gave us a lot of support and they continue to give us support. If I had the expertise and I wanted, we could take it and do our own revisions and features updates to whatever we wanted to do with it. But I don’t. I rely on them.”