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.
More Posts in This Series |
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.
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 idea of flexibility really comes down to some essential elements:
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.
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.
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.