<img src="https://ws.zoominfo.com/pixel/kZxG1sNctrruFoZSPoVD" width="1" height="1" style="display: none;">
Contact Us
Book A Demo
Menu
Book A Demo
Contact Us

Successful RMIS implementations: Collaboration is vital

successful RMIS implementations collaboration resized 600Remember how, in grade-school report cards, our teachers evaluated us on how well we “worked and played with others”? It all came back to me as I wrote this blog post focusing on the best ways I'’ve found to ensure collaboration between a RMIS company and the client’s project team.

All implementations will have a formal statement of work and generate project plans; however, as a professional project manager who has completed hundreds of RMIS deployments, I can attest that collaboration is a vital component in bringing risk management software successfully online.

Collaboration is something of an intangible factor, but by bearing in mind the following points, we on the Aon eSolutions Professional Services team are trying continuously to promote cooperation.

More Posts in This Series

  1. Introduction
  2. Manage the project collaboratively
  3. Define your success criteria clearly
  4. Capture your organizational hierarchy and reporting structures
  5. Focus on data mapping and data integrity
  6. Build it to scale
  7. Deploy in phases
  8. Encourage user acceptance
  9. Be flexible

Plan communications to meet stakeholder needs

describe the imageI think communication is the most important practice in project management; that's all well and good, but it leads naturally to the question, How do we know what it is, exactly, that we should be communicating?

A good place to start is getting knowledge and understanding of exactly who your stakeholders are and how and when it's most effective to communicate with them. At project kickoffs, we on the Aon eSolutions Professional Services team develop a formal communication plan. We base this plan on a detailed stakeholder analysis that we perform together with the client team during the planning phase. We make sure the plan reflects the level of detail required by each shareholder or group.

For example: One client gave me three minutes a month to communicate to their CEO, which meant I had three minutes to deliver a status report on a $10 million project. How did I do it? I researched what was most important to him and focused only on those project areas. Everything else went into a status report he could review offline.

Address risk and issue management within the project itself

Just as risk management is a critical function in a business, it’'s also one of the most important factors in a successful project implementation. The practice of risk and issue management starts during project inception.

For example: This kind of situation arises with surprising frequency. The client already knows that end-users from, let's say, the Finance department, love the system they use today and are reluctant to change; this is precisely the kind of issue that the combined vendor-client implementation team should record as a potential risk.

Once you'’ve recorded the issue/risk, it's important to evaluate the potential impact and apply mitigation strategies. That means discovering what needs to happen to gain buy-in from, to continue this example, end-users who are happy with the current system. Keep revisiting the issue until you have eliminated that risk. This is the same way you will manage all of the risks and issues that come up on the project. Some of them will be obvious, some not as much.

I find that many project management teams have risk logs, which are a valuable tool for all team members to reference frequently as a resource that enhances collaboration. Yet, in many cases, team members do not actively use risk logs to manage the project. This kind of oversight represents a missed opportunity that can result in negative consequences for the project as a whole.

Manage schedule, cost and scope

Project managers know it as the “triple constraint”: schedule, cost and scope. If one of those variables changes during an implementation, the others must also change, because the variables naturally self-balance, or recalibrate themselves. Imbalances in the schedule-cost-scope relationship can be a major contributor to IT-project failure.

For example: The client asks the vendor, I really, really want to have that feature that was missed in determining scope of work, but I don't have any more budget, and I can't delay the project. Can't you just squeeze it in?” Unless the client and vendor can sit down to adjust cost and schedule, the answer should almost always be something along these lines: “No, for now, because adding this scope will negatively impact budget and timelines, but could we set the request aside for a later phase of the deployment?”

Positioned in positive terms, the triple constraint provides a way for project managers to communicate this paradigm with our stakeholders. If communicated correctly, the concept of the triple constraint can help the joint implementation team achieve the goal (outlined in the first post in this series) of a project that is both structured and flexible.

The provider and client must work together to avoid to adding features that are not critical to the business. It’'s imperative to agree to stay true to the project plan, to meet the objectives you’ve jointly defined.

At the same time, change may be unavoidable: such as a new government regulation or a company acquisition. The important thing is to analyze the change (scope) and understand its effect on cost and schedule.

Managing workloads: the human element

We have found that a crucial, —and often overlooked—, step involves managing employee workloads. On a RMIS implementation, nearly every employee also has a “day job,” and the implementation is an unplanned addition to her or his workload.

Both provider and client should be realistic about time constraints, both foreseen and otherwise, for participants. For example, I'm struck by how often managers fail to build in breaks for vacation and holidays—even emergency work projects that come up—during a months-long implementation.

Other ways to acknowledge the human element of an implementation: celebrate every milestone; hold team-building activities; even make it part of employees’ overall performance goals to meet RMIS project objectives.

Just do it? Or let's just do it together?

In closing, I'’ll point out that many clients want their RMIS provider to “just do the job.” Take over the implementation they say, either overtly or through their actions. It's quite understandable, but it’s also classic silo thinking that is fraught with hazards.

To encourage a collaborative implementation, I make it a point to frequently emphasize one of the key ultimate goals of adopting a RMIS: to improve the organizations working environment and work product. Put in that context, I think it'’s a bit easier to understand why a collaborative implementation should cross all levels of users, business units and departments that will ultimately touch the product. Agreement on this point and cooperation upfront, along with proven project management measures, speeds startup, eases the way for issue resolution and ensures stakeholder buy-in.

In our next post on successful implementations, we'’ll look at the need to clearly define the success criteria. Questions we'’ll address include: What processes do stakeholders want the RMIS to address? How can priorities be set to reflect these goals? We’'ll also address the fundamental questions that can define the project plan around the objectives set forth in the statement of work.

Leslie Sargent, PMP, is a senior member of the Professional Services team with Aon eSolutions. Please email Leslie at leslie.sargent@aon.com.

RMIS Guide

May 22, 2013

 | Originally posted on 

Subscribe by Email