RMIS Applications: Guidelines for Selection and Implementation

September 2001

Tillinghast-Towers Perin consultants David Whitesell and Anita Schoenfeld provide key points an organization should consider to ensure that a new information system is properly selected and smoothly implemented.

by Anita Schoenfeld and David C. Whitesell¹
Tillinghast—Towers Perrin

Selecting and implementing a new risk management information system (RMIS) or claims management information system (CMIS) can be an extremely difficult process. However, it can be done successfully and need not be an undue burden to those involved with the project. This article will briefly cover some of the key aspects of the process an organization should consider to ensure that a new RMIS/CMIS is properly selected and smoothly implemented.

Needs Assessment

It is vital at the beginning of the process to gain a clear understanding of the organization's needs with respect to its RMIS/CMIS. Gathering the essential information can be accomplished using various "needs assessment" approaches. Examples range from structured, one-on-one interviews with key executives to focus group discussions and questionnaires. Often, informal discussions with key personnel are helpful.

The following are some key tasks in the typical needs assessment process:

• Identify all the primary users that have an impact on the RMIS/CMIS environment. The spectrum of users will likely range from individual claim adjusters to key financial and operational executives.
• Define the current functional needs, business processes and procedures, and interactions of each user group. It is often worthwhile during this step to consider the organization's projected needs over the next 3 to 5 years.
• Evaluate the functional needs of each individual user group in light of the organization's overall strategy and informational needs. This step in the needs assessment process may reveal unnecessary, inefficient, or redundant work efforts.
• Document the results of the needs assessment process in sufficient detail to allow the organization to validate and evaluate the needs of each individual user group. Performing this task may reduce the organization's exposure to missing or misinterpreting key needs and delays in successfully implementing a new or updated RMIS/CMIS.
• Prioritize each need in accordance with its relative cost and added value to the organization.

Request for Proposal Process

The next step in selecting an appropriate RMIS/CMIS typically involves creating a concise, structured set of system functional specifications. The documentation from the needs assessment should serve as the basis for the specifications. Depending on the organization's desires and resources, one of the following two options may be taken:

• The request for proposal (RFP) is a formal, detailed structured bidding process for gathering and evaluating responses from pre-selected system vendors. The responses would clearly define costs for each item documented in the RFP.
• The request for information (RFI) is a less-formal process that typically results in a system demonstration with no firm bid, but is sometimes sufficient to meet an organization's needs.

The ultimate goal with either process is to select a software partner(s) that meets the organization's functional, procedural, and informational needs. With careful attention to detail and dedicated management, both the RFP and RFI should achieve successful results.

It can often be difficult to distinguish one software vendor from another in the RMIS/CMIS marketplace. Listed below are some things to consider when evaluating vendor responses resulting from the RFP/RFI:

• Software and hardware platform
  • Size and scalability
  • Program languages
  • Infrastructure requirements
  • Databases
  • Internet and Intranet access
  • Internal and external connectivity
• Company history and expertise
  • Financial strength
  • Size (number of employees per function)
  • Experience with similar implementations
• System functionality
  • Risk management (data collection and analysis, reports and distribution, client access, cost allocation)
  • Claim management (claim administration; payment; financial management; note/comment; diary/job queue; supervision, management, quality controls; medical case management; utilization review; cost allocation)
• Costs
  • Software license
  • User
  • Annual maintenance
  • Customization
  • Project management, implementation, and installation
  • Training
  • Data conversion
  • Middleware, other third-party software
• Clients
  • Current clients
  • Previous clients
  • Client mix
• Security
  • Software
  • Internal and external access
• Interfaces
  • Data sharing
  • Various service organizations

The suggested RFP and RFI steps are as follows:

• Identify all the potential RMIS/CMIS vendors
• Prequalify the vendors by reviewing available marketing material and interviewing persons knowledgeable about the systems and/or the RMIS/CMIS marketplace
• Develop system specifications and RFP/RFI document
• Distribute the RFP or RFI document to the prequalified vendors
• Analyze the responses received, using the categories outlined above. It is helpful at this stage to develop a scorecard or response tally document. Based on this analysis, you should be able to narrow the field of potential vendors and choose the top candidates to participate in oral demonstrations
• Schedule a time for each selected vendor to come to your facility for a formal system demonstration. Attendees from your organization should represent as many of the individual user groups as possible. During the demonstration, be wary of "vaporware," meaning portions of system functionality that may not exist or be fully functional.
• Evaluate all written responses and oral presentations. It may be helpful at this stage to combine a review of the documentation with a facilitated group discussion
• Select the RMIS/CMIS partner(s) that most closely meet(s) your organization's needs

Implementation

Once the RMIS/CMIS partner has been selected, and the contracts have been signed, it is time to implement the system. Hopefully, the steps outlined above have been well thought out and documented. Otherwise, implementation may prove a more difficult and time-consuming task than anticipated. It is important to realize that the implementation process may involve many components and organizations. The key to a smooth transition is to ensure that all parties involved in the implementation are smoothly integrated and that there are open channels of communication.

One critical piece of this process is creating a cooperative and flexible environment in which all participants can easily work together as a team. Most successful organizations have accomplished this by appointing a strong, organized person to manage the entire implementation project. The project manager should have an in-depth knowledge of the business side of the organization and an understanding of how technology is applied and used.

The Project Kick-Off Meeting. Suggested steps for kicking off a new implementation process include the following:

• Identify all key groups that will need to participate. Some examples include:
  • Internal systems (IT) personnel
  • Software vendor
  • Training
  • Risk management and employee benefits
  • Claims administration
  • Quality control and internal audit
  • Management
• Schedule a kick-off meeting facilitated by the project manager. The primary goals of this meeting include:
  • Introducing all participants
  • Providing a high level overview of the project
  • Reviewing the results of the needs assessment and RFP/RFI
  • Gaining a detailed understanding of the new system and its capabilities
  • Reviewing all comments and objections, and confirming their validity
  • Clarifying individual responsibilities ¾ Establishing a tentative timeline for project
  • Identifying next steps

During and after the initial kick-off meeting, other items of importance (such as workflows, user preferences and other internal project deadlines that might conflict) are likely to emerge. The new items need to be evaluated by all impacted user groups. Often there will be some give and take during this process, but it should be well managed within a reasonable timeframe. Hopefully, once the new items are handled, the project manager can create a project plan encompassing all activities needed to successfully implement the new system.

The Project Plan. A typical project plan should at least address the following areas:

• The background and benefits of the project
• The scope of the project, including tasks and major deliverables
• The roles and responsibilities of the project team
• Project timeline, including the target date for key deliverables
• Approvals and success criteria.

The last item mentioned above is important, as it is the formal way of documenting management approval, and it describes the outcomes that dictate whether or not the implementation was successful.

One important aspect of the project plan is creating and maintaining the timeline. This may well be the most time-consuming single task the project manager will have to perform. It is essential that the timeline contain all of the functions that the project team is either managing or performing.

Project Communication. New problems and concerns are likely to arise throughout the implementation process. It is particularly important that the project manager maintain an open line of communication with the system vendor. The project manager can mitigate the effects of major problems and concerns by regularly communicating with all the users groups.

Methods for managing these relationships can include periodic face-to-face meetings, teleconferences/videoconferences or simple e-mail updates. Regardless of the meeting type, they could likely include the following agenda items:

• Introduce any new participants
• Provide a quick summary and status of all the problems, concerns, and any outstanding items from the previous meeting
• Supply a detailed status report of the project
• Solicit any new problems, concerns, and questions the project team may have
• Assign responsibility for any new items that arise
• Agree on the time and form of the next project status meeting

Purposefully we have spent a great deal of time with project management functions such as the project plan and project communication. These items are essential for a successful implementation.

Data Mapping and Conversion. Converting data from a previous system is both a science and an art and requires strict attention to detail. It is imperative that detailed data mapping sessions occur with all members of the project team. The preferred approach to data conversion involves the cooperation of project team members who both understand the functions of the current system and where the data resides within the current database (bits and bytes).

The outcome of the mapping session should be a documented data conversion plan that details exactly where the data now resides and where it will be converted to in the new system. Realize that incorrectly converted data can cause not only project delays, but also potentially serious operational problems. Poorly converted data may also reduce the value of the information presented in typical claims and risk management reports.

Testing. It is imperative that the new system be adequately tested before going live. This often involves having key project team members and representatives of the user community test it in stages. This should be done far in advance of the go-live date to provide sufficient time for changes and refinements.

Testing should encompass many of the following items:

• System functionality
• Workflow functionality
• Stress or capacity testing
• Data import/export and interfaces
• Security

Training. A variety of training methods should be used according to the specific needs of the various users. One-size-fits-all training is not effective. For example, many users who have been working on legacy style systems may not be accustomed to a typical Windows environment. Therefore, the user would need additional time and training to adapt to the new system

It is imperative that the trainer(s) have a solid technological and functional understanding of the new system. Trainers who are only technology-oriented may miss the underlying reasons for certain functions or purposes of the system. Likewise, trainers from the user community may have a tendency to only present those aspects of the system necessary to perform there jobs, possibly missing key functional improvements and shortcuts. Training on both sides of the system is necessary. Also, training should occur as close to the actual go-live date as possible. Training materials should have both visual and written instructions to accommodate the different learning methods of various users.

Conclusion

Selecting and implementing a new RMIS/CMIS takes a great deal of planning, communication, and the cooperation among a number of various parties. Effective project management, data conversion, testing, and training are essential to achieve a successful implementation.

---

¹This article was written by David C. Whitesell and edited by Anita Schoenfeld.

David Whitesell is a risk management consultant with Tillinghast-Towers Perrin in its Dallas office. He has 19 years of experience in the insurance industry in a wide range of technology and product development, claim office, and call center management roles. Mr. Whitesell recently joined Towers Perrin in May 2001 as a risk management consultant from an independent technology-consulting firm. At Tillinghast, he has undertaken a variety of risk management assignments with a focus on strategic risk financing and risk management information systems (RMIS). His consulting services include information systems analysis, design, bidding and selection; operational claim reviews; workflow analysis; organizational planning and administration; contract analysis; strategic risk financing.

---

Opinions expressed in Expert Commentary articles are those of the author and are not necessarily held by the author's employer or IRMI. Expert Commentary articles and other IRMI Online content do not purport to provide legal, accounting, or other professional advice or opinion. If such advice is needed, consult with your attorney, accountant, or other qualified adviser.