The potential for a lengthy (or failed) system implementation is often cited as the most significant barrier standing in the way of improving the technology available to risk pool staff and members. “Risk Insurance Pools: Secrets to a Successful Implementation” — one of three risk pool-specific webinars recently hosted by Origami Risk — provided attendees with practical insights, best practices, and lessons learned that may prove helpful in countering implementation-related concerns.
Kevin Sesock, Chief Information Officer of the Oklahoma Municipal Assurance Group (OMAG), who served as a panelist on the webinar, made it known that he very much understands where those hesitant to make the change are coming from. Switching over from operations-critical claims and/or underwriting software can be a daunting prospect, one that Sesock humorously summed up as akin to “changing engines in a car when going 90 miles per hour down the highway.”
- Assemble the right team
- Be flexible
- Avoid recreating bad processes
- TEST, TEST, TEST
- Focus on true collaboration/partnership between client and vendor
Assembling the right implementation team
Success is, in a large part, dependent on selecting the right people to be involved in the implementation process. One of the first questions many ask is how many people should be involved. There is no “right” answer here; however, Sanford referred to a study that may prove helpful.
As the panelists point out, far more important than beginning with a focus on numbers is time spent carefully spent considering answers to the following questions:
- Who is the best type of team member to include?
- Realistically, how much time can each person on the team dedicate to the project?
- Do you have a project “champion”?
According to Sesock, there are a number of points to factor in when choosing team members. How well a person knows the existing system and processes are, of course, critical. Equally important is including those who understand how the bigger puzzle pieces of the organization fit together. In other words, in addition to the details, ensuring that the team also includes those who understand the linkage between different parts of the organization. Sesock pointed out that a representative from an organization’s IT team often fits the bill.
Also important is taking into account the inclusion of a representative sample from the teams or departments that will be using the system. This can play a part in ensuring that the entire organization feels ownership and buy-in, an important consideration given that, in many cases, risk pools are replacing technology that has been in place for a decade or more.
Change is rarely, if ever, easy — even when that change ultimately means improvement. That’s why, when it comes to selecting a team, perhaps the most important factor in the overall success is selecting a project champion. For Sesock, this means someone who, above all, has the vision of serving members by providing quality solutions. This is the person who is capable of really promoting the future benefits and selling staff and members on “why” the move to a new system is essential.
Flexibility is key
Referring to his experience, Sanford spoke to one of the most common stumbling blocks — assuming everything has to be perfect or getting hung up on certain details that, while important, can be “tweaked” down the road. Avoiding “analysis paralysis” is dependent on finding a balance that allows for progress while still addressing issues or needs that arise.
Exactly what this means can be difficult to describe until one is “in the moment.” For Sesock, this means being aware of the potential for these types of issues to arise. While maintaining a focus on the excellence of the new system, one must always remember that all of the answers may not be known until feedback is gathered from users.
Of course, just as important as flexibility on the part of stakeholders is, the technology and process must be just as flexible in order to allow for quickly accommodated changes as they are needed. An iterative project plan helps, as does a system that allows for changes to be made on the fly.
Don’t recreate a bad process
“We’ve always done it that way.” can be a common refrain during implementation. But as Sesock and Sanford point out, a goal of simply recreating the old system runs the risk of missing some of the key benefits of a new system — better processes, cleaner data, easier workflows. There has to be an openness to new ideas and workflows. Even for processes that may have been around for decades.
As a strategy for addressing this potential issue, Sesock returned to the important role the project champion plays when it comes to this topic. That person has to be an agent and advocate for change.
According to Sesock, it can be truly inspiring for all involved when the implementation team is getting creative with thinking about how to adapt the system to adapt or creatively work around problems. However, this does not mean change must occur for change’s sake or that there is always a need to “reinvent the wheel,” especially when it comes to functional parity. When addressing processes on which member staff are most dependent, while certain changes may be possible — or even necessary — it’s important to ensure that users are able to perform the same functions.
Test, Test, Test
To introduce the next point, Sesock referred to where OMAG currently stands as they implement Origami Risk for managing the pool’s underwriting processes. Just as with selecting a team that is representative of the organization as whole, involving internal stakeholders in the process of testing the new system has been invaluable. For Kevin, this has meant the inclusion of staff from Underwriting, Member Services, and the IT teams. Next up? Involving member staff. For Sesock and OMAG, this means involving as many members as possible so that the organization gets a broad range of feedback. Others may take a different approach and target specific external stakeholders. When this is the case, Sesock advises that risk pools implementing a new system not hold back on recruiting the vocal members to provide feedback. While this might be somewhat intimidating, it will always be invaluable for improving the system and helping to ensure buy-in.
Above all, Sesock and Sanford were also careful to point out (and reiterate) that the urge to scale back timelines should never come at the expense of testing. Always allow enough time for both internal and external testing. In the long run, both staff and members will never regret doing so.
What makes a risk pool/vendor partnership successful?
Ultimately, true collaboration is what influences a project’s success or failure. But what does collaboration look like? According to Sesock and Sanford, it begins and ends with open and honest lines of communication. Rather than being about blame, the ability to identify and address issues is key.
Clear throughout the webinar was the trust and rapport that Sesock and Sandford have developed in working to implement OMAG’s claims administration and policy underwriting solutions. Through standing, weekly calls and regular check-ins the two — and the Origami and OMAG teams working on the projects — reached the point upon which every successful implementation partnership depends, one of complete trust.
How Origami Risk Can Help
Origami Risk takes an approach to the implementation of risk, claims, policy, and safety technology solutions that is different by design. Rather than simply recreate the old, Origami sees implementation as an opportunity to truly collaborate with clients in an effort to help them refine and improve their processes. To read more about how Origami Risk worked with another risk pool to successfully implement a new RMIS system, click here. Or contact us to learn more.
A recording of the webinar summarized in this post can be accessed here. Two other webinars in this series are also available: