What could possibly go wrong?

What could possibly go wrong?

Thinking about what could go wrong identifies potential problems and gives you information to build a more error-resistant plan.

© Esther Derby 2001-2002

This article originally appeared on StickyMinds.com in April 2001

A while back, I decided to wallpaper a small room at my cabin. Even though I had done a lot of home projects, I'd never wallpapered before. But my mother-in-law, Shirley, is a wallpaper queen. She can do three rooms in a day. After talking with Shirley, I made a list of materials and tools I'd need and calculated the number of rolls of wallpaper required to cover the room. I estimated that if Shirley could do three rooms in a day, as a beginner, I'd better allow a whole day to paper the room.

On Saturday morning, I stopped at the home-remodeling 313s1814d store and bought everything I needed to wallpaper a room and headed up the road to the cabin. I was set. I knew the approach, I had a plan and all the materials. I was confident I could finish the job in a day. What could possibly go wrong?

By Sunday afternoon, I had a rather long list of things that could go wrong:

• Not all the rolls of wall paper were from the same print lot. The color and texture of half the rolls were noticeably different from the other half.
• The water trough for wetting the paste (free with 5 or more rolls of wallpaper) developed a crack and leaked pasty water over the kitchen floor.
• Even though I switched paper lots in a corner, if I looked closely, I could see that the colors didn't match.
• I didn't have quite the right tool to smooth air bubbles out from under the paper, and in spite of all my efforts, some stubborn air bubbles remained.
• Too much fussing with the air bubbles squished out the pre-applied paste, and the paper came unstuck from the wall.

I could go on. Did I mention that my cabin is a two and half hours down a two-lane road from the nearest home re-modeling store?

When we design solutions and plan software projects, we tend to plan for things to go right. It's a human tendency to be optimistic and concentrate on how to get things done rather than dwell on what could go wrong (or turn out to be harder than originally thought). And I believe our software culture encourages this tendency -- how many times have you heard someone say "Failure is not an option," "Don't be negative," or "Don't tell me about problems, tell me about solutions!"

We go through stages of understanding the problem -- we gather requirements, develop analysis models and then design software solutions. We develop plans to build and deploy the solution. We think about the steps we need to take to achieve the solution. And we come up with a well-ordered set of actions that will lead us logically and inevitably to the goal.

And then we skip an important step. We don't sit down and think about what could go wrong. We learn about weakness in our plan and design approach as we go. Discovering oversights by running into walls costs money, causes delays, and can compromise the quality of the product.

I (now) use a rule of thumb when I approach a new project or design problem: I try to think of ten things that could go wrong before I start. If I can't think of ten things that could go wrong, I haven't thought enough, and I try to understand the problem better.

First, I look for "lack of:" areas where the team doesn't have experience, knowledge or information. Then I look for areas where we're dependent on someone else to provide something -- areas where the project team doesn't have control of a needed component. I look for areas where not all the key players are in agreement. And I look for areas where there's not enough time to finish a component -- or finish with desired quality. These questions help me identify natural areas of risk. I pull out a list of common software project risks to jog my thinking.

Then I start asking "What if ." questions:

"What if we can't fill those three positions by week 4 of the project?"

"What if a competitor releases a new feature and marketing wants to change the feature set?"

"What if we lose a key project team member?"

"What if our design won't carry the volume we think it will?"

"What if the vendor code is buggy?"

"What if" questions help me figure out the impact of potential problems and develop contingency plans that will help us meet project goals when something does go wrong.

I look around the organization: How have similar projects fared? What wisdom do other project managers, developers, and testers have to share about past efforts? What's the history of projects in the organization?

Finally, I ask someone else who has a fresh point of view or someone who has done something similar to poke holes in the plan. This isn't always fun. When I'm in the throes of enthusiasm over a new project, or think I've found a really elegant solution, it's a drag to hear about what could go wrong. Sometimes I just want the other person to be as excited about my neat design or "solid" plan as I am. In the long run, though, it helps me come up with an even better solution, and develop a more resilient plan to help stay on track when something does go wrong (and it will).

I don't have the illusion I'll think of all potential problems ahead of time, but the ones I do find help me make a much better plan.