The Horror of Surprise

The defenseless couple walk along the dark hallway, dim lights flickering among the cobwebs. Eerie music crescendos as they near the door at the end, unsuspecting of any possible harm as they slowly reach for and turn the knob.

Boo!

Sorry, that's as scary as we're going to get this Halloween season. Unless you're a project manager. And you're blindsided by the unexpected. Like some hideous monster jumping out from behind the shadows, there are always creepy-crawly things waiting to scare you:

• Indecisive executives
• Changing business landscapes
• New or forgotten requirements
• Office politics gone awry
• Sudden staff changes

I saw a t-shirt this summer that said "Life is all about how you handle Plan B," and that's especially true if you're a project manager. But with all of our risk and issue planning, few project managers TRULY give thought to Plan B and how it plays out.

What are the elements to creating a solid Plan B?

• Trigger Event - what has to happen among all your risks in order for you to jump away from Plan A? Define events, thresholds, or variances that must be present for you to go to your Plan B.
• Outcomes - what do you want Plan B to accomplish? Don't assume it's the same thing as Plan A. You may need to scale back features and functions of your scope to get done on time. You may need to sacrifice time or budget.
• Roles - what skill sets will help you achieve the Plan B outcomes, and which available staff have those skills? Avoid the temptation to simply reassign your Plan A team (after all, they may have been the ones who got you into the mess).
• Tasks, Dependencies, and Estimates - create your Plan B project plan to show how you will use the ROLES to achieve the desired OUTCOMES once the TRIGGER EVENT has occurred.
• Stakeholders and Accountability - who cares and how are we going to keep them apprised of our progress? How will we define "done" to ensure people are accomplishing Plan B?

So the next time you go sneaking around dark passageways on stormy evenings, make sure you have your escape route marked. Go Plan B!

A Trunk Monkey For Christmas

I'll bet after watching this ad, there will be a lot of last-minute requests for trunk monkeys.  It seems to be a cure-all for society's ills.  We tend to do that a lot in business:  look for the silver bullet.

Sigh... if only...

Each risk in life (or projects or business) has a pre-disposed response.  Depending on how much probability and impact there is for each risk, there are different responses you can take:

• Accept the risk - that's right, boys and girls, do nothing.  You'll take this approach when the risk isn't that big of an impact to your project, so you really don't care if the risk occurs.  You'll also use this if the other two approaches are too expensive or time-consuming to implement.  Just suck it up, and deal with it, bucko.

• Avoid the risk - if the risk's impact to the project is so bad you can't bear to think of it, then this may be your best course of action.  This approach generally involves the more drastic measures, like replacing a risky vendor or firing a non-performing team member.  Whatever it costs, you will not let this risk event occur.

• Mitigate the risk - develop an appropriate "plan b" response to the risk, to be implemented if the risk does indeed occur.  This may involve insurance or warranties, multi-sourcing with vendors, or cross-training your project staff to pick up the slack.  You're just keeping it tucked in your back pocket until you need it.

Either way, projects and life require their own kind of trunk monkey.  The trick for you is sorting out which is needed and when.  That's just one way to keep on track to seize the accomplishment.

"Key" Issues To Project Scope

(Originally Published On Iowabiz.com In May, 2007)

I have a box of keys at home.  Big keys.  Small keys.  House keys.  Office keys.  Cabinet keys.  Padlock keys.  Keys.  Keys.  Keys!!!!

The only problem is that I have no clue what any of these keys actually unlocks.  Maybe an educated guess at best.  The problem is that I'm unwilling to unload any of these keys because one never knows when a new lock may just appear out of nowhere and need a key.  And - EUREKA - I'm prepared.  Meanwhile, the "key box" takes up real estate in a drawer in our house, and I generally run into it when I'm looking for something else.

Are these keys like some of the projects in your organization?  Are they simply solutions waiting for a problem?  In companies of all sizes, it can become very easy to be enamored by the latest hot software solution du jour.  Some people fall under the spell of evil consultants who make lofty promises.  Worse yet, sometimes we let executives go to the restroom with trade magazines.  They go in seeking a nature call and come out with the latest ad-induced idea, shouting, "Hallelujah!  I gotta get me some of that!"  It doesn't matter what "that" is; they've found a solution and it becomes your issue to retrofit it to a problem.

Think about the projects that your organization is currently tackling.  Can you really name the problem or opportunity that each is intended to solve?  John Dewey once stated that "a problem well defined is a problem half solved."  Yet how many of your projects are simply keys without locks?  Here is a quick and easy test:  How many of your so-called problem statements start with the words "we need" or "we have a lack of"?  If so, you've probably defined a solution rather than a problem.  Case in point, if your problem statement is "We need a new computer system," what is the solution?  (No peeking.)  Yup, you guessed it.  I have a two-year-old here at home who is excellent with asking "why" questions.  I'm thinking of asking her to subcontract to me, so I can assign her to the clients who cannot define a good problem statement.  If you ask "why" enough times, you'll get to the root cause of the issue.

Why should you as a small business owner or employee care about this?  Good question.  As somebody who probably has limited resources, you don't have the time or money for people to be running down rabbit holes after half-baked ideas.  (If you do have people with ample time on their hands, send them over to my house and I'll let them find the locks to all my extra keys.)  The trick to avoiding the key-without-a-lock project is to write a brief yet solid business case before approving the idea to become a project.

This is more than just an academic exercise.  In my book, Race Through The Forest - A Project Management Fable (Tiberius, 2006), I recommend a simple approach to documenting a business case.  Because the business case is the "senior artery" that carries information and decision-making ability to the entire project life cycle, it's also a great way to remember the content of your business case:

• Stakeholders - list those people who might or should care about this project
• Rationale - document a compelling reason (problem or opportunity) for undertaking this project
• Alternatives - list feasible options for addressing the problem or opportunity
• Recommendation - choose which of the alternatives is the best solution
• Timeline - lay out the high level milestones for completing this project (with specific dates)
• Estimates - set expectations about the amount of effort it will take to complete the project
• Risks - consider the main things that could go wrong (either by undertaking the project or staying with the status quo)
• Yes/No Decision - even if it's just a contract with yourself, document the approval to proceed.

Don't trick yourself into thinking you have to write a 150-page dissertation for your business case.  After all, you are a small business owner who is strapped for time.  You'll know when you have enough documented to justify it in your own mind.  Some of the best business cases I've seen were under five pages.  Taking this simple step should help you get rid of those keys without locks, and help ensure that you are spending your time and resources on the truly critical problems or opportunities within your organization.

Carpe Factum!!!

What If You Get Hit By a Bus?

What if you get hit by a bus?

This is the standard question asked in project management circles to get people to think about risk.  It's sort of the PM equivalent of "it's all fun and games until somebody's eye gets put out."  The idea is to get people to think about the borderline absurdities that can derail a project.  Those things that live in the outer reaches of reality... those unpleasantries that we don't like to think about but still COULD happen.

Here in Des Moines, we need to think of a new project risk management example.  It seems that our bus drivers have been getting too aggressive... clumsy... careless... dangerous.  Last week saw the third bus-pedestrian accident in the past nine months.  Now, for those of you in larger cities, I'm sure you're chuckling right now that we've only had three in nine months... but for us here in the middle of the Midwest, that's a little too frequent for our collective comfort level.

But let's take this back to our projects.  Are we accurately assessing the probability of each project risk event occurring?  Is the probability of the resignation of our key subject matter expert at 10% ... or is it really closer to 70%?  Is the probability of a vendor default really at 90%?  Or is that the assessment of the purchasing manager whose ego was bruised by this same vendor and is more like 10%?

The best risk management assessments in my career were discussed in a group.  We gave our initial gut reaction, and if there were discrepancies, we talked through them until we reached consensus.  Then you can create an appropriate response for each risk.  To do anything less is like crossing the street in downtown Des Moines.

What's Your Happy Fun Ball?

Remember this little sketch from SNL?

Where does one strike a balance of communicating potential risks to alert stakeholders and going overboard to the point of being labeled Chicken Little?  Project risk management is challenging.  We try to educate people about what can go wrong, and sometimes the messenger gets shot.

I've found the following criteria (and some relevant links) for analyzing and communicating risks and issues:

• Does/should management care about it?
• Does management need to take action on it?
• Can/will it cause irreparable harm to the company or its customers if not mitigated or avoided?
• Will I get fired if management gets blindsided by this later?
• Is there a high probability of the risk event occurring?
• Is the risk just too great to pursue?
• Do I need to cover my backside by documenting it (reality check)?

So, what is your happy fun ball?  How are you communicating it?

A Walk On The Wild Side

Steve Irwin is dead.  The famed "Croc Hunter" is no longer.  I'm going to miss seeing him as I'm flipping through cable channels.  He was always fun to watch, as I shook my head in disbelief that he had lived this long.  I would guess that 44 is well beyond the life span of a guy who has snakes for pets and wrestles crocs.  But, as his online obituary read, he died as he lived... doing what he loved.

I've been thinking a lot about some people in my field.  How they always play it safe.  How their risk management plans not only cover their butts but entomb them so that there's no longer ANY skin in the game.  It's OK to think about what can go wrong... as project managers, we kind of encourage that.  I'm talking about the people who suffer "paralysis by analysis" and do nothing because they're afraid that something might happen.

A lot of my consulting work is done at major corporations.  There's a double standard that exists within those walls.  Executives say they want their people to be more risk taking, more entrepreneurial.  The people working for those same executives are scared out of their wits to fail because they "saw what happened to the last guy."  If that's the mindset we're all going to take, then I guess nobody is going to swim with stingrays any longer.

Maybe I'm just getting tired of corporate cowardice.  Maybe I'd like to see somebody rip their boss a new one just because he deserves it.  Maybe I'd like to hear about a project manager demanding a raise because she's kicked butt on the last five projects and she could go anywhere in town and get double what she's getting paid now.  Maybe I'd like to hear a design team tell the executives that their idea is dumb from so many angles that it would take more paper to document the stupidity than it would the design.

Maybe I'd like to see Steve Irwin fight one more croc.

Maybe I'd like to fight a few corporate crocs myself.

Maybe.

Crikey.

Couldn't See That One Coming

Every year, Iowa hosts one of the nation's premier bicycle enthusiast events, the Register's Annual Bicycle Ride Across Iowa (RAGBRAI).  This year, we even have Lance Armstrong joining the ride for a couple of days (with the whole Tour de France thing under his belt, he must have felt compelled to try a real bike ride for once).  Over the course of one week each July, riders make their way across the state of Iowa, staying in a different town each night (generally camping out in tents).  While I enjoy cycling, I've yet to participate in this Iowa phenomenon, although I've heard from others that it is quite the experience.

Host towns go to great lengths to ensure that riders are treated well and that they have good memories when they leave.  Being selected as a host town is a big deal in Iowa, and it is our state's equivalent to being selected as a site for the next Olympics.  Many hours of planning go into preparing the venue for the overnight stay.

Last night, the riders were staying in the neighboring suburb of Waukee.  A big thunderstorm blew through last night.  While July thunderstorms are nothing new to RAGBRAI riders, this one (according to news reports this morning) evidently short circuited the sound system in Centennial Park, causing the school fight song to blare out over the campgrounds where many of the cyclists were staying... all night long.  Yup, that'll be a memorable stay.

You can rest assured that the Waukee planners were probably prepared for most risk events, but this one probably didn't even hit their radar screen.  But I bet it gets filed under "lessons learned" for the next time Waukee is selected to host.

As project managers, we have to plan for risks.  But there are some risks we could never begin to fathom in a million years... things that blindside us so badly that we're left standing there dazed and confused.  That's where documenting our assumptions (REMEMBER:  "Undocumented assumptions resurrect as excuses")and building in logical contingency help us keep our credibility.  It is so much easier to go to stakeholders and say "Our assumptions were violated" than it is to say "We didn't see that one coming."

And if that doesn't work, repetitively playing your project's fight song might help.

Technorati Tags: RAGBRAI, Iowa, Waukee, Lance Armstrong, Project Management, Risk Management, Assumptions