Whether you are in the workshop setting of Chapter 10 or whenever you find yourself needing new ideas or creative solutions to problems, brainstorming is a very useful technique. It's simple, easy to do, and fun.
In the workshop setting, you probably already have a pretty good idea of the features of the new product. After all, few projects start out with a totally clean slate. However, in addition to reviewing the suggested features for the product, the workshop provides the opportunity to solicit new input and to mutate and combine these new features with those already under consideration. This process will also help us in our goal of "finding the undiscovered ruins" and thereby making sure that we have completeness of our input and that all stakeholder needs are addressed. Typically, a portion of the workshop is devoted to brainstorming new ideas and features for the application. Brainstorming is a collection of techniques that are useful when stakeholders are collocated.
This elicitation technique has a number of primary benefits.
It encourages participation by all parties present.
It allows participants to "piggyback" on one another's ideas.
A facilitator or scribe maintains a written trail of everything discussed (so nothing is lost).
It exhibits high bandwidth.
Typically, it results in a broad set of possible solutions to whatever problem is posed.
It encourages out-of-the-box thinking, that is, without being limited by normal constraints.
Brainstorming has two phases: idea generation and idea reduction. The primary goal during idea generation is to delineate as many ideas as possible; the goal is breadth of ideas, not necessarily depth. The primary goal during idea reduction is to analyze all of the ideas generated. Idea reduction includes pruning, organizing, ranking, expanding, grouping, refining, and the like.
Although brainstorming can be approached in many different ways, the simple process we describe has proved effective in a variety of settings. First, all of the significant stakeholders are gathered into one room, and supplies are distributed. The supplies given to each participant can be as simple as a stack of large sticky notes and a thick black marker for writing on the notes. The sheets should be at least 3" × 5" (7 cm × 12 cm) and no larger than 5" × 7" (12 cm × 17 cm). Each participant should have at least 25 sheets for each brainstorming session. Post-Its or index cards work well. If index cards are used, push pins and a soft wall, such as a large cork board, are also needed.
Then the rules of brainstorming are explained (see Figure 11-1), and the objective of the session is clearly and concisely stated.
The facilitator also explains the objective of the process. Although it may seem as though the objective that starts the process is rather straightforward, it is not. The way it is stated has an effect on the consequences of the session. For example, the following questions are a few ways to state the objective.
What features would you like to see in the product?
What services would you like to see the product provide?
What things would you like the product to keep track of?
(Note that the objective also helps you to decide when the session is done. When the objectives are met and no one else has anything to add, quit!)
After the objective of the process has been stated, the facilitator asks participants to state their ideas aloud and to write them down, one per sheet. Ideas are spoken out loud to enable others in the room to piggyback on the ideas, that is, to think of related ideas and to follow rule 4, to mutate and combine ideas. In this process, however, the first rule—no criticism or debate—must be foremost in people's minds. If this rule is not enforced, the process will be squelched, and many bright folks who are sensitive to criticism will not feel comfortable putting forth more ideas, a tragic loss.
Tip
In our experience, the most creative and innovative ideas—those that truly revolutionized the product concept—were not the result of any one person's ideas but instead resulted from combining multiple, and seemingly unrelated, ideas from various stakeholders. Any process that fosters this result is a powerful process indeed.
As they are generated, ideas are written down by the idea generator on the supplied materials. This is important.
To make sure that they are captured in that person's own words
To make sure that they are not lost
To enable them to be posted for later piggybacking
To prevent delays in the creative process that could be caused by a single scribe trying to capture all ideas on a flip chart or whiteboard in front of the room
As ideas are generated, the facilitator simply collects them and posts them on a wall in the meeting room. Again, no criticism of ideas can be tolerated. It is inappropriate to say, "That's a stupid idea" or even "We already have that idea on the wall." The sole purpose is to generate ideas. Even a mildly negative remark can have the deleterious effect of suppressing further participation by the "victim." However, remarks such as "Great idea!" are appropriate and will often provide the award of a "That's a Great Idea Ticket," which can encourage further participation by all stakeholders. Idea generation should proceed until all parties feel that it has reached a natural end.
It is common for lulls to occur during idea generation. These are not times to stop the process. Lulls tend to correct themselves as soon as the next idea is generated. Longer lulls might be cause for the facilitator to re-ask the objective again or to ask similar questions. Most idea-generation sessions last around an hour, but some last 2–3 hours. Under no condition should the facilitator end a session that is going strong with a remark like "I know we're all doing great with this process, but we need to move on." To the participants, this remark says, "Your ideas are not as important as my schedule." The number of ideas generated will be a function of how fertile the subject being discussed is, but it is common to generate 100–200 ideas.
The process tends to have a natural end; at some point, the stakeholders will simply run out of ideas. This is typified by longer and longer gaps between idea submissions. At this point, the facilitator brings an end to the session, and it may well be a great time for a break.
When the idea-generation phase terminates, it is time to initiate idea reduction. Several steps are involved.
The first step is to "prune" those ideas that are not worthy of further investment by the group. The facilitator starts by visiting each idea briefly and asking for concurrence from the group that the idea is basically valid. There is no reason for any participant to be defensive or to claim authorship for any idea; any participant may support or refute any idea.
Tip
The presence of ideas that can be easily pruned is an indicator of a quality process. The absence of a fair number of wild and crazy ideas indicates that the participants were not thinking far enough "out of the box."
The facilitator simply asks the participants whether each idea is worthy of further consideration and then simply removes an invalid idea, but if there is any disagreement among the participants, the idea stays on the list. If participants find two sheets with the same idea, group them together on the wall. (This is usually preferable to removing one; its author may feel insulted.)
It may be helpful during this process to start grouping similar ideas. Doing so is most effective when participants from the session volunteer to go to the wall and do the grouping. Related ideas are grouped together in regions of the walls. Name the groups of related ideas. For example, the groups might be labeled
New features
Performance issues
Enhancements to current features
User interface and ease-of-use issues
Or, they may be specifically focused on capabilities of the system and the way they support various types of users. For example, in envisioning a new freight and delivery service, the features might be grouped by
Package routing and tracking
Customer service
Marketing and sales
Web-based services
Billing
Transportation management
Idea generation can be reinitiated now for any one of these groups if the participants feel that the grouping process has spurred development of new ideas or that some area of key functionality has been left out.
At this point, it is important to take the time to write a short description of what the idea meant to the person who submitted it. This gives the contributor the opportunity to further describe the feature and helps ensure that the participants have a common understanding of the feature. This way, everyone understands what was meant by the idea, thus avoiding a fundamentally flawed prioritization process.
In this process, the facilitator walks through each idea that has not been pruned and asks the submitter to provide a one-sentence description.
| Application Context | Brainstormed Feature | Feature Definition |
|---|---|---|
| Home lighting automation | "Automatic lighting settings" | Homeowner can create preset time-based schedules for certain lighting events to happen, based on time of day. |
| Sales order entry system | "fast" | Fast enough response time to not interfere with typical operations. |
| Defect tracking system | "Automatic notification" | All registered parties will be notified via e-mail when something has changed. |
A welding robot feature, such as "automatic reweld," may already be sufficiently described, and no further work is required. However, it is important to not bog down in this process; it should take no longer than a few minutes per idea. You need capture only the essence of the idea.
In some situations, the generation of ideas is the only goal, and the process is complete. However, in most settings, including the requirements workshop, it will be necessary to prioritize the ideas that remain after pruning. After all, no development team can do "everything that anybody can ever think of." Once the groupings have stabilized and have been agreed to, it is time to move on to the next step. Again, a variety of techniques can be used; we'll describe two that we use routinely.
Cumulative Voting: The Hundred-Dollar Test. . This simple test is fun, fair, and easy to do. Each person is given $100 of "idea money" to be spent on "purchasing ideas." (You may even wish to add a kit of "idea bucks" to the workshop ticket inventory.) Each participant is asked to write down on a sheet of paper how much of this money to spend on each idea. Then, after the participants have had a chance to vote, the facilitator tabulates the results and provides an order ranking. It may also be helpful to do a quick histogram of the result so participants can see the visual impact of their decision.
This process is straightforward and usually works just great. However, you should be aware of the following caveats. First, it will work only once. You cannot use the same technique twice on the project, because once the results are known, participants will bias their input the next time around. For example, if you're a participant and your favorite feature is first on the list but your second-favorite feature didn't even get honorable mention, you may put all of your money on the second feature. You're confident that other voters will see to it that your favorite feature still makes the cut.
Similarly, you may find it necessary to limit the amount anyone spends on one feature. Otherwise, a tricky participant, knowing full well that "other items" such as "Run faster" and "Easy to use" will make the cut to the top of the list, might put all of their money on "Runs on the Mac platform" and elevate it to a higher priority. On the other hand, you may wish to allow a higher limit, so long as you have the opportunity to understand where the really big votes came from. They may represent high-priority needs from a limited stakeholder community.
The "Critical, Important, Useful" Categorization . A colleague taught us another technique that has also been very effective, especially with a small group of stakeholders or even just one stakeholder, such as when you need your boss's opinion of your priorities. In this technique, each participant is given a number of votes equal to the number of ideas, but each vote must be categorized "critical," "important," or "useful." The trick in this technique is the rule that each stakeholder is given only one third of the votes from each category; therefore, only one third of the ideas can be considered critical.
Critical means "indispensable," suggesting that a stakeholder would not be able to use a system without this feature. Without the feature, the system does not fulfill its primary mission, its role and is therefore not worth releasing.
Important means that there will be a significant loss of customer utility or market share or revenue or new customer segments served. If the important items don't get implemented, some users would not like the product and would not buy it.
Useful means nice to have. The feature makes life easier, makes the system more appealing, more fun, or delivers higher utility.
Note
With this scheme, all ideas that survived the pruning process get at least a "useful" vote, avoiding insult to those who submitted them.
In a larger group of participants, each item will have a mix of categories, but this is not really a problem. The facilitator has one more trick: Simply multiply "critical" votes times 9, "important" by 3, and "useful" by 1 and add up the score! This will tend to spread the results to heavily favor the "critical" votes, and thus every stakeholder's "critical" need will bubble to the top of the list.
So far, we have discussed a process for brainstorming that works very effectively when all stakeholders can be gathered together at the same time, are relatively proactive and not overly shy, the facilitator is experienced, and stakeholder politics is manageable. Indeed, there is no substitute for the developers and outside stakeholders spending this time together. Each will remember the various hot buttons and issues addressed by the others, and perspective and mutual respect are often byproducts of the process. Therefore, the requirements workshop and live brainstorming are by far our preferred approaches.
But sometimes, live brainstorming is not possible. In these situations, an alternative is to use the Internet or an intranet to facilitate the brainstorming process via the establishment of a discussion group. This technique may be particularly suited for developing advanced applications for which research is required or a long-term view is critical, the concept is initially fuzzy, and a wide variety and significant number of user and other stakeholders inputs are involved.
With this technique, the project leader sponsors a list server or Web page for recording and commenting on product features. The recording of ideas and comments can be done either anonymously or by crediting the author, based on the construct created by the administrator. An advantage of this technique is its persistence; ideas and comments can be circulated over a long period of time, with full recording of all threads for each idea. Perhaps most important, a unique advantage of this process is that ideas can grow and mature with the passage of time.
Let's get back to our case study. While the interviewing process was under way, the development team met with marketing and decided to hold a requirements workshop for the HOLIS 2000 project.
After thinking through the issues, the team decided not to bring in an outside facilitator but instead to have Eric, director of marketing, facilitate the workshop. The team also decided to have two development team members participate in the workshop: Cathy, the product manager, and Pete, the development manager. The team felt that both Cathy and Pete would speak for the team, as well as be able to contribute content, as they were both new homeowners. Other team members would not participate but would simply attend the workshop in order to observe the process, listen to the customers, and see the results immediately.
The team also decided to include representation from the four "classes" of customers and invited the following participants:
Distributors: John, CEO of the company's largest distributor, and Raquel, the general manager of the company's exclusive distributor in Europe
David, a local custom homebuilder with experience in purchasing and installing competitive systems in the marketplace
Betty, a local electrical contractor
Prospective homeowners, identified with the help of Betty, who were in the process of building, or were considering building a high-end residence.
The following list provides more detail on the participants.
| Name | Role | Title | Comments |
|---|---|---|---|
| Eric | Facilitator | Director of Marketing | |
| Cathy | Participant | HOLIS 2000 Product Manager | Project champion |
| Pete | Participant | Software Development Manager | Development responsibility for HOLIS 2000 |
| Jennifer | Participant | Prospective homeowner | |
| Elmer | Participant | Prospective homeowner | |
| Gene | Participant | Prospective homeowner | |
| John | Participant | CEO, Automation Equip | Lumenations' largest distributor |
| Raquel | Participant | GM, EuroControls | Lumenations' European distributor |
| Betty | Participant | President, Krystel Electric | Local electrical contractor |
| David | Participant | President, Rosewind Construction | Custom homebuilder |
| Various members | Observer | Development team | All team members who were available |
Prior to the workshop, the team put together a warm-up package consisting of
A few recent magazines articles highlighting the trends in home automation
Copies of selective interviews that had been conducted
A summarized list of the needs that had been identified to date
Eric brushed up on his facilitation skills, and Cathy handled the logistics for the workshop.
The session was held at a hotel near the airport and began promptly at 8 A.M. Eric introduced the agenda for the day and the rules for the workshop, including the workshop tickets. Figure 11-2 provides a perspective on the workshop.
In general, the workshop went very well, and all participants were able to have their input heard. Eric did a fine job of facilitating, but one awkward period occurred when Eric got into an argument with Cathy about priorities for a couple of features. (The team decided that for any future workshop, an outside facilitator would be brought in.) Eric led a brainstorming session on potential features for HOLIS, and the team used cumulative voting to decide on relative priorities. The results are shown in Table 11-1.
The results of the process turned out as expected, except for two significant items.
"Built-in security" appeared very high on the priority list. This feature had been mentioned in previous interviews but had not made it to the top of anyone's priority list. After a quick offline review, Cathy noted that built-in security, such as the ability to flash lights, an optional horn, and optional emergency call-out system, was apparently not offered by any competitive system. The distributors commented that although they were surprised by this input, they felt that it would be a competitive differentiation and agreed that this should be a high-priority feature. Krys and David agreed. Based on this conclusion, marketing decided to include this functionality and to position it as a unique, competitive differentiator in the marketplace. This became one of the defining features for HOLIS.
In addition, feature 25, "Internationalized user interface" did not get a lot of votes. (This seemed to make sense to the team, because the U.S.-based homeowners could not have cared less about how well the product sold in Europe!) The distributor, however, stated flatly that if the product was not internationalized at version 1.0, it would not be introduced in Europe. The team noted this position and agreed to explore the level of effort necessary to achieve internationalization in the 1.0 release.[1]
Table 11-1. Features from HOLIS workshop, sorted by priority
| ID | Features | Votes |
|---|---|---|
| 23 | Custom lighting scenes | 121 |
| 16 | Automatic timing settings for lights, etc. | 107 |
| 4 | Built-in security features, e.g., lights, alarms, and bells | 105 |
| 6 | 100% reliability | 90 |
| 8 | Easy to program, non-PC control unit | 88 |
| 1 | Easy to program control stations | 77 |
| 5 | Vacation settings | 77 |
| 13 | Any light can be dimmed | 74 |
| 9 | Uses my own PC for programming | 73 |
| 14 | Entertain feature | 66 |
| 20 | Close garage doors | 66 |
| 19 | Automatically turn on closet lights when door opened | 55 |
| 3 | Interface to home security system | 52 |
| 2 | Easy to install | 50 |
| 18 | Turn on lights automatically when someone approaches a door | 50 |
| 7 | Instant lighting on/off | 44 |
| 11 | Can drive drapes, shades, pumps, and motors | 44 |
| 15 | Control lighting, etc., via phone | 44 |
| 10 | Interfaces to home automation system | 43 |
| 22 | Gradual mode: slowly increase/decrease illumination | 34 |
| 26 | Master control stations | 31 |
| 12 | Easily expanded when remodeling | 25 |
| 25 | Internationalized user interface | 24 |
| 21 | Interface to audio/video system | 23 |
| 24 | Restore after power fail | 23 |
| 17 | Controls HVAC | 22 |
| 28 | Voice activation | 7 |
| 27 | Web site–user presentation | 4 |
[1] This issue demonstrates one of the problems with cumulative voting. Not all stakeholders are created equal. Failure to achieve internationalization, which had not been on the "radar screens" of the team prior to the workshop, would have been a strategic requirements misstep of significant proportions.