Always Assume Your Assumptions Are Wrong


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.

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.