Planning a project is difficult, and selling the plan to your team is even more difficult. One way to integrate these tasks is to have the team do the project planning. When this happens, they do most of the work and they buy into the plan because it's their project. But how does a team plan a project?
Tuesday, 9:50 a.m.
It was Tuesday morning at 9:50 and I was walking into the lobby of a hotel down the street from our office. I’m Eddie, the lead hardware engineer for HomeSecSys. We make home security systems that involve hardware and software.
I'd received a memo from Patricia, one of my company’s project managers, about planning our next project, the Model 2005 Home Security System Controller. The memo said we were to attend a two-day "cards-on-the-wall" planning session in order to create a project plan, but I didn't want to go. I thought I had too much work to do preparing for the project itself to waste two days in a hotel conference room doing a bunch of "touchy-feely" team stuff.
The memo emphasized that we were to be on time, and we were not to leave during the session. Patricia wanted us present from start to finish.
Boy, this hotel needs an interior decorator, I thought to myself when I found the conference room. The walls were bare and could have used a paint job. There were no plants, tables, or cushy chairs along the walls. Our company never pays top dollar for anything I thought. It was just like us to rent a conference room in a run-down hotel.
Just then, Patricia started the session. "Welcome. Let me introduce Faye to you. She is a skilled and experienced facilitator. Faye doesn't know much about home security system controllers, but she does know how to help us plan this project."
Faye introduced two people who came with her. First was Richard, who sat in front of a laptop and printer. He would record what we did. What's the matter, don't they think any of us can type? Next was Alan, a young guy who looked like he was still in college. He was Patricia’s "assistant," but I know a gopher when I see one.
All the other team leaders for this project were here, and so was Bruce, the engineering manager. I knew Samantha, a software engineer; and Cecil, a systems engineer. I also recognized the faces of the other people, but couldn't put names to them, since they worked in other departments I didn't deal with often.
Faye introduced the cards-on-the-wall technique. The cards were blank 5"× 7" cards. We were to write task information on them and pin them to the walls. Then, we were to tie each task together with yarn to show precedence and make a network of tasks. The result would be our project plan.
Our company has gone haywire. This was a ten million dollar project to produce our next major controller, and here we were in a cheap hotel with cards, thumbtacks, and dollar store yarn.
"To help learn the process, we’ll plan the lunch party we're having on Thursday," Faye began, "and that party will celebrate our success at planning the Model 2005 Home Security System Controller project."
"What's the end state of a party?" Faye asked.
Kelly from QA joked, "We are all in the party place with food, drink, and entertainment."
Faye took it seriously. "Good, here's a card and marker. Write 'people, place, food, drink, and entertainment' on it, and pin it to the wall over on the far left. Please print legibly because we all need to read these."
Kelly didn't know what else to do, sohe did what Faye suggested.
"Now what do we need to do to have those five things?" asked Faye.
Slowly but surely, people answered. With each answer, Faye put a card and marker in the hands of the contributor. People were soon stringing yarn between cards and poking holes in the walls with thumbtacks. I hope the hotel doesn't mind about the holes.
In fifteen minutes we had planned a party. The wall looked like a PERT chart or network of tasks. Each task card described what had to be done, who was to do it, how much time would be needed, the prerequisites or inputs to the task, and the outputs of the task (see Figure 1). Faye asked that each writer put his or her initials on the card so we could ask questions later. Richard entered the information in the laptop and printed it. Alan took the plan and walked out of the room, mumbling something about making reservations. Someone needs to tell Alan that the party was a joke. It was, wasn't it?
The practice session was interesting. I could see how this might work for some things, and now we started planning our real project, the Model 2005 Home Security System.
Faye began by restating her question, "What are the deliverables?"
By now, we knew the drill. If you opened your mouth, you wrote a card and pinned it on the wall. This kept some of us from answering. Who wants to stand up in front of the group?
Faye quickened the pace so that most of the people were standing at the wall. When this happened, I felt more awkward sitting than standing, so I joined in.
Faye kept pumping us with questions. "What's the product of this task? What do you need to produce it? What do you need before that? Which people will do this? How much time do you need?"
When we answered with "I don't know" or "I'm not sure," Faye would follow up with "What do you need so you will know?"
"Well, I need someone else to tell me something or give me permission," was the usual answer. Since all the right people were in the room, Faye would take us to that someone and help us get the information and permission. Interesting.
Faye also cautioned us about our time estimates. "There is a temptation to underestimate time in front of the other team leaders. You may want to look good by stating how quickly your section can do something. But to make this work, please give realistic rather than optimistic estimates."
At this point, Patricia, as the project manager, reinforced Faye's instructions. "No one has dictated a delivery date on this project. We are working here to learn how much time this project really needs. If our plan requires more time than upper management can swallow, we will work with them to change the scope of the project. For now, upper management needs realistic estimates to make their decisions."
After a while, the room was filled with noise. There were three or four conversations in progress all the time. Some were funny and some heated.
Faye, who was standing next to Tabitha, our test engineer, asked for everyone's attention.
"Tabitha has raised an important point. She thinks we need to do a market survey in the manufacturing area early in the project, but doesn't feel comfortable writing that card since it isn't a testing issue. I want everyone to know that each of you can write any card and place it on any area of the wall. You all own the entire plan."
About mid-morning, Alan rolled in food and drink. Having refreshments right there kept us from sneaking out to the hotel snack machines. Alan kept the refreshments stocked for the two days. Maybe our company isn't so cheap after all.
Just before lunch, our software lead, Samantha, pulled Patricia and Faye aside. "I've been scribbling some assumptions, but they aren't tasks. I also want to have some policies in place to help me during the project, and I think they will be helpful to others as well. Could I have a few minutes to share these with the group?"
"Good points, Samantha," and Faye turned to the group. "Everyone listen up for a moment. There are things we'll need to note that will be helpful, but they aren't tasks. Where do we put them?"
"Let's stick them on the side wall," suggested Bruce, our engineering manager.
Faye nodded in agreement.
Most of us spent the next ten minutes writing such things on cards and sticking them to the side wall. Bruce, an organizing genius, spent the rest of the morning rearranging and grouping these things on that wall. By lunch, he had clumped together assumptions, policies, major risks, critical attributes, and critical personnel groups.
We came back from lunch and considered the cards we had pinned to the walls during the morning. Cecil, the systems engineer, and I felt we needed to move and maybe even discard several cards, so we mentioned it to Faye.
"Cecil and Eddie have raised a good point. They want to remove some cards from the wall. Let's agree that we don't do that without the consent of the group. In addition, let's not throw away any cards just yet, but pin them to the back wall for now in case we need them later." And so we proceeded as a group to prune a few items without discarding them entirely.
Little by little, we were building a project plan on the wall, and there was a flow to it. We had a list of deliverables, and we were building up the tasks needed to produce them. This isn’t easy, but it isn't rocket science either.
There was also something positive about seeing the entire plan come together. I usually understood only my part of a project, and everything else was just "out there" somewhere. Here, however, I could see what everyone else was doing. I heard them talk, saw them write cards, and understood why they were moving the cards around.
"How can you keep up with all the changes we're making on the walls?" I asked Richard during a break.
"Well, I don't," he replied. "I type for a few minutes and then wait. I know you guys will move things around, so I don't waste time typing as you pin cards to the wall. You tend to work in cycles, a flurry of card writing, a pause, a discussion among two or three of you, some card rearranging, and then you move to another section of the project. I wait until the conversations are done and enter what you settle on."
When we quit for the day, Faye and Patricia told us that no one was to go back to the office. They said to go home, relax, enjoy the afternoon with family and friends, and sleep well. I haven't worked a six-hour day since...well, since eve.
Wednesday, 9 a.m.
People charged into the second morning. The long afternoon off and late morning arrival (I'm usually at work by 8:00) were nice. We spent the first half-hour repositioning the cards we had put on the wall the day before. Everything seemed so clear now. The problems were still in front of us, but we worked through them.
Faye and her staff were beginning to impress me. She asked questions, worked the room, pushed some people to participate, and let others sit quietly. We were definitely making a plan. Maybe there's something to this stuff.
The people in our group had different styles of working. Several people seemed to sit more than stand, but Bruce stayed in his chair the most. He was writing furiously, a mechanical pencil in one hand and a straight edge in the other. After some time, Bruce asked Patricia and Faye to look at his work. He had noticed several major patterns of work and intermediate products.
Patricia pulled Samantha, Cecil, and me over. There were repeating patterns with common elements, and Bruce had found a way to remove about 25% of the task cards. This meant we could reduce the workload on the project by about 25%. How did he figure that out? How did Faye know to leave him alone at the table? Would we have seen this without this session?
That afternoon, we had another timesaving breakthrough. Mike, from manufacturing, and I were talking about the cycles of hardware prototyping and engineering rework. In the past, I would give him a board layout and usually wait three weeks while his crew built it. Then I could test the board, rework my design, and we would do this again.
We discovered that if I sent my preliminary design information to Mike on a daily basis, he could start ordering parts. Also, if he spent one extra day building two prototype boards instead of one, I could have one to start testing two weeks early. This short chat showed us how to cut six to eight weeks off the project.
I also learned why I could never find Mike in the afternoons. He is in a carpool that comes in at 6:00 and leaves at 3:30. Now I knew not to waste time in the afternoons looking for Mike and sulking when I couldn't find him. We decided that I could leave voice messages on his phone at the end of my day. He would check his phone at 6:00 the next morning and have a full status sheet on my desk when I walked in at 8:00. That Mike is a pretty reasonable guy.
Each team leader learned similar things about other team leaders and their departments. We found out what each other's departments did with our products, and we learned a few simple things that would make it easier on everyone. The result meant we could save a little time and money every day.
By early afternoon, we were finished. We had a plan and we could see how it would go from start to finish (see Figure 2). It was all in front of us and we understood it. We knew the critical parts and how it all fit together. In fact, it seemed that we knew a lot, and it seemed that I was using the word "we" a lot.
We also could see the complexity of such projects. There were so many things we had to do right to build our controller. Were all our projects this involved? It's no wonder new product development costs so much. Maybe that's why upper management seemed hesitant to do these things.
And something else had happened in these two days. The specialists from different areas had jelled into a team. We had created a plan we believed would work.
The next morning, our planning team met back at the hotel for our celebration party. I couldn't remember having two days in a row that were short and productive. With all our new experience, maybe they should have let us replan our party after we had planned the project. Anyway, it was the best lunch we ever had at work.
Reviewing the Plan
Monday morning we reconvened in our conference room at the office and found the side wall covered with our plan. Richard had captured our hotel conference room mess and put it in a finished format.
Faye then led us through a discussion of our plan. She had some 3"× 3" sticky notes and markers and asked if we wanted to add or rearrange any tasks. With that, we added a dozen tasks and crossed off another dozen. Finally, we were satisfied.
Amazingly, this peer review took about an hour, and we had never reviewed anything this big so quickly. In fact, it seemed we had to be doing something incorrectly. We had, however, reviewed the plan while we were making it. All our moving, changing, deleting, and adding cards during the session was like a real-time peer review.
We had a good plan because the people who knew the work had created it.
"This plan looks good," said Patricia. "The only thing missing is that it doesn't account for those things we can't anticipate. No plan does that. So, we will leave this on the wall and meet each week to update it. We'll use what Faye has taught us about working as a group while we make the changes." But surely we have it right.
It turned out that Patricia had been right about the unanticipated things, so we altered the plan almost every week. At first we were hesitant, since we had worked so hard during the cards-on-the-wall session.
As the weeks passed, we realized that we had done a good job during the session with Faye, but projects change with time. Marketing dropped in a few new requirements, upper management subtracted and added budget (more subtraction than addition), and technology changed.
But the changes we made to this plan were easier to make than changes we had made on previous projects. One reason was that the team leads knew so much about the entire plan. We knew how things were connected, and we could anticipate how changes might trigger other changes.
Another reason was that the plan was visible. We posted it by the coffee pot and soda refrigerator. When my hardware engineering team offered to help revise the plan, I couldn't believe it. I never would have thought they would be interested in such management-type activities. They even asked if they could attend the cards-on-the-wall session before the next project.
Having such a visible plan meant that everyone could see how everyone was doing. When anyone was behind schedule, people helped one another. Sometimes the help was simple encouragement. Other times people took care of off-project tasks—such as running errands—to free up the person who needed to concentrate on the project.
We all had more reasons for this project to succeed. We had always worked hard on our projects, but this time we could only look at ourselves if the project failed. We had planned it, we were in charge, and we were responsible.
In the end, we finished the project a little ahead of schedule. One of the reasons is that the other team leads on the project were real people now. I knew them because we were locked up in that hotel for two days. They had families, hobbies, personalities, and lives. I enjoyed stopping by their departments and talking, and those chats often turned into ways to save time and improve the product. The cards-on-the-wall session turned out to be just fine.
It's Your Deal
This story was about a project that owed much of its success to a cards-on-the-wall planning session. It reflects much of what I have experienced in various real-life, cards-on-the-wall sessions.
Good cards-on-the-wall sessions have plenty of advantages. In the example, Eddie and the other team leaders owned the plan, and they were committed to seeing it work. They watched it evolve, and they understood how and why the pieces came together.
Most important, Eddie and the others stopped being independent team leaders and started being people working together on a common vision. And, of course, that can mean all the difference between a plan that gets used and one that sits on a shelf.