As we continue to look at ways to ensure the successful implementation of a risk management information system software, or RMIS software, I’d like to focus on a desirable trait that some organizations deploying a RMIS may find surprising: Flexibility.
Why flexibility? Because even though both RMIS provider and the client team approach an implementation armed with formal plans for the implementation and project, it's still important to build in give-and-take along the way.
In my experience with hundreds of implementations for all types and sizes of clients, I’ve found that flexibility in the process creates a cooperative mindset for both provider and client. At the same time, it still allows the project to meet the stated success criteria and even the milestones.
FOR EXAMPLE: To take a high-level, generic example, let's consider the classic scenario in which the RMIS implementation is driven primarily (maybe even solely) by the final delivery date. Even when completion date is paramount, it's still crucial that the client receive all of the mutually agreed-upon system requirements; however, the potential friction between delivery date and requirements can become an issue when there is no “play” that factors in variances in client needs, schedule and resource vagaries, and other criteria that almost always come to light at some point in a complex implementation.
In the real-world: The value in being open to revisions
To show how flexibility can be a powerful ally, I’ll share a recent illustration from a retail client. Going in to the implementation, their number-one requirement was to implement incident entry capabilities in their new RMIS in time for Memorial Day, the beginning of their busiest selling season.
In order to meet this deadline, we, as the RMIS provider, initially set system go-live for before Memorial Day. However, as we progressed through the implementation, members of the client team and their pilot users expressed a need for added functionality that would make it easier for the end-users to adopt the new system. Improved ease-of-adoption, the client understood, would make it much easier for their stores—particularly the employees who were new to risk management automation—to get on board with the new system.
These added functionalities, all of which would ultimately result in less work for the users responsible for field-level data entry, included things like re-writes of instructions; changes to drop-down menus to create higher-quality descriptions; additional validations; and additional pre-populations of values. Because these were substantial additional functionalities, we and the client faced the question of whether to A.) push ahead with the initial go-live date, or B.) step back, rework the implementation slightly and then get back on track.
Looking closely at the options, it became clear that the client was convinced of the value they’d get from faster rates of user adoption. That’s because if end-users had a faster data-entry process and could get back to their “day jobs” more quickly, these end-users would take to the system faster. So that’s the course we took, and lo and behold, we still came very close to our original go-live date because the system was easier for new users to learn and adopt.
To reach agreement on the change, the client’s risk management team took the idea to the project sponsor at the corporate level. Their request went along these lines: “We’d like to propose an approach that we feel will make the RMIS adoption much easier. Are you okay with our pushing back the date of the launch, even if it means going into our busier seasonal timeframe?”
Even though both we as the provider and our client were both driving toward an aggressive implementation, it was easy to collaboratively arrive at this decision. There was mutual understanding that both sides wanted what was best for the project, the client and, ultimately, for the users who would be hands-on with the system.
The "top three" for flexibility
The idea of flexibility really comes down to some essential elements:
- Introduce the concept of collaboration early. At the beginning of an implementation, we build in a collaborative approach to defining the success criteria. That way, both provider and RMIS are on the same page with what's most important to them.
- Make communication a priority. Two-way communications and active discussions between provider and client team are essential. This is where you introduce the idea of being flexible so that it's a shared value and all parties see the benefit of it.
- Link changes back to the success criteria. Let's say the client is asking for A, but their success criteria is B. Will pursuing A alter some criteria or criterion of B, and if so, how? Just how important is A? Will A make for an easier process in the long-term? Or is it just a nice-to-have that we can postpone for now? In other words, we as the provider are not saying we won’t complete the request; we’re just asking that you as the client examine together with us the order in which we tackle the request for A.
Remain open to suggestions
We urge clients to keep to their project path but stay open to suggestions. You never know what issues may arise that seemed minor in early planning but slowly emerge as important to the client’s satisfaction.
FOR EXAMPLE: We have had clients that were moving to a RMIS from an environment of categorizing everything in spreadsheets. Their entire user base had been using spreadsheets and sending them in to the client’s risk management team. It was a huge change for them to go from spreadsheet data entry to system data entry.
One of the reasons the client purchased the RMIS was to streamline the collection aspect and make it easy for reporting. Their team came into the project with a preconception that they wanted it to work like X, Y and Z. We came back to them and said, We can do that; however, here is why you might want to look at a slightly different approach.
This is where it pays to be flexible. If the client is open to suggestions of improving their process rather than just re-creating it, they'll get a much better system.
FOR EXAMPLE: Consider a recent implementation of premium-allocation functionality. The client had been accustomed to calculating their inputs for their allocation manually, which gave them the ability to modify the results as needed. After analyzing their requirements for automating premium allocations, the eSolutions team suggested that the client consider calculating the inputs in the system while also allowing manual modifications, if necessary.
After some discussion, all client team members agreed with the new process. Walking into the implementation, neither side assumed this to be possible. However, with collaboration, flexibility and lots of questions, the automatic calculations allowed the client to reduce the time spent each year and create a better auditing tool to back up their allocations.
We wanted them to be receptive to: A.) a new way of data collection; B.) asking questions in a different manner; and C.) building calculations so that their users no longer had to enter all the information manually.
Keeping the end goal of being able to easily consolidate the data and send it off to be reviewed, we helped them revisit the big picture and why they wanted an automated system in the first place. It's all about prioritizing what's most important to you, while keeping your success criteria in mind.
Neither the RMIS provider nor the client goes into an implementation thinking that change is a given. But from my perspective, I think it’s best to remain open. The best implementation is—no let’s say the "highest value" implementation—is one where people keep their minds open.
Marissa Moscowitz is the manager of Project Management with the Aon eSolutions Global Professional Services team. Marissa works from the Aon eSolutions Chicago office. Email Marissa at Marissa.Moscowitz@aon.com.
