A potentially serious impediment to success in software projects is false assumptions. Both yours and everyone else's. If you act on false assumptions as though they're true, such as by assuming you understand exactly what your customers want, you may find yourself faced with flawed software and failed projects. In this column, Karten explores false, conflicting, and hidden assumptions, and how you can "surface" them.
Not that software projects have a monopoly on false assumptions. Here's a sad saga that suggests that false assumptions occur everywhere, and can even be deadly:
"The confusion began at 6:18 P.M. Monday, when the woman's landlord called 911, saying he had found her body in her basement apartment. Two technicians-E.M.S. employees with less training than paramedics-arrived within minutes and pronounced her dead at about 7 P.M. They notified the Medical Examiner's office, which sent an investigator, a doctor, who assumed the woman was dead because the technicians had said so. The investigator had been in the apartment for more than half an hour when he heard what sounded like a single faint breath . . ."
Needless to say, she was alive.
Now, maybe the doctor should have known better than to assume the technicians' information was correct, but most false assumptions don't seem like false assumptions. They seem perfectly logical and reasonable at the time-so logical and reasonable, in fact, that you don't even realize you're making an assumption. Which is why it's so easy for assumptions to create havoc with your good intentions.
How to Steer Clear of False Assumptions
Fortunately, most software flaws and flubs aren't life-threatening, though sometimes they are (and sometimes the pressure to deliver on-time and within budget feels life-threatening). So what's a person to do? Here are four suggestions:
Keep in mind the one assumption you should always make; namely, that you and others don't understand each other. Assume that others interpret what you say differently from the way you do, and that they mean something different from what you think they mean. Until you've gone through a rigorous process of information gathering and assumption challenging, it's wise to assume that even if the words sound familiar, you're speaking two different languages.
Don't minimize the importance of assumption-checking, as one organization's systems development methodology did. Their methodology included a one-page form in the middle of which was a skinny section with the instructions: "List your assumptions here."
Talk about false assumptions! The makers of this methodology falsely assumed that the space provided could accommodate the number and range of assumptions underlying any given project. And nowhere in the methodology was there a process for gathering assumptions from other pertinent parties, ensuring the validity of the assumptions captured, and identifying those that were missing.
Become more aware of the fact that you and others (customers, teammates, management, whoever) are making assumptions. One way to develop this awareness is to ask yourself what these assumptions might be. For example:
What assumptions are we making about . . . this project . . . the intended outcome . . . the schedule . . . their roles . . . their constraints . . . their expectations of us . . . their criteria for success . . . their priorities?
What assumptions might they be making about . . . this project . . . the intended outcome . . . the schedule . . . our roles . . . our constraints . . . our expectations of them . . . our criteria for success . . . our priorities?
The very fact of asking these questions may help you focus on aspects of the project that, on reflection, you're not as certain about as you thought you were.
Still, you can't possibly know what assumptions others are making (even if you assume you can!). Therefore, the more critical the project, the more important it is to try to identify each party's assumptions, and the