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

Assumptions – Power for Programs

The most powerful tool I use in leading transformational change programs is assumption management. Over the years, I have contracted with hundreds of project managers and most of the leading system integrators; none of them actively used assumptions. Maybe you are wondering what I am even talking about.

One place assumption management has been discussed is in regards to software development and defects by The Software Engineering Institute (SEI) at Carnegie Mellon. The article states that most of the defects discovered in existing systems were probably caused by invalid or changed assumptions. I believe major programs fail, or experience huge cost overruns , for the same reason. Many programs don’t even consider what assumptions are out there. Project management methodologies refer to assumptions and there are even a few companies that have based an offering on assumptions and risk management, but very few programs actively use assumption management as a communication and alignment tool throughout the project lifecycle.

First of all, what are assumptions? Merriam Webster says an assumption is a fact or statement (as a proposition, axiom, postulate, or notion) taken for granted. No matter how many people are involved at whatever stage of your program, everyone is making assumptions and taking for granted that something is in fact true. And I can guarantee you – assumptions are being made that are mutually exclusive; they conflict with each other. Why does that happen? Diversity is a key aspect of transformation teams, individuals are selected to provide broad perspectives and different points of view, so it is natural to see things differently and therefore assume different things. Assumptions are not right or wrong; they are just valid or invalid within the context and timeframe of your specific program. The power in that is that people don’t need to fear assumptions.

What do you do about assumptions, especially those that conflict? The first thing is to identify and document assumptions. If you don’t know what they are, at each stage of your program, you certainly can’t do anything about them. Depending on the stage and size of the program there are different ways to collect assumptions; interviews and questionnaires being the most common methods. I then use a matrix to categorize and de-duplicate the assumptions. The matrix provides the framework for the assumption validation meeting; where the cross functional team rapidly reviews every assumption for validity and risk potential (more on that in another blog) with special focus on conflicting assumptions. If conflicts cannot rapidly be resolved then they are set aside for deeper review and validation. You’ll find that a lot of other assumptions come out during the validation meeting allowing for an even deeper understanding of the program. This type of meeting is one of the most effective communication and alignment tools I’ve used; people are open, engaged and animated; they come away with a real sense of ownership because they are involved. All this increases the probability of success for your program.

Remember that assumptions are vulnerable; they can change or become invalid over time. That is why periodic review and refresh is essential for longer duration programs. I recommend stage gates and/or testing events as opportune times to collect, review and revalidate assumptions or incorporate assumptions as part of risk management. After all, an ounce of prevention is worth a pound of cure.

Can you see the power of using assumption management in your programs?

 © Ellen Terwilliger 2012

Related articles

• Project Wisdom: Step 1 (tuitionpaidlessonlearned.wordpress.com)

Get to the cloud (and save money)!

How many C-level executives have heard or uttered this phrase in the last week; for that matter in the last 24 hours? And how many of them really know what they are asking for?

The National Institute of Standards and Technology gives a good high level definition of the cloud. Is cloud computing really that new? As with most things, life is circular (what goes around comes around), so maybe the technology specifics are new but not the concept. Anyway, the definition states that the cloud will save money (hence the utterings in the c-suite). Cloud vendors (and what hardware or software supplier isn’t a cloud provider today?) continually ensure that the cloud will save you money; so it must be true, right? But will it really? Like all things, the answer is – it depends (don’t you hate that!).

There are great reasons for using Infrastructure as a Service (IaaS) or Platform as a Service (PaaS). I think particularly in R&D situations where you have varying compute needs versus having dedicated hardware to meet your highest capacity compute requirements. Crunching big data is probably another area where the cloud could save money. In both scenarios I believe you need data retention policies that are enforced (probably true in or out of the cloud) to ensure your variable storage requirements and associated costs don’t just escalate. You have cost in set up and ensuring you continue to get what you pay for over time but you are relived of the day-to-day operational costs and pay for the benefits. I am sure you have other scenarios where you can save money using compute services in the cloud.

As indicated in an earlier blog, I love applications; I appreciate infrastructure (IaaS and PaaS) but it’s really just a vehicle to run applications (I am not biased or anything)! So I have a business operations application centric view when looking at the cloud. Software as a Service (SaaS) is the predominant cloud choice (or whatever aaS you want to call the on-demand flavor) for running your business. I am not convinced that the cloud is always a money saver in this situation.

The Upper Edge LLC blog has an interesting series about SaaS and On Demand contracts and whether there is really a lot of difference in your cost commitments, SaaS Matters: When “On Demand” Really Isn’t.  For you finance people in the crowd (or is that cloud) how do you feel about capital expense (CapEx) versus operational expense (OpEx)? I am such a conservative that predictable CapEx depreciation makes me feel good. Although from the Upper Edge point of view, maybe you get predictable OpEx using cloud SaaS options. Variable expense is something you should consider as you think about getting to the cloud and saving money.

Another cloud cost consideration from a business operations perspective is integration. Certainly in the early stages of your company, getting your business up and running is a great economical use of SaaS. And fit for function SaaS offerings which are best of breed in doing one thing really well are great choices too. But get too many independent SaaS offerings that need to work together and your cost savings may begin to erode or even disappear. There is not only the cost of integrating the applications but productivity must be considered also. If a single user has to go to multiple applications to complete their work and the configurations and integrations do not provide the necessary consistency, productivity could very well take a dive. The cost of supporting your business users in your unique cloud environment will also be affected by the consistency of integrations.

The cloud and saving money may often but not always be synonymous; it depends. So be cautious if cost savings are your only reason to “Get to the Cloud!”

© Ellen Terwilliger 2012

Why. Now What?

According to Steven Covey’s 7 Habits of Highly Effective People habit #2, you should start with the end in mind. While he’s talking about individuals, I think this is applies equally well to transformation programs. (Maybe all seven habits are applicable; I’ll have to check that out.) Anyway as they say in the army, you can’t hit a target you can’t see.

In an earlier blog Why Transform , we used an example to show that a picture is worth a thousand words to manifest your vision and allow people to internalize why to transform.

 

This is a great start, people can see what success looks like, staring with the end in mind like Steven Covey suggests. But this alone is not always enough to completely inform and empower people to do the right things and make the right decisions during your journey of change. I believe that the next step is to describe solutions that show what is required to get to your desired outcomes.

In the example, there are spaces that need to be filled in to allow us to get to that happy productive salesrep. Take a look at the four solution spaces described below and we’ll talk about each of them:

To realize the vision of One Cloud One Me, first you need to know “Who I am”. A lot of companies do a pretty good job of this; often there is a unique identifier and strong password that is proliferated around the many application systems allowing a single sign on (or in some cases sign on and on and on as my former colleague Leslie Thiel has been heard to say). So you might not need to do a lot of work on this space.

“What I do” can be a little trickier. Since you’re a very successful startup, it’s likely that these SaaS applications were purchased and implemented at different times as the need arose. It may also be the case that some applications were implemented by business groups and some by IT (Does that sound familiar to you IT people in the crowd?), heck maybe IT didn’t even exist at the company when some of these went live. In any case, what I do or my role may not be consistent between the applications. This is pretty straight forward to figure out in order to ensure that your various types of sales people (salesreps, territory managers, etc.) have the appropriate capabilities to do their job.

Now comes some more interesting stuff (remember interesting is the word that is used to mean that complexity and cost are staring to go up). “What I see” may be very different between the various clouds. For example, sales team may play a huge role in the opportunities I see in my sales force automation system (SFA: Salesforce.com in the example) but sales team doesn’t exist in my enterprise resource planning system (ERP: NetSuite in the example), so unless I am the actual salesrep assigned to the deal, I may not be able to see when an order gets booked for the deal I sweated over. And therefore I’m worried I’m not going to get compensated properly by the incentive compensation or commissions system (IC: Callidus in the example) since that’s in some other cloud formation in my mind. Now salesrep productivity begins to erode because time is being spent “checking things out” instead of selling. This is the real opportunity to be addressed.

So what do we do about it? Here’s where the last piece of describing the solution comes in; critical data leverage. By describing what data objects will be used to connect the spaces across all the clouds that are relevant to me, I don’t have to worry about consistency anymore. Everyone can see what will be used to guarantee that every application I use to do my job has the right stuff. People will be able to do the right things and make the right decisions to ensure the desired outcome: one me. The values of the data objects may change over time as territories are divided up differently or salesreps move around the world, but the data object will stay the same and be consistent (until the next transformation anyway).

In the example, let’s say territory, sales team, customer classification and product family are used to determine what I can see and how I am compensated. So we add those data objects to the solution spaces to complete the picture.

The last solution space “How I know”, just became a bit easier to handle. By describing the solution spaces and critical data to be leveraged, everyone has a clear picture of what will be used to connect the clouds consistently and provide the ability to validate or reconcile One Cloud One Me.

Starting with the end in mind and describing the solution creates the guardrails for your transformation program. Do you think people will be able to accurately create the processes and designs that will enable your desired outcomes? Will decision making be easier and more rapid? Will your transformation program be set up for success?

© Ellen Terwilliger 2012