Risk Management Software Implementation Guide eBook

RISK MANAGEMENT
SOFTWARE DEPLOYMENT
Your Guidebook to Success

RISK MANAGEMENT
SOFTWARE DEPLOYMENT
Your Guidebook to Success
2015-10-21

RISK MANAGEMENT SOFTWARE DEPLOYMENT: YOUR GUIDEBOOK TO SUCCESS 1
INTRODUCTION
But before you get started, we recommend you explore the key factors that make for
a smoothly executed and successful implementation. The Ventiv professional services
team has been involved in more than 400 implementations, and through this experience
we have developed some keen insights into best practices for effectively transitioning to
a new RMIS.
In the pages to follow, we offer eight guidelines for success to help you greatly improve
the odds of an efficient, successful RMIS implementation. As you proceed, you’ll
notice a consistent theme that emerges in each of these guidelines: The importance
of establishing structure while also remaining flexible. Though it might seem like a
paradox (structure and flexibility?), you’ll soon learn that it is an important mindset to
understand and adopt.
Great news:
You’re planning to deploy a new Risk Management Information System, or RMIS.
Today’s risk management software can contribute to transformational change across
the organization — from the risk manager’s own desk right up to the C-suite.

MANAGING THE PROJECT
COLLABORATIVELY
Successful implementations are collaborative in
nature. This means that from day one they have a
project lead and resources from a partner as you’d
expect, and a project lead and support personnel
from the client, which you may not expect.
This section focuses on best practices in
project management.
1. Plan communications to meet stakeholder needs
2. Address risk and issue management within the project itself
3. Manage schedule, cost and scope
4. Managing workloads: The human element

Remember how, in grade school report cards, our teachers evaluated us on how
well we worked and played with others? Well, this section may take you back as
we address the best ways to ensure collaboration between a technology provider
and the client’s project team.
All implementations will have a formal statement of work and generate project
plans. But in bringing risk management software successfully online, collaboration
is certainly a most vital component.
Collaboration is something of an intangible factor, but you’ll likely find the following
points useful in continuously promoting cooperation.

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. 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 end users who
are happy with the current system. Keep revisiting the issue until you’ve
eliminated that risk. Many project managers also have risk logs, which
are valuable tools for all team members to reference frequently as a
resource that enhances collaboration.
ADDRESS RISK AND ISSUE MANAGEMENT WITHIN
THE PROJECT ITSELF
How do we know exactly what should be communicated? 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, our Professional Services team develops 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.
PLAN COMMUNICATIONS TO MEET STAKEHOLDER NEEDS

We have found that a crucial, and often overlooked step involves
managing employee workloads.
On an 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.
Managers should build in breaks for vacation and holidays, and allow for
potential emergency projects to arise. And they can celebrate milestones,
hold team-building activities and build RMIS project activities into overall
performance goals. Some clients simply want their RMIS provider to do
the job. But we continue to encourage a collaborative implementation
since one of the key ultimate goals of adopting an RMIS is to improve
the organization’s working environment and work product. Put in that
context, 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.
MANAGING WORKLOADS: THE HUMAN ELEMENT
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. Positioned in positive terms, and if
communicated correctly, the triple constraint provides a way for project
managers to communicate this paradigm with our stakeholders. The
provider and client must work together to avoid adding features that
are not critical to the business. They must agree and stay true to the
project plan to meet objectives they’ve jointly defined. But often change
is unavoidable; the important thing is to analyze the change (scope) and
understand the effect on cost and schedule.
MANAGE SCHEDULE, COST AND SCOPE

DEFINING CRITICAL
SUCCESS FACTORS
Clearly defined success criteria allow the
team to define the project plan around key
stakeholder objectives.
This section discusses in detail how the
implementation team should build on the
objectives set forth in the statement of work.
1. Critical Success Factors (CSFs)
2. S.M.A.R.T.? Or not so S.M.A.R.T.?

CSFs = critical risk management needs
As soon as the contract is signed, our project management team asks our
own sales team and solution consultants: What does the client want from
this RMIS? What can you tell us about the client’s critical success factors?
At the kickoff meeting, we ask the client: What are your challenges? What
do you want to improve? How will we know we’ve improved the ways you
handle your challenges?
We make sure the discussions are interactive and that all client
stakeholders, as appropriate, take part. By arriving at CSFs early in the
project we help ensure the system is developed, tested and accomplished
in a way that is aligned with functional needs and specific business goals.
With most engagements, clients tend to start with a master list of six or
seven CSFs; larger clients can have as many as 10.
When your organization faces an IT implementation, how do you
know the best place to begin? Identifying and developing the “critical
success factors” (CSFs) that will shape and guide the project is a great
first step. CSFs are the limited number of areas in which satisfactory
results from the implementation will ensure successful competitive
performance for the individual, the department and the organization.
In practice, CSFs often represent the three to five items that are the
reason the client purchased risk management software in the first
place. They are must-haves for a project and must be monitored,
visited and visited again throughout the implementation. Let’s explore
how we determine CSFs and put them to work in helping to make
implementations successful.
CRITICAL SUCCESS FACTORS (CSFs)

STAND AND DELIVER
In developing success factors, it is
vitally important that all team members
actively collaborate and participate in
meetings and decisions. If the project
succeeds, the team succeeds. The same
holds true if the project falls short.
Getting the teams to think about end
goals requires both sides to go through
the discipline of considering question
after question, developing the CSFs
and then using them as the actionable,
measurable toolset they’re meant to be.
S.M.A.R.T.? OR NOT SO S.M.A.R.T.?
1. The client required the system to generate
reports without manual intervention. Moreover,
the new reports had to match the current
manual reporting template exactly. And, the new
reports had to be delivered by the end of the
third quarter.
This is S.M.A.R.T. and was adopted as a CSF.
2. The client required the claim form to be sent
automatically to the carrier within exactly two
days of the claim being reported. The reason?
The government required the claim in a specific
format; if it missed the timeframe, the client
would be fined $1,000 a day.
3. The client proposed a project goal that “every
module be delivered on time and budget.”
This is close, but not S.M.A.R.T. enough; it was
too vague and too difficult to measure.
4. The client required that the loss summary
report consistently reports data from TPAs on
a monthly basis with an error percentage no
greater than .001%.
5. The client wanted the RMIS to develop seven
custom reports that provided ‘what-if’ scenarios
by September 30 so that their actuaries
could review the results and meet the client’s
December 1 insurance renewal deadline.
So, what’s the best way to determine a project’s CSFs?
For our RMIS implementations, we evaluate proposed success factors against the S.M.A.R.T. criteria.
We adopt a CSF only if we determine it is Specific, Measurable, Achievable, Realistic and Time-bound.
A few examples:

SHAPING
ORGANIZATIONAL
HIERARCHY
AND REPORTING
STRUCTURES
Identifying your company’s location (or site)
hierarchy and reporting structures is the backbone
of any implementation. It seems simple enough, but
we’ve found again and again that it’s an important
area for the client and vendor to examine in detail.
In this section, we discuss how your RMIS can
support you in capturing distinct levels and identifying
elements such as a location’s legal entity, division,
region and accounting and operational status, among
other identifiers.
1. So, how to start?
2. Chance for a fresh start
3. The management question

You’ve got to get organized. It may be something you say to yourself or
remind others of at home or at work. When it comes to implementing a Risk
Management Information System (RMIS), getting organized isn’t optional. Having
good organizational hierarchy and reporting structures in place is a critical part
of ensuring that risk management software delivers business value and strong
return on investment.
As the blueprint for the entire RMIS, a workable hierarchy:
• Maps the workflows.
• Establishes formats for loading data into the system and generating reports.
• Integrates the units, personnel and roles.
• Captures the distinct levels within the organization.
• Indicates down to the user level what the roles are and who should be included in
accessing data and reporting.
We find that most organizational hierarchies include:
• The location’s legal entity at the highest level.
• The disparate divisions, regions, accounting and operational status.
• Any other identifiers that come into play.
Risk managers need to know that users of risk management software have the
appropriate permissions to view the data they are tracking in the RMIS. From there,
users can perform analytics on the information and make solid business decisions
based on that information.

Whether a client is implementing an RMIS for the first time or moving
from an existing system, the setup of the organizational hierarchy
offers a good checkpoint. The setup process is an opportunity to
review: Existing workflows, levels of user security, types and formats
of reports and access, and processes and practices.
Clients who have prior systems can look at what they have and confirm
that it’s the structure they want going forward. This may be a juncture to
improve on that structure so that they’re able to create reports that are
the same across the board.
They can consider introducing best practices at this point. They may want
to modify business workflows to gain efficiencies, to improve reporting or
to redefine levels of users that better reflect security needs.
With the guidance of the RMIS provider, clients can validate that this
is still the best way to structure these elements to manage the risk
management side of their business.
We remind clients: You’ve bought new risk management software
for a reason. Take this opportunity to address the areas that were
disjointed or weren’t working well, then modify the system’s structures
to remedy them.
CHANCE FOR A FRESH START
As our team launches an implementation, we often find the client has
some type of hierarchy in place. They may have an existing RMIS. They
may be receiving data from one or more third-party administrators,
each of whom has its own format. The client may have an in-house
system. Or, there may be a combination of all of the above. Even a
loosely structured hierarchy is a starting point for discussing and
mapping out a new structure.
At this early stage we urge clients to understand how valuable it is
to have all parties using the same structure. To that end, the RMIS
structure should:
• Work for third-party administrators handling the organization’s claims.
• Align with the organizational structure from, for example, an SAP or an
Oracle system.
• Enable the risk management team to produce reports in line with how top
management wants to see its data.
To steer clients in their hierarchy decisions, we often provide them with
generic examples of structures that similar organizations have in place
and prepare examples using the client’s own data.
SO, HOW TO START?

The management question clients often want to know,
once their organizational hierarchy is in place, is what can
they expect in terms of managing it going forward?
Our answer is: It varies. Ideally, the RMIS will have the tools
that allow the client to manage and maintain their hierarchy
through virtually any event, including:
• A merger with a new company.
• Expansion and added locations.
• Acquisitions and diversifications.
All of these scenarios require a hierarchy that is flexible
enough to support the client throughout any modifications
to organizational hierarchy and reporting structures.
Such flexibility will provide:
• Seamless integration from one set of data sources to the
new hierarchy.
• Automatic data loads, with little or no manual intervention.
• Functionality that keeps all data in sync with whatever their
systems may be.
Whether it’s an easy drag and drop to move their structure
around, adding new locations or expiring locations that are
no longer needed, the hierarchy must be designed to make
these updates automatically for them. The goal is to take
the manual component out of their jobs so they can focus on
making informed decisions based on reliable information
to support decision making.
THE MANAGEMENT QUESTION

FOCUSING ON
DATA MAPPING AND
DATA INTEGRITY
If you are bringing in data from external sources,
coordinating the receipt and overall quality of the
data is essential to keeping your project on track.
This is a critical phase that incorporates data load
setup, processing, balancing, error notification
and auditing. An effective data conversion process
is central to a successful transition. From our
perspective of hundreds of data conversions
involving thousands of sources, we address how data
mapping and data integrity have a profound impact
on an implementation.
1. Chance for a fresh start
2. Risk data quality: Checks and balances
3. Large swings in data size or financials
4. Establishing sound protocols
5. Importance of a seasoned team
6. Spotlight on data security

The act of carefully managing data as it is brought into a Risk Management
Information System (RMIS) is critical. A strong data integrity plan enables risk
management software to efficiently extract data from a multitude of sources,
formats and files and then convert it flawlessly to the new data structures
established within the RMIS.
In terms of the quality and consistency of information the RMIS manages, the data
structure determines whether the system meets or fails to meet expectations.
That’s why we work closely with our clients to carefully design their data intake and
loading processes. From the perspective of successful data coverage, these factors
are critical:
• Providing an automated, reliable data-load process.
• Incorporating automated, robust balancing mechanisms that provide error notification
in the event a file doesn’t balance or arrive.
• Incorporating regular auditing with each load.
CHANCE FOR A FRESH START

It’s important to notice any unusual activity in data updates as
well. This could indicate that something went wrong with the
production of the file or that a change was made in the data source.
Using custom automated controls designed for each individual data
source, we can alert both our team and the client if unusual activity
is received on a particular file. We can make sure that any changes
in frequency or dollar swings are accounted for, investigated and
corrected, if necessary.
No matter how well a database is designed, if the data itself is not
accurate, it won’t be worth much. That’s why we put protocols in place
that will monitor the integrity of data entering the RMIS.
In terms of monitoring data accuracy, the concept of “balancing” is
critical. A good data intake process must include methods for reconciling
(or balancing) numerous variables. The number of records in the RMIS
should be balanced with the number of records in the source data.
Likewise, there is also financial balancing, which ensures the risk
management software is bringing in the correct dollar amounts and that
they’re adding up correctly.
LARGE SWINGS IN DATA SIZE OR FINANCIALSRISK DATA QUALITY: CHECKS AND BALANCES

One of the best assets an RMIS provider can bring is a seasoned data
team that knows what to look for and can help the client design the
data conversion process to meet the agreed-upon goals.
For a client who already has an RMIS but is changing vendors, the team
can help ensure that the new reports balance as the prior ones have done.
Once the client makes the transition, they are usually thrilled to have a
reliable dataset on which to base critical business decisions. They have all
their data aggregated in one place, from all their different vendors as well
as any internal systems, and can report on all that data across coverages,
currencies, policies, etc. The process is automated, with controls and
alerts built in.
We work with clients to determine the sources, volumes and formats
of their data. We consult closely and then create custom balancing
functions, both for the initial and the ongoing loads. Different clients
can have very different historical data scenarios, from processing
claims themselves using an in-house system to having multiple
vendors that handle different claims sets. Or, a client may have one
vendor doing the entire dataset, but they might have switched vendors
from time to time. Or it could be a combination of those, as well.
These clients benefit universally from a high-quality mapping process.
It is a huge benefit to them to have all of their data aggregated into one
spot, in a consistent format, and auto-checked for accuracy. The active
import of the data is itself an audit of the data. The mapping process
shows if there are any anomalies.
IMPORTANCE OF A SEASONED TEAMESTABLISHING SOUND PROTOCOLS

Clients are also calling for extreme security across all the data that
their RMIS handles. With all the sensitive information RMIS systems
are handling today, they are insisting that it be both encrypted and
sent securely. The setup must also ensure that the data is accessible
to only those users who need it in order to load data into the system.
This focus on security will continue, particularly with emphasis on
requirements like HIPAA. RMIS providers must have the controls in
place to keep the data secure.
SPOTLIGHT ON DATA SECURITY

BUILDING YOUR RMIS
FOR GROWTH
No one knows what the future holds. Consider
whether or not the RMIS vendor has the organizational
structure to support your operations and whether the
risk management software can grow as you expand
your needs. Is the system able to flexibly meet your
changing business demands? Does its architecture
provide the opportunity to configure client-specific
modules and scale their use as needed? Can it handle
data volumes from all of your sources without the need
to archive data?
1. Building your RMIS for growth
2. The power of brainstorming
3. Understanding workflows
4. Beyond manual spreadsheets
5. Keep within a manageable scale, then expand

When an organization moves to a new Risk Management Information System
(RMIS), it is usually making the change for a specific reason or reasons. Perhaps
the organization requires more flexibility in tracking and reporting data. Maybe
it wants the more powerful functionality that technology can provide. It may
want to handle its risk management operations more efficiently across multiple
departments, from field user up to the C-suite level.
Regardless of motivation, one question our implementation team likes to look at
with a new client is how the RMIS we’re developing today will be ready to support
the client’s needs in the future. While the implementation process itself can
command the full attention of both the provider and the client’s teams, we still
advise taking the time to consider how the solution will grow to meet the client’s
needs as the organization evolves.
BUILDING YOUR RMIS FOR GROWTH

We often find it works well to understand the organization’s current
workflows. We focus on what their pain points are today, and then look
at what’s not working.
Once we have a good understanding of the workflows, we discuss where
they see the RMIS in the next two years, three years — even five years.
Are there other modules or capabilities they’ll need, or other critical data
they’d like to capture?
We realize that these are longer term, even visionary questions,
particularly for a first-time RMIS client. But even having a basic wish list
of how the RMIS could support them gives us a jump-start on deploying
the new system.
UNDERSTANDING WORKFLOWS
This step can be as simple as a collaborative brainstorming session.
For example, we can pose the scenario: “We’re tracking these five
claim types in the system today. But we also have claims for areas X, Y
and Z. How can we make sure the RMIS can accommodate this change?
Can we build a system now that will track those additional claim types
effectively, as well?”
The answer doesn’t have to be definite, as in, “These are the exact
reports we’ll need,” or, “This is the exact data we’re going to capture.”
It’s more a case of, “This is our policy information now, and in the future
it would help to understand how our claims are impacting our policies
and insurers.” This kind of information helps ensure that we are aware of
future needs and are making decisions today that will allow the client to
grow into this setup.
THE POWER OF BRAINSTORMING

It’s best not to make an initial implementation too large. Instead,
start with an implementation — and the scope of the RMIS — within
a scale that’s comfortable to work with. There’s nothing wrong with a
phased implementation, especially for a client who is implementing
an RMIS for the first time. The ideal scenario is to roll it out to a scale
they can support.
But we also don’t want clients hampered by a system that can’t go
beyond the deliverables in the initial implementation. So, we encourage
thinking a couple of years out about what they’re expecting their RMIS
system to provide and how that will impact the effectiveness of their
risk management operations.
KEEP WITHIN A MANAGEABLE SCALE, THEN EXPAND
Many times, we see first-time clients who are migrating to an RMIS
from using an Excel spreadsheet method of data capture. The risk
manager is looking for an RMIS to bring in spreadsheets submitted
from the field, update property values and produce a statement
of values on an annual basis.
Their initial implementation meets the goal: It enables them to pull in
basic data quickly and provide some basic reporting. But frequently the
next step is to have the field-level staff logging on to the RMIS, updating
their information in the system and allowing the risk manager to review
and make sure the numbers make sense.
Here, the client is moving away from a very labor-intensive process of
pulling together multiple spreadsheets or statements of values and
consolidating them into one that can produce actionable reports.
By taking a forward-looking approach, we can deploy the implementation
by understanding what fields users will update regularly, and what
approval process needs to be put in place.
BEYOND MANUAL SPREADSHEETS

IMPLEMENTING THE
NEW SYSTEM IN PHASES
We encourage clients to plan on deploying portions
of their risk management software over time. This
enables your team to gain firsthand experience with
each phase. Furthermore, performing lessons-learned
studies between phases can help the collaborative
team find better ways to meet stakeholder needs in
upcoming phases. As a result, the latter phases will
proceed more smoothly, your team will have fewer
issues and you’ll better address obstacles while
they’re manageable.
Another plus: You’ll build buy-in from stakeholders
as they witness the benefits of the early phases.
1. Guiding Factor #1: Project size
2. Guiding Factor #2: Availability of necessary personnel
3. Guiding Factor #3: Client-side support and resources
4. Guiding Factor #4: System training

Perhaps the biggest advantage is that the client-side sponsor and
the RMIS provider can gain buy-in from stakeholders as they become
comfortable with each aspect of the technology. Stakeholders — from end
users to executive-level sponsors — will see the benefits of a new system
as it is being deployed. And finally, new users are less likely to report
concerns or revert back to their prior risk management methods (e.g.
relying solely on spreadsheets).
Experience shows us that implementing a new system in phases — in
defined, manageable segments — can be a win-win for both the RMIS
provider and the client.
The reasoning behind this is based on three key considerations:
1. Deploying risk management software in a step-by-step fashion allows the
client to gain firsthand experience as the installation is progressing.
2. Members of the client team can then experience some early successes from
using the new system.
3. Both client and provider benefit from lessons learned at various stages along
the way.

Typically, when a project team is assigned to an implementation, we look
at availability and skill sets and assign people for the entire project. If we
take a phased approach, we can reassess our personnel requirements
as we go and assign the best resources to the subsequent parts of the
project. This is true on the client’s side as well.
Using a phased approach, we bring on the appropriate people for data
consolidation and, when the time comes, deploy the renewal people for
the property side. Phasing allows the provider and the client to put the
most qualified personnel on each phase of the project. Phasing enables
better coordination of skill sets and schedules across various team
members.
GUIDING FACTOR #2: AVAILABILITY OF NECESSARY PERSONNEL
A phased implementation may not be ideal for every implementation.
The determining factors are the size of the project, timing and project
deadlines. Successful implementations adhere to a proven and agreed-
upon methodology. For example, the project kickoff meeting will include
a mutual review of the implementation methodology to ensure a collective
understanding of the project. We can develop the project plan, highlighting
the separate phases and the time anticipated to complete each phase.
GUIDING FACTOR #1: PROJECT SIZE

The phased approach to RMIS implementation also pays dividends from
a training perspective. When the RMIS provider can focus the training
efforts on one piece of the system at a time, trainees are more likely to get
comfortable with and accept the system. In addition, a focus on training
also gives the RMIS provider’s account team time to build a relationship
with the client, experience success with the system and, later, roll out the
subsequent parts of the system.
GUIDING FACTOR #4: SYSTEM TRAINING
At times, we work with risk managers from sizable organizations who
have dedicated IT teams that routinely manage major projects. As a
result, these clients have the appropriate people available, they know
their schedule and they know the skill sets of the resources who are
coming onto the team.
By contrast, we’ve seen cases where a small risk management team is
tasked with the implementation, even as the team has, for example, its
renewal period coming up in three months.
On these small- to medium-sized projects, the risk manager is trying
to organize the project as well as do their day-to-day job of insurance
renewal, claims adjusting and all the other things that go on day-to-day.
In cases like this, we’ll sit down with this client and take them through a
discussion that helps to identify critical near-term needs, objectives that
can wait and how to identify who on the client’s team can handle which
tasks in combination with their normal duties.
GUIDING FACTOR #3: CLIENT-SIDE SUPPORT AND RESOURCES

ENCOURAGING USER-
ACCEPTANCE TESTING
Engage soon-to-be end users early and often.
Don’t let the first time that they see or test
their portion of the RMIS be during their go-live
training session. Key users should be engaged in
review of requirements and testing of the solution
throughout the project to validate that pre-defined
success criteria are being met prior to engaging
all end users.
1. First: Engage users from the beginning
2. Second: Test each deliverable as it is delivered
3. Third: Address the issue of time
4. What to test? Test scripts that consider actual scenarios

In previous sections, we’ve emphasized the importance of the client and RMIS
provider working together. This is especially important during user-acceptance
testing (UAT). UAT is, at its core, a process meant to determine if the software
complies with the requirements and success criteria defined for the Risk
Management Information System being deployed.
Why is user-acceptance testing so important? UAT sets the stage for users to
embrace a new system in three key ways:
• At the most basic level, UAT lets end users get their hands on the system before
it goes live.
• UAT gives end users the opportunity to ensure that the system will support their
business processes.
• And finally, UAT allows end users to be sure that the RMIS is functional and useful
from their perspective.
In this section, we show you how we coach clients to build UAT into their process.

Testing deliverables as they’re delivered means that user input should
be solicited throughout the deployment — not just at the end of the
implementation or at a critical juncture. By doing so, the client and
RMIS provider are more likely to uncover issues that will be most
effectively addressed before the next deliverable is delivered.
SECOND: TEST EACH DELIVERABLE AS IT IS DELIVERED
The actual users should be involved early in the process to make sure
the RMIS provider understands their business requirements and that
test cases and test scripts align with those requirements (more on test
scripts in a moment). In fact, we encourage users to help define the
actual test steps for the business testing, and that happens at the very
beginning of the project.
Clients often ask us who should be involved in testing. We recommend
having end users from various parts of the organization.
When we start an implementation, we begin talking about testing as early
as the requirements gathering (or discovery) stage and we make sure it’s
included in the project plan.
FIRST: ENGAGE USERS FROM THE BEGINNING

For the actual tests, we have clients provide us with sample
scenarios they’ll encounter — both typical and problem scenarios.
We also like to test the less likely scenarios that are outside the
norm of everyday operations.
If users come across an issue, it’s often not really an issue; it may have
been the way the data was entered or the workflow that was used. The
testing will help determine if it’s something that can be addressed in
training, or if we want to actually incorporate a change into the project.
In developing the test scripts, we believe the RMIS provider should
support the client. The provider can bring experience in the areas that
make the most sense to test. They’ll know how to develop the test plans
and scripts. They’ll know the functional elements to look for. And if they
do find something, they’ll know what it means and if it aligns with or
is outside of the original business objectives. This is an example of the
consultative value an RMIS provider can and should bring during testing.
WHAT TO TEST? TEST SCRIPTS THAT CONSIDER ACTUAL SCENARIOS
For virtually every client, time is the biggest obstacle. End users have
their day jobs. Sometimes they have their own day job and then some!
Whereas the client’s IT staff may have set aside time for the project,
the end users usually have a full workload they have to carry.
In these cases, we caution the client: When users don’t have the time to
invest in doing the testing, or they want to rely on the provider or their IT
staff to do it, the client runs the risk that some top-level requirements
won’t be met. Or, they’ll have to spend more time at the end of the
deployment resolving unexpected issues.
THIRD: ADDRESS THE ISSUE OF TIME

STICKING TO THE
PLAN, BUT REMAINING
FLEXIBLE
As the saying goes: “The best-laid plans of mice and
men often go astray.” An RMIS deployment is no
exception to this principle. While a formal project
management methodology will give structure to your
development and delivery, it’s equally important
to go into an RMIS project with a flexible mindset.
Understand what is essential to your success
criteria and what the “nice-to-haves” are. The right
toolset for a successful implementation includes
a collaborative approach to project management,
the ability to configure your solution to meet your
business needs and the flexibility to allocate
resources as needed.
1. The “top three” for flexibility
2. The value in being open to revisions
3. Remain open to suggestions

Flexibility in the process creates a cooperative mindset for both provider
and client, but it still allows the project to meet the stated success
criteria, and even the milestones.
The idea of flexibility really comes down to some essential elements:
1. Introducing the concept of collaboration early.
2. Making provider-client communication a priority.
3. Linking any changes back to the success criteria.
A desirable trait that some organizations deploying an RMIS may find
surprising is flexibility. Why flexibility? Because even though both
the 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.
THE “TOP THREE” FOR FLEXIBILITY

To show how flexibility can be a powerful ally, here’s an illustration
from a retail client. Going into the implementation, their number one
requirement was to implement incident entry capabilities in their new
RMIS in time for Memorial Day. But 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 to
make it easier for the end users to adopt the new system — particularly
employees new to risk management automation.
These added functionalities would ultimately result in less work for the
users responsible for field-level data entry. But because the additions
were substantial, 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 at the options, the client was convinced of the value they’d get
from faster rates of user adoption since, by building in better functionality,
end users could get back to their “day jobs” more quickly and take to
the system faster. We agreed, and that’s the course we took. And we still
came very close to our original go-live date because the system was
easier for new users to learn and adopt.
Ultimately, it was easy to collaboratively arrive at this decision, as both
sides wanted what was best for the project, the client and the users who
would be hands-on with the system.
THE VALUE IN BEING OPEN TO REVISIONS

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.
An example: We have had clients who were moving to an 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 recreating 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 experience shows us that it’s best to
remain open. The best implementation — no, let’s say the “highest value”
implementation — is one where people keep their minds open.
REMAIN OPEN TO SUGGESTIONS

CONCLUSION
We hope you’ve found this eBook
useful in envisioning a successful
RMIS implementation within your
company. To learn more about
how Ventiv Technology can help
your organization, please contact
us through the information on the
following page or by visiting
www.ventivtech.com

APAC
Justin Gale
GENERAL MANAGER
+61.2.8669.7201
justin.gale@ventivtech.com
Americas
Wes Foster
VICE PRESIDENT
+1.770.308.5620
wes.foster@ventivtech.com
EMEA
Steve Cloutman
MANAGING DIRECTOR
+44 20 3817 7373
steve.cloutman@ventivtech.com

Risk Management Software Implementation Guide eBook

More Related Content

What's hot (20)

Similar to Risk Management Software Implementation Guide eBook (20)

Risk Management Software Implementation Guide eBook