What Could Possibly Go Wrong?

						
© 2002 Esther Derby, www.estherderby.com

						
A software project is a complex thing. It involves many players, many tasks, and lots of things that could go wrong (and often do). If not for dogged optimism, some projects might not be tackled at all. But optimism doesn’t mean turning a blind eye to potential pitfalls. In this column, Esther Derby applies a lesson about asking, "What if..."

						
What could possibly go wrong in your software project? Thinking about what could go wrong identifies potential problems and gives you information to build a more error-resistant plan.

							
A while back, I decided to wallpaper a small room in 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 do one room.
						
On Saturday morning, I stopped at the home remodeling store and bought everything I needed 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 wallpaper 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 five or more rolls of wallpaper) developed a crack and leaked pasty water all 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.
						

						
The list was actually longer. Did I mention that my cabin is two and half hours down a two-lane road from the nearest home remodeling 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. 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 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 quality.

							
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.

							
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 four of the project?”
							
  • “What if a competitor releases a new feature and Marketing wants to change our 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 an elegant solution, it’s a drag to hear about what could go wrong. Sometimes I just want the other person to be as excited as I am about my neat design. 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).

                

        
 Email this article to a friend.

        

        
Comments to: