Critical success factors in risk management software implementations

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 place to start.

As the senior manager for dozens of risk management information system (RMIS) implementations, I thought it might be helpful to share my insights on how our team uses critical success factors in client projects.

First, let's define the term: Critical success factors 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, our project management team knows CSFs as the three to five items that are the reason the client purchased our software in the first place. CSFs are at a higher level than deliverables; in fact, a single critical success factor will often include three or four deliverables.

Experience has taught us that CSFs are must-haves for a project and must be monitored, visited and visited again throughout the implementation. Experience also teaches that some clients know virtually from day one how they want their RMIS to perform, whereas many others need help refining and articulating their specific CSFs.

The rest of this blog post will discuss how we determine CSFs and put them to work in helping to make implementations successful.

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 in the discussions.

We want to know exactly what the client needs. We want to know, from a business standpoint, what they need the system to do. That way we can make sure the system supports their business. 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 specific goals.

YES, BUT… At first, many clients take the position that, “we expressed our needs to your salesperson. We don’t need to take time to develop success factors.” That is understandable, but implementations are complex efforts. Our experience shows that having the client see the value in developing CSFs upfront helps the project in the long run.

I’'ve found with most engagements, clients tend to start with a master list of six or seven CSFs; major clients can have as many as 10. We work with them to identify the main elements that will make the implementation and ongoing use of the RMIS successful.

With a deep dive into what the key areas of the business are, the client can begin to drive out the three to five key areas. This information goes into a kickoff document for further discussion and paring down. Eventually, it informs the Project Charter, which, thanks to work by both parties, serves as a toolset for managing the implementation.

S.M.A.R.T.? Or not so S.M.A.R.T.?

So, what'’s the best way to determine a project’s CSFs? For our RMIS implementations, our team evaluates proposed success factors against the S.M.A.R.T. criteria. In other words, before adopting a critical success factor, we determine whether it is Specific, Measurable, Achievable, Realistic and Time-bound.

Let'’s consider some examples. Remember, to become a critical success factor, the proposed factors must be:

• Specific
• Measurable
• Achievable
• Realistic
• Time-bound

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. This is S.M.A.R.T. and was adopted as a CSF.
3. A 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. A client required that the loss summary report consistently report data from TPAs on a monthly basis with an error percentage no greater than .001%. This is S.M.A.R.T. and was adopted as a CSF.
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. This is S.M.A.R.T. and was adopted as a CSF.

Developing CSFs into project goals

When a proposed factor passes the S.M.A.R.T. test, we develop CSFs around them that define project goals. The CSFs also became part of status reporting, including milestones like accomplishments and activities as well as risks and issues. This kind of reporting is core to what the project manager does throughout the life of the project; it lets the team know how we’re tracking to goal.

CSFs also help inform us on when to escalate situations and when to say no. They are guides to ensure the solution meets the client’s stated needs from inception through go-live.

Let me point out that as helpful as the S.M.A.R.T. process is, implementations don’'t have to be tied to a formula. The key is to make sure your criteria are specific and measurable. That way, the teams can visit them at interim stages and say, “we're hitting these,” or we're off here, and we know it because we have goals we’re measuring against.” Establishing specific criteria also helps us know when to celebrate the milestones as a project team once we’ve hit them.

Stand and deliver

In earlier blogs, we stated that collaboration between client and provider is critical to an optimal implementation. In developing success factors, I believe it’s vitally important that all team members actively participate in meetings and decisions. For example, if the end goal is a custom report, we work to ensure collaboration between the reporting team and the configuration team during the meetings that determine configuration specifications.

In summary, as a consultant on dozens of implementations, I'’ve observed that “no one stands alone.” 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.

Marissa Moscowitz is the manager of Project Management with the Aon eSolutions Global Professional Services team. Marissa works from the Chicago Aon eSolutions office. Email Marissa at Marissa.Moscowitz@aon.com.