When RASCI #2321 is not enough

You know you have a program that is set up to fail when:

There are two thousand three hundred twenty one RASCIs and still no one knows what they are supposed to do and what they are not supposed to do.  And they spend all their time protecting what they think they should do and arguing with the other guy about what they should and shouldn’t be doing.

I’ve been on a program like that.  Every other day someone wanted to create yet another RASCI (if you don’t know what that is, consider yourself lucky) at yet another level of detail to attempt to take responsibility for something; or better yet to place blame on someone else for something that’s not going so well.  Needless to say, not much was getting done except to fight over who did or didn’t do what to who.

I’ve also been on a program where there were no RASCIs at all.  WHAT, not even one?  This was a program where people knew whether they were a screwdriver or a butter knife (see http://visionpeak.wordpress.com/2012/02/01/the-butter-knife-and-the-screwdriver/) and had no desire to be anything else.  Everyone was busy, contributing, and being recognized so it wasn’t necessary to worry about what the butter knife was doing; being a screwdriver was enough. Not only was it enough; it was fun!

Why do you suppose that was?  I believe it’s because every person could see in their own mind exactly where the program was headed.  And people all saw the same picture.  Everyone knew what was required to get there and what their role was (screwdriver or butter knife) in getting there.  They also believed that it took both the screwdrivers and the butter knives to get there, neither was enough alone and neither could do the other’s job near as well.  Trust was implicit.

So how did that come to be?  In this case, investment was made “up front” to create that common vision of what success looked like.  Along with that was a description of what and who was required to get there; both the screwdrivers and the butter knives.  All this, before the implementation program was even launched; there wasn’t a systems integrator in sight (or billing by the RASCI line).  For this program it wasn’t so much about how it was going to be done; it was about figuring out what to do first.

The payback?  An implementation program that was on time and under budget.

Sometimes I twitch when I hear RASCI.  Maybe you might need one RASCI, but many more than that and you’re probably headed for a program that is set up to fail.  And if you feel you need to have that one, it’s best to not have too many lines…

Don’t twitch!

© Ellen Terwilliger 2012

Whatever can go wrong will go wrong – but you can be ready!

In the first week of my brand new career in IT (many, many moons ago) when I wiped out an entire disk drive while performing a backup (I followed the process exactly), through my first implementation (also many, many moons ago) when the physical back plane burned during go live and had to be replaced, to my most recent large scale implementation when the power failed in the command center in the middle of the production data conversion – I have been a victim of Murphy’s Law. On one program a colleague even gave me a framed lithograph of Murphy’s Law engraved on tablets (shown above) since it seemed we were dealing with some sort of disaster on a daily basis! Even today, I probably wouldn’t document any of these specific examples as a risk to my program (since the probability is low of reoccurrence in my lifetime); but I would certainly think about them!

Over the years, I have learned the value of proactively identifying the unique risks that could possibly befall my program (because Murphy never sleeps) so mitigation plans can be developed for those that could derail success. This is especially important for large scale transformational change programs where the opportunity for disaster to strike is more prevalent, just because there are more moving parts. By being prepared in advance, you can often prevent the issue from arising at all (An ounce of prevention is worth a pound of cure!) or at least have a plan in place and avoid panic.

The earlier you begin risk management and mitigation (notice I didn’t stop at just management, you will have to act too) the healthier your program will be and the more likely you are to be successful (remember according to McKinsey less than 40% of transformation programs succeed). In identifying risks, you need a few key pieces of data to start with: risk event/statement, impact statement, impact level of the risk and the probability that the event will occur.

So how do you get started with proactive risk management? I begin with identifying assumptions (Assumptions – Power for Programs). Conflicting and invalid assumptions are primary candidates to create risk although any assumption can lead to risk.

Here’s an example. In an 18 month program, my program manager assumed an eight hour workday in her master project plan (not too unusual, although we all know people often work more than an eight hour day, especially on major programs). Our system integration partner assumed a nine hour workday. Oops, conflicting assumptions! This created a couple of high impact/high probability risks as follows:

• Budget risk: $260,000 in unexpected cost (1 hour per day @ $25/hour for 40 developers for 12 months)

• Schedule risk: missed deadlines (10,400 hour discrepancy)

Since this was identified within the first few weeks of the program, we were able to prevent the risk from occurring by choosing a valid planning assumption and adjusting accordingly: no budget overrun and no missed deadlines (at least not for that reason).

There are different types of risks and many ways to approach risk mitigation. In the example above, we chose to eliminate the risk since it was straightforward to validate one assumption, invalidate the other and act accordingly. This isn’t always possible, so you can choose to minimize the impact of the risk (create a risk mitigation plan) or accept the risk (deal with the consequences should the event occur). A first step toward determining the mitigation approach is to score the risk impact and probability to identify the risks most likely to occur that will have a significant impact on your program. For those that rise to the top, you can take immediate action; eliminating or minimizing the impact. Through routine risk management you will be able to choose your approach for all the risks you identify leading to a greater chance of success for your program.

You can be ready for Murphy when he comes to visit your program!

© Ellen Terwilliger 2012