Risk Assessment and Mitigation Plan (RAMP)

RAMPing up for Project Success….Stopping failure before the project ever begins by Louis Schwartz

If you ever “Google” Risk Mitigation Template its obvious the tool utilized to document risks and

develop mitigation or opportunity responses has been done a thousand times. You may ask, “What

makes this RAMP any different?” I’d say the big difference started with listening to Dean A. at a meeting

in Atlanta last year. He said, “Solution Consultants are supposed to determine why projects fail and

stop that from happening, not identify every risk and work through them.” To put it another way, our

multi-disciplined consulting team needed to focus on “bridges that are out” not identifying “bumps in

the road”. It was like a rock hit me when he said that. I had been worrying about the wrong thing. I

was making sure a deliverable had the proper amount of professional service hours associated with it

when I should have been focusing on the big picture.

Project Managers (PMs) work through bumps in the road. Heck, all projects have bumps and

great PMs handle them with ease. What they can’t handle, because it is out of their span of control, are

risks that require more time, resources, or funds than the project allocates. If in the pre-implementation

process the solution consultant worked closely with the sales specialist they could build in the resources

to the project to overcome “project killers”. The likelihood of project failure would be dramatically

reduced. We needed to think strategically not tactically.

Under Mary Ellen S.’ direction we morphed our Risk Mitigation Tool into one focused on the

customer, their environment and the specific project. We realized we needed to change the way we

identified risks by thinking about three major areas: Past History of the Customer, Current Scope of the

Project and the Current State of the Customer. Then we needed to roll up all the risk symptoms into an

aggregate risk. The standard process of listing risks and assigning them a percentage did not always

answer the question of why the project might fail. It became quite clear that when we asked questions

like “Have we had a successful and profitable project with this customer?” or (if we hadn’t had a project

with them) we asked the customer to tell us about their last successful project, the risk jumps out at a

person. By changing our thinking more than changing a tool we began to take on more of the role of

ensuring project success by “building bridges”.

Building bridges does not just mean adding additional professional service hours as a buffer to

high risk symptoms. It also means consulting with sales and implementation for specific resources for

certain customers based on personalities, adding services or taking them away due to poor value

recognition, and rethinking how our team wants to offer a solution based on our consolidated

experience.

This document represents a change in our methodology. We understand that change takes time,

specially internalizing the change.