Channels ▼
RSS

Cards-on-the-Wall Sessions

, July 01, 2001


July 2001: Cards-on-the-Wall Sessions

Planning a project is a difficult but necessary task. Not only must the project planner (usually the project manager) know about everything that needs to be done on the project, he must also consolidate all these details into a form that will guide the project's management.

Once the plan is complete, the real challenge begins—selling the plan to the people who must execute it. Imposing as it may seem, the title "project manager" doesn't necessarily inspire devotion or blind agreement to a plan. As a project manager, I have to convince everyone that the plan holds together and makes sense.

A cards-on-the-wall planning session helps to create and to sell a plan. This group technique brings all the involved team members together, drawing on their collective expertise. With this method, I don't need to sell the plan to the team—they already own it because they created it themselves. And this simple, low-tech system has proved markedly effective for a variety of projects—I've used it to plan one-week sprints and four-year marathons.

Figure 1. The Project Plan

An example network of tasks from a cards-on-the-wall session. The tasks are linked with string to represent precedence.

Figure 2. Sample Template

A sample template for a task card, which will contain essential information, including a descriptive task name, the inputs to or prerequisites for the task, and the task's outputs.

Simple, Yet Effective
The cards-on-the-wall technique enables a team to plan a project by attaching cards that represent tasks to a wall. The tasks are linked with string to represent precedence. This collection of cards and string represents a network of tasks: the project plan (see Figure 1). It also creates a team who believes in the plan because their own inspiration and perspiration produced it.

The network of tasks depicted in Figure 1 has two main elements: task cards and their connections. Figure 2 shows a sample template for a task card, which contains essential information, including a descriptive task name, the inputs to or prerequisites for the task, and the task's outputs. The task card must also delineate who will perform the task and how much time he'll need. Enter these details when you discover them; people learn as the sessions progress.

The strings leading from card to card represent the connections between tasks in their order of precedence: A task can't begin until the task(s) on its left is completed.

Planning to Plan
I recommend using a professional facilitator to ensure a successful cards-on-the-wall session. If you can't hire a professional, train someone in these skills (see the sidebar for further information). No matter who facilitates, you must plan the session.

You should also invite the right people to your cards-on-the-wall session. If the project will employ a dozen or fewer people, invite everyone. If the project requires several dozen people, invite only the team leads and several other key participants. Everyone should be present throughout the entire session.

Location is also important. The room must have large blank walls, but don't choose a room that has to remain in pristine condition, as you'll be taping cards and sticking pins into the wall. Choosing an off-site setting helps to minimize interruptions.

Allow sufficient time for the session. You can create a plan for a six-month project in two half-days. Two short days are better than one extra-long day, because people can sleep on their ideas and develop fresh perspectives for the second day. The session may last between one hour and five full days, depending on the project's size and complexity.

The facilitator will need one or two assistants: a recorder who is an expert with an automated tool and the computer, and an administrative assistant who will track down necessary items, run errands, take phone messages and keep the refreshments fresh. The admin isn't always needed, but can be very helpful if you have a dozen or more participants.

The Session
If the group is composed of many people who are unfamiliar with each other, begin with a warm-up exercise, such as organizing the party you'll have after the planning session.

Starting the plan is usually the hardest part. I like to begin with the products of the project, usually on the far right side of the wall, and work backward.

In the beginning, there will be some awkward moments as team members wonder what to do. The facilitator needs to engage people by asking useful questions like:

  • What is the end product?
  • What items do you need to produce the product?
  • What actions must you take before you can do that?
  • Which personnel do you need?
  • How much time do they need?

When people start talking, the facilitator should give them a blank task card and a marker. Don't tape-record the session; its success depends on placing cards on the wall.

The general rules of participation I use (posted on a side wall) include:

  • Start when everyone arrives; no sooner.
  • All participants must stay for the entire session.
  • Anyone can create a card at any time for any part of the plan and place it anywhere on the wall.
  • Anyone can connect cards with string at any time for any part of the plan.
  • Participants must place their initials in the corner of all cards they post.
  • Participants must write legibly.
  • If someone can't understand a card, the writer must explain it.
  • No card or string can be pulled off the wall without group consent.
  • Pulled cards aren't thrown away—save them on another wall until the session has ended.
  • Principles, policies, major risks and other concepts learned should be written on a special sheet on a side wall. Though these may not be tasks in your card network, they can be useful in later stages of project planning.

You can measure the quality of a cards-on-the-wall session by the amount of noise in the room. People should be discussing, debating and reaching consensus on many issues. A good session evokes participation from all attendees.

The facilitator should look for people who aren't actively participating, and solicit their ideas. Some of the best insights come from that person who's sitting silently scribbling ideas on paper or perusing the wall with his hands in his pockets.

Throughout the session, the recorder enters data into a computer. The plan will change many times during the session, so the recorder shouldn't enter too much information at any one time—just enough to capture key points and lighten the post-session workload.

The cards-on-the-wall session ends when the wall is covered with a plan that will allow the team to move from concept to reality: the completion of the project.

After the Session
Planning doesn't end with the session. The recorder polishes the plan, enters it into the computer and then creates a hard copy.

The team then reconvenes with the facilitator to review the plan in detail before the project begins.

It's important to remember that the plan is never finished: It changes constantly until the project is finished. People will require more or less time to perform tasks, some tasks become unnecessary, other tasks are born from thin air, and management adds or subtracts products. Expect change and live with it.

The Advantages
A cards-on-the-wall session offers several advantages over a dictated plan: ownership, visibility and higher quality. The team owns the plan they produced in a cards-on-the-wall session. They identified the tasks, their connections and their duration. No one needs to convince the team that they can do it "if they work hard enough." Though it may be cheaper in the short term to have one person create a plan and pass it on to the team, this dictatorial method doesn't motivate people to work toward the plan's success. Without direct "ownership," it's simply easier for people to sit back, work half-heartedly and watch someone else's plan fail.

It may be difficult for traditional planners to understand that a plan produced in a cards-on-the-wall session is more effective than one produced solely by managerial fiat. Professional planners have the experience, expertise, training—and titles. How could a bunch of programmers, testers and engineers create a better plan? The answer is simple: These people know their own jobs better than anyone else does. The professional planner can and should help, as experienced planners will be aware of forgotten tasks and other buffers that are necessary to absorb risk. However, the project team should always be responsible for the bulk of the planning.

Another factor that improves planning quality is real-time peer review. At a cards-on-the-wall session, everyone is present, with many eyes to catch mistakes. This review and correction occurs organically, without most participants even noticing.

Caution!
Before you dive into plan management, heed these words of caution about managing the plan your team produced. First, beware of using an automated project management tool. While an automated tool can help immensely for many management actions, you shouldn't expect it to guide you through the project. It's also a bad idea to use an automated tool if you haven't managed a project before or served as an apprentice to an experienced project manager. In those cases, use the cards on the wall throughout the project. They will help you learn the basics of project management.

Next, honor humility and honesty. The facilitator must work with the team members in such a way that they create a realistic—not an optimistic—plan. Setting durations for tasks is not the time for bravado ("I can do that in only two days"), and creating a plan is not an exercise in "getting the right answer." The team can't go into the session with management directing them to "figure out how to deliver all the products in six weeks, not nine" or "work hard, because the last few projects were 50 percent too long." Create a plan you can live with, and then hold firm to your convictions.

Finally, projects succeed when people work together. Having a plan doesn't mean that everyone will show up and do wonderful things every day. People are people, and we all have good and bad days. Software development is an intellectual pursuit, so these good and bad days have significant influence on the project.

One More Result
One last benefit can come from a successful cards-on-the-wall session: It helps a disparate group of people gel into a team to build that rara avis—a plan that works.

I've seen cards-on-the-wall sessions produce what seemed like miracles. My current project—40 people, four years, $33 million—had an enlightening cards-on-the-wall session mid-project (yes, mid-project, but that's another story). People from different departments gathered in one room for a couple of days. In this session, their greatest achievement was learning how to send partial products from department to department, which enabled them to cut months and millions of dollars out of the project. More importantly, they developed relationships that helped them work through the unexpected problems that arise in business every day.

Acknowledgments:
Thanks to the following fine people for contributing ideas and comments: Johanna Rothman, Martine Devos and Dale Emery.

[return to article]

The Materials
A shopping list for a well-prepared, successful cards-on-the-wall session.

Cards: The basic materials are 5"x7" cards. Sticky notes of the same size are good. You can also use 8 1/2"x11" pieces of paper. It's easy to create task templates on a word processor and print them ahead of time. Use cards of a single color for the vast majority of tasks. I use different-colored cards to emphasize some tasks, but I've found that using more than two colors can cause confusion. You'll also need something to stick the cards on the wall. The best tools are pushpins and thumbtacks for soft walls and tape for hard walls.

Walls: The bigger, the better. Don't let doors and corners impede your planning. Use the string to jump over such obstacles. Large white boards serve well as walls. It's easy to write notes and draw lines on these.

Markers: Black, fine-point Sharpies are my favorite. I may use one other color besides black, but no more. There are always times when I want to emphasize a task, but too many colors can be confusing.

String: Yes, string or yarn. This is readily available and cheap. As with the cards and markers, I use one color for the vast majority of the plan and have a second color on hand for emphasis.

Tables: The tables hold materials and refreshments. They also allow for some writing. Chairs are needed, as some people think best when they're comfortable.

Refreshments: A cards-on-the-wall session evokes plenty of discussion. Coffee, tea, water, soda, juice and so on will be needed. Snack foods are also great.

Computer Tools: The recorder needs a reliable, powerful computer and printer. The recorder also needs an automated project management tool such as Microsoft Project or Scitor's Project Scheduler (but, as I mentioned previously, beware of automated project management tools if you haven't managed a project before). The computer needs a quick backup mechanism (zip drive, writeable CD-ROM drive). Back up data every hour.

Further Information:
Books

Facilitator's Guide to Participatory Decision-Making by Sam Kaner, New Society Publishers, 1996.
Project Retrospectives by Norm Kerth, Dorset House Publishing, 2001.
The Software Project Manager's Handbook: Principles that Work at Work by
Dwayne Phillips, IEEE Computer Society, 1998.

Consulting Firms

MG Rush Systems Inc., Gary Rush, manager. http://mgrush.com.

[return to article]


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.