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:
Suggestion #1
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.
Suggestion #2
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.
Suggestion #3
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?
And:
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 sooner, the better. Each false or conflicting assumption that you find is an opportunity to prevent problems.Suggestion #4
Consider trying the following technique to help surface false or conflicting assumptions. This technique is not intended to replace your current processes for requirements identification, scenario planning, or risk assessment; it's simply a quick and easy way to locate concealed molehills before they morph into mountains.
Consider All Factors
This technique begins by doing a CAF. This stands for Consider All Factors, an exercise described in Edward de Bono's book de Bono's Thinking Course. The CAF is an attention-stretching activity that helps ensure that you don't overlook essential aspects of a problem you're trying to solve or a solution you're trying to create.
In my adaptation of this technique, developers and customers get together and brainstorm as many factors as possible that anyone in the group thinks could affect the outcome of the project. Most groups rapidly identify at least fifteen or twenty factors. In groups I've worked with, the lists have included such factors as priorities, schedule, budget, business impact, resources, constraints, staffing, turnover, tools, standards, timing, politics, government regulations, reorgs, external parties, interfaces, company policy, existing procedures, service levels, training needs, advance notifications, problem history, implementation, workload distribution, and division of responsibilities.
Oh, yes, and one final factor—troublemakers—which one group concluded was critical, because if they could identify people who might withhold their cooperation or drive them crazy during the project, they could formulate ways to minimize that impact—legally, I assume. This certainly seems like a better approach than to assume that all others will support the project and do their utmost to help it succeed. In my experience, doing a CAF, is an eye-opener for participants; it almost always brings to light aspects of the project that might otherwise have been overlooked.
Assumption-Check the Collected Factors
Once the group has captured a list of factors, they assumption-check the factors by discussing, for each factor, what stands out for them. Questions that can serve as a guide include: What makes this factor important? What concerns, puzzles, or worries you about it? What aspect of this factor caused problems in past projects? If something could go wrong regarding this factor, what might it be? What one change with respect to this factor will improve the odds of success? This discussion usually unearths a few false assumptions. When it does, you can breathe a sigh of relief for all the problems you just prevented.
I Assume You'll Read This Final Section
Assumptions being the elusive critters that they are, you won't unearth every one of them, but each one that comes to light and receives attention is a step in the right direction. In the process, you and your customers will develop a much better shared vision of the entire project. I don't dare assume you'll find these suggestions helpful, but I sure do hope you will.
