Making a Party out of Project Management: Chapter 2 - Planning the Party - Part 2 of 3

Since everyone would be working closely together to execute the project plans, Abby suggested they should take some time to build rapport together before getting into the project work by spending a few hours playing volleyball that evening. By doing this, everyone could get a sense of working with others on the team. They mixed up the teams at the start of every other game so everyone would play on the same team as everyone else for at least two games.

As they played, everyone got to learn a little bit about strengths and weaknesses of team members they didn’t know as well. They formed different dynamics on different teams. In particular, Abby was looking at how teams went through different stages of the Tuckman group development model: forming, storming, norming, performing, and adjourning. This sort of activity is often referred to as a team building exercise. While this wouldn’t help to get the party set up, Abby knew it would be important to help everyone connect and relate before asking them to work together on the project. This connection would help everyone to feel closer and more committed to working together successfully on the project.

The next morning, Abby soon found herself thinking of more ideas about how to make the most of her friends’ help. “You know, I suppose my friends and I will come up with a lot of ideas when they come over today, so I’d better come up with a good way to keep track of those ideas and keep them organized…” Abby thought to herself shortly before her friends were due to return to help some more that morning.

As her friends trickled in, Abby had started working on a plan for keeping track of everything she wanted to get done for the party, and how factors both in and out of her control could require her to make any necessary changes to her planned scope along the way. To help her keep track of what everyone would do and manage any changes that needed to be made, she and her friends developed a plan known as the scope management plan. With this, she decided how she and her friends would determine what to do, write down the details of what to do and then make notes along the way about their progress in getting everything done. For any given thing they wanted to do, they would have to decide who would do it, when, and what they would need. Was there a guide on how to do it? Would an expert be needed, or would a group have to hold a meeting and work together to get it done?

With her friends ready to lend a hand and a schedule of when they were available, Abby spoke more about the main things she envisioned for the party and how she planned to divide it into some main parts like food, décor, and games. She also wanted to make it clear that everyone surely had valuable ideas to share and that it wouldn’t be okay to dismiss someone’s ideas because they “weren’t very good”. In order for everyone to offer their best ideas, Abby knew that everyone had to feel comfortable sharing those ideas with everyone else. This approach helped Abby immensely for the rest of the project because everyone felt included and that their ideas and help mattered to the success of the party, and so they worked much harder and more diligently to help Abby make sure Nathan’s party would turn out great.

The first thing Abby had everyone do after drafting the scope management plan was help her decide on the details of what would be done for the party. These details are called requirements, and they make up a specific list of what the party needs to include. Before everyone came over, Abby had thought ahead and created a system for how to manage the details of these requirements, how to decide what the requirements for the party would be, and how to keep track of whether a requirement had been worked on at all or was taken care of. This system is called the requirements management plan. It’s not the recording of the requirements themselves, but instead it’s the way that a project manager keeps requirements organized and tracks which requirements are taken care of and which ones aren’t. Also, the plan includes the process for considering proposed requirements and then adding them to the list of requirements if the project manager decides to adopt them.

There were a few techniques that Abby introduced to her friends to help them generate ideas for the party and then decide which ideas to adopt. First, they engaged in a technique called brainstorming, where everyone offered ideas for what to do and the ideas were added to a list that Abby was making; there was no judgment or evaluation of the ideas, just collecting whatever came to mind. After doing this for about an hour, Abby and her friends had a good list of items put together. They had made a requirements list.

Abby’s requirements list.

In fact, Abby and her friends were a little too good at coming up with great party ideas. There was no way that they could fit in everything that they had thought of. So, there had to be a way to narrow down the requirements for each of the main parts of the project. How would Abby and her friends decide which ideas to keep, and do it in a fair way that wouldn’t be dominated by anyone and hopefully wouldn’t hurt anyone’s feelings?

The best answer Abby had to this was something known in project management as the Delphi technique, where everybody would anonymously vote on the different ideas in each category, and the ideas with the most votes would be the ideas that would become official requirements for the party [4]. This is usually done in a few rounds of voting; for food, for example, Abby and her friends had come up with several ideas for the grill. They proposed steaks, pork chops, hamburgers, hot dogs, turkey burgers, brats, and chicken.

[4] The Delphi technique can be used to anonymously gain consensus in other areas of the project, like task duration estimation, cost estimation, or prioritizing project risks.

Abby knew that Nathan loved all of these and wanted to figure out which three would be best to serve at the party, to keep Dad from being overwhelmed with too many things to manage while grilling. So, she and her friends voted for what to serve in two rounds, putting their secret ballots into a box that Abby opened to count the votes. In the first round, Abby crossed off all options except for the five which received the most votes. With five options left to choose from, she and her friends then voted again and she crossed off the two items that came in fourth and fifth place, leaving the most popular three items to become the official requirements for meat Abby’s dad would grill at the party. Of course, there were some requirements that wouldn’t need a vote, like the need to have a grill, charcoal, lighter fluid and matches to allow Dad to cook the meat. Abby and her friends did their best to think of everything like that as well [5].

[5] On a project, requirements may be divided into two categories, technical requirements and functional requirements. The same can be done by Abby and her friends. Technical requirements are the need for a quantitative specification to be met for a product to be acceptable to its customers. An example of this would be the meat getting cooked to 165° F to make it safe for everyone to eat. A functional requirement is more about how something needs to work for the product to be acceptable; the plates and flatware people use to eat don’t have to be an exact size or made of a specific material, but they do have to work well for dishing up and eating food during the party.

The group spent the remainder of their time together voting on requirements until a final list could be made. By then it was suppertime, and everyone needed to go home, so they didn’t do any more work on the project that day. Abby was still very pleased with what they accomplished since she now had a definitive but also manageable list of all the things that needed to be done to make the party a success.

By collecting a list of requirements for the party, Abby now knew what things had to be done to throw a successful party for her little brother. The requirements were all items that needed to be completed, but while reviewing the list, Abby noticed that not all the requirements were actually part of the product, the party itself. Some requirements, like completing and submitting the form to reserve the park pavilion, were part of the project scope but not a part of the party; this work would be necessary to enable the party to happen (a project requirement). Other requirements, like the need to seat up to 30 people at a time during lunch, were part of the project’s scope and would be part of the party (a product requirement). Both of these requirement types were needed for the party to succeed.

Abby had one more trick up her sleeve to make sure the party would be just what Nathan wanted, without letting him know it was coming. She asked her friends whose younger siblings were Nathan's friends to have them join her and her friends for a facilitated workshop, to ask them what they think he would really like to have at the party. They would know what he was most interested in these days, and besides, Abby wanted to make sure they had fun, too. A few ideas would be a little too hard to manage, like setting up a batting cage at the park. Some ideas were more doable, like their request for a bean bag tossing contest. After collecting the different ideas from Nathan’s friends, Abby’s friends shared the best ideas that they thought would add fun and excitement to the party without going overboard on work or cost.

Over the next few days, Abby met with friends when they had time and finished working on documenting the many attributes, or descriptive features that each requirement had, as well as determining which requirements had dependencies, meaning they would have to wait until others were completed. Determining and reserving the venue, for example, had to be done before planning a layout and setting up tables and chairs could be done. What about the status of each requirement? Was a requirement currently open (nothing done about it yet), in progress (someone was figuring out what to do for it) or resolved [6] (someone figured out what to do for the requirement)? Abby’s parents had plenty of plates and cups to use for the party, so getting plates and cups for the party was an example of a resolved requirement; setting the plates and cups at the serving table was part of another requirement to set up the food and wares before the party, which was still an open requirement because what to do about it hadn’t been decided yet. All these considerations for each requirement are logged together in a key project management document known as the requirements traceability matrix (RTM). This document ties together a requirement, where in the project scope it belongs, what quality level needs to be achieved to satisfy the requirement, who will work on the requirement, and the current status of the requirement. If needed, a project manager may include additional attributes in their project’s RTM.

[6] Notice how the requirements are not actioned as soon as someone figures out what to do for them. Instead, the project team will figure out what needs to be achieved, then figure out a plan to achieve it, and the plans to achieve all the requirements becomes the overall project plan. Doing the work to actually fulfill those requirements comes in the executing phase of the project, after planning has been done.

Abby’s initial requirements traceability matrix, with some columns still to be completed.

Abby was one step closer to getting the details of the party figured out. So far, she had gone from an initial idea to throw the party, to coming up with some general needs and understandings in the project charter, to now having a detailed list of requirements for the party, what would make it a success, and what should or should not be expected. She was still a long way off from having it all figured out, but Abby and her friends would keep iteratively reviewing the scope over time and acting on new details of work as they emerged. At this point, it was time for them to take the next step by charting out the specific scope elements and writing out their details.

To help herself to better visualize the key elements of scope and keep them organized, Abby used the attributes of her project’s requirements list to make a chart called a work breakdown structure, or WBS for short. Most of the things to be done fell into some kind of category, like food, décor, or games. So, Abby started with those major groups and performed an activity called decomposition, breaking them down into more and more detail. Pretty soon, Abby had enough detail to create the smallest items within a WBS, called work packages. Normally, a work package on a project is a chunk of work that is expected to take between 8 and 80 hours of time to complete, but for planning Nathan’s birthday party, Abby decided it would make more sense for her work packages to be between 8 and 80 minutes long.

“Some tasks, like putting tablecloths and centerpieces on the tables, should only take fifteen minutes for a person to do,” Abby said to herself as she worked. “But I like this way of identifying all the significant things the party should have. I feel like I can look at this chart and almost see the party in it!”

Birthday party work breakdown structure (WBS).

To make sure all the work packages shown in the WBS would be clear to everyone, Abby also created a WBS dictionary to explain the title of each work package in a short but descriptive one-sentence summary. For example, in the Food section of the WBS, the Cake work package describes that “The cake will be a two-layer Devil’s Food chocolate cake with chocolate butter cream frosting”. Descriptions like this help someone to better visualize the details alluded to in the WBS, in case that extra information is needed to clearly understand the project intent.

After all the work Abby did to develop a concise but thorough project scope statement, lay out the major deliverables in the WBS, and then define every important WBS term with the WBS dictionary, she finally had all she needed to fully define her project’s scope. With her scope statement, WBS, and WBS dictionary all prepared, Abby had created what is called the scope baseline. The scope baseline made it clear what the party would entail, going from a general summary in the project scope statement to a detailed description of work packages in the WBS and WBS dictionary, all based on the exact, specific details recorded in the requirements list. Now that Abby had a clear idea of what would be produced in the project, the next step was for her to start working out what it would take to produce everything that the project scope required.

Next post in the series: Making a Party out of Project Management: Chapter 2 - Planning the Party - Part 3 of 3