The acquisition of a Risk Management Information System (RMIS) is a project that presents serious long-term implications for your organization.  Here are some of the risks along with proven ways to improve your satisfaction with your new RMIS, regardless of which vendor you select:

THE RISK – Managing Your Implementation.

Many organizations in this industry have been burned by poor or completely failed implementations.  While a certain amount of hesitation is expected, it is entirely possible to manage the implementation stage to meet scope, timeline, and budget. Will your organization experience a failed implementation that must be aborted?

MITIGATION

1. Avoid making assumptions. For example, a client asks the vendor if they can do web-based intake.  The client assumes all state reporting and EDI is included in the intake, and the vendor assumes the client is just asking if they can do web-based intake. Each process should be discovered and documented as a part of the Statement of Work (SOW), including very clear deliverables.
2. Never depend on a timeframe estimate from sales.  Insist on hearing it directly from the person in the vendor organization that is responsible for actually delivering the Implementation. (and make sure sales isn’t in the room glaring at the promiser)
3. Make resources available to properly scope the project.  Revisit scope and budget during contract negotiations to remind the vendor they are about to sign their name to a legal document that contains cost and timeframes.
4. Facilitate the transfer of your data from any third parties (TPA, broker, etc.) to the vendor.  Data problems, including very late arriving data or poorly formatted data arriving with errors, can severely set back an implementation plan. If possible, find out from your data sources what they can deliver, when and for how much before you sign a statement of work. (The data providers OFTEN charge to produce the data files – this is not typically covered in the RMIS vendor’s quote)
5. Be patient with the different teams the vendor will bring in to help with your implementation (sales in the beginning, then security, then data converters, then technicians, etc).  You may have to repeat some of the discovery for these teams, but recognize that the process helps validate your needs, scope and the overall design of the project.
6. Discuss with your vendor your own resource requirements and the amount of time that will be required at different phases of the implementation.  Ensure those resources are available as needed.
7. Apply project management skills to your implementation to avoid negative consequences caused by undefined or changing scope, and keep the lines of communication open between your team and your vendor.
8. If you do bring in an outside consultant to help manage the project, instruct your consultant that their job is to facilitate communication BOTH ways – not just beat up the vendor.  I’ve seen many clients get frustrated because “it seems so simple” to them despite their lack of any experience in this technical area.    They need an objective third party to give them some hard truth from time to time.