Making a Party out of Project Management: Chapter 3 - Figuring Out the Details - Part 1

               After Abby and her friends finished defining the scope of the party and figuring out how communications would work, it was time for them to go home for dinner. Abby made sure to take a nice break from the work, knowing there was plenty to do still and not wanting to get burned out. Her mom was almost done making dinner when Nathan watched her put a thermometer in the pork chops.

               “How come you need to do that, Mom?” he asked inquisitively.

               “The meat has to be cooked hot enough that we won’t get sick from eating it,” she explained.

Even though Abby was taking a break from her work, an idea still came to mind.  “If Dad’s grilling meat for everyone at this party, he’ll need to check it with a thermometer to make sure it’s thoroughly cooked, just like Mom is doing,” she thought to herself, “and for everything else in general, how do I know that the work for the party will be done well enough to make it a success?”

After a nice dinner and mealtime conversation with her family, Abby decided she was ready to get some more work done that evening. She went to her room and kept thinking about what it would mean for the work on the project to be “good enough”. How would she know? How would she measure work and results? Thinking back to her work with her friends that day, Abby knew she could rely on the scope they defined to guide her in deciding what to check for quality as work occurred. In addition to what to check, Abby also tried to think through how to measure each quality item and when it would need to be measured, and how to record results and make project document updates.

With that, Abby set out to make herself a quality management plan. She knew things needed to be measured and checked to ensure the party would be a success, but she also knew that having a method for doing all of the quality checking was as important as the quality checking itself. What would be quality in the eyes of the stakeholders, specifically Nathan, Mom, and Dad? What risks [10] could be realized (in other words, could happen) if quality were to be lower than required? While better quality is usually assumed to be a good thing, could quality actually be made too good to the point of being counterproductive?

[10] A risk is an event that may or may not happen during a project and may have either a positive or negative impact on the project.

Pondering questions like these helped Abby to write about key concepts to make a solid quality management plan. She zeroed in on what types of quality were important for the project, and how much emphasis on quality was right for the party she wanted to throw. As Abby examined each major portion of her project’s scope, she performed cost-benefit analysis to decide what quality measures were worthwhile. Looking over the picnic tables after they are set to make sure they look good would be one thing – measuring with a ruler to make sure the tables are set exactly would be a little overboard. The quality measures Abby chose to adopt would need to be noted in the requirements traceability matrix to ensure they were met as part of fulfilling the project’s requirements.

WBS ID numbers, quality specifications, and notes added to the requirements traceability matrix.

Next, Abby came up with some specific quality metrics to use for ensuring things were being made and set up correctly. These metrics would be the specific numerical levels required to fulfill certain quality criteria. Some of these included checking the temperature of the meat as it comes off the grill or ensuring all of the food items on the serving table have serving utensils. Others included ensuring all of the seats in the park are clean and the garbage cans aren’t too close to the eating area. How clean is “clean enough” for the seats, and how close is “too close” for the garbage cans? Evaluating some quality metrics would be straightforward, like making sure there were tongs, ladles, and serving forks and spoons to help people load up their plates.

With other metrics, Abby asked around or used trial and error. Holding the party in a big, open park, Abby figured it would work well to have the garbage cans about thirty feet away from the eating area and everything else. That way, people wouldn’t have to walk far to throw items away, but they also wouldn’t have to endure foul odors or swarms of bees while they ate or played. Less than twenty feet would cause these problems for people eating, but forty or fifty feet away would be excessively inconvenient.

Most metrics would need to be checked at specific times in the party prep, with many of those specific times being right before the start of the party. Abby wanted to make quality checklists to review everything in the right order, as efficiently as possible. She even drew up a map of the setup she envisioned at the pavilion to help her understand how the party would flow and where she should go to check on everything. Of course, it only made sense that these checklists would include items Mom and Dad would want to review, and that the metrics on the checklists would be up to the quality standard they would want. What’s the point of making something to comply with a quality metric if that quality metric isn’t good enough to meet the customer’s requirements and needs? It wouldn’t do any good, for example, to have a checklist item for meat cooking to 150 degrees or “hot” if it has to be cooked to 165 degrees before it’s safe to eat.

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

Some of Abby’s friends were pretty busy with summer jobs, sports camps, and family vacations, but everyone was happy to offer help where they could. They let her know when they could spare time and when they would be away, and Abby made a calendar to keep track of when everyone was available to help out. Professional project managers do this as well, assembling what is called the resource calendar. Often, people on a project at work have other jobs or projects that they spend some of their time on, requiring a project manager to know when a team member is or is not available to help with the project. This is a little different from the project calendar, which tells the hours and days of the week in which the whole project team generally works. In a professional work setting, the project calendar usually has working hours set during the workday Monday through Friday, with weekends and holidays typically kept as non-working days [7].

[7] If you decide to work in project management, don’t be shocked by the request to work an occasional weekend or two for a special event like the startup of the system created by your project, often referred to as the “go-live”.

It was a priority for Abby to include her friends and parents in as much of the project as she could, including the planning. Not only would it make everyone feel included and needed, causing them to work harder and be more committed to the project, but they would also bring great ideas and skills that Abby wouldn’t have on her own. Luckily, Abby had several close friends and of course, her parents were eager to help. But there was a catch – in order to use all of this help effectively, Abby needed a way to keep all of the roles, responsibilities, and relationships organized, and to ensure everyone had the knowledge and skills they would need to succeed in their jobs.

So, Abby set about creating an overall structure for her human resource management plan, making an organizational chart (“org chart” for short) for who would perform what roles on the project, as well as a RACI matrix to ensure good coordination between everybody. She engaged in networking, asking neighbors for advice on how to manage her team and what they thought would make the party a success. Mom and Dad provided expert judgment about how to help and take care of everyone working on the project (providing snacks, drinks, and encouragement) based on their years of life experience and working with kids.

After setting up a general outline, Abby began to fill in the details of her human resource management plan. She added her friends to specific places on her org chart and RACI matrix based on what work items they would help complete. With roles clearly laid out across the main work items of the project, Abby knew which friends to talk to about getting each of the items done. Part of her human resource management plan was a staffing management plan, which would include how Abby would provide team members with job and safety training they would need for their tasks [8].

[8] On larger projects, a staffing management plan may include a staff acquisition plan to define the ideal candidate for each role, and a staff release plan documenting when each project team member’s work on the project is expected to end, as sometimes team members are only involved in a project for part of its duration. Larger projects may also have compliance requirements that affect staffing options, such as contractual, union, or regulatory requirements.

So, Abby thought through and wrote down the training that would be needed for each role. For example, she would train those setting up balloons on how to tie them down correctly so they wouldn’t come loose and float away, and how to use a ruler to curl up the ends of the balloon strings to make them look fancier. There would also need to be some safety training, like ensuring those who arranged the picnic tables at the park lifted the tables with their legs, not their backs. In addition to this training, Abby would brief everyone on certain safety points to keep in mind, like moving very slowly with hot or sharp items, cutting away from oneself and others if a knife or scissors had to be used and keeping their fingers away from the cutting path.

Birthday party project organizational (org) chart.

RACI matrix for food, décor, and games.

Abby wanted everyone on her team to feel valued and supported as they helped her to get the party ready. In addition to thanking everybody for a job well done as they accomplished big tasks and helping anyone who struggled to keep up, she ensured everyone had snacks and drinks to keep them going.

“Thanks for bringing us these snacks, Abby! I really love these cheese crackers – they’re my favorite!” one of her friends exclaimed.

“Thank all of you for all of the help you’re giving me! Everything’s been going really well because of all you’re doing!” replied Abby, happily.

With most things getting done ahead of schedule, Abby decided the team had time to take a break and relax for a little bit, helping them to keep their energy and motivation up.

“How will everyone know what they need to know, when they need to know it?” Abby thought to herself, after she finished planning how to manage her team. “Actually, I need to tell other people (stakeholders) certain things, not just my project team!”

By now, Abby had caught on to a useful pattern – don’t just pick up the phone or start sending texts and e-mails, first make a plan to figure out the best way to communicate with everyone. She would need to review her initial communications plan and do more work to plan communications management. Different people would need different communications at different times and in different ways. The big thing that Abby needed to help her further refine her communications plan was her trusty stakeholder register, which would remind her of who had some kind of interest, or stake, in Nathan’s party.

Reviewing the stakeholder register to assess communications needs.

Abby sat back for a minute to ponder what should be added to this plan. What communications do I need to have with my team to lead them to complete the project successfully? How about people who are just attending the party? Mom and Dad would need certain communications, both as her and Nathan’s parents and as the project sponsors. As she went down her list of stakeholders, ideas started to flow for how to best share information with each, as well as what information she would need from them, too. She even thought about how to keep her number one stakeholder, Nathan himself, from learning about anything that would ruin the surprise of the party.

The activity of reviewing communications needed to and from each stakeholder is called communication requirements analysis. Understanding these requirements allowed Abby to understand how information should flow between the stakeholders and to identify possible challenges with communications ahead of time. One thing Abby wanted to avoid was everybody trying to communicate directly with everyone else about the project work, as this would overwhelm her and lead to complete chaos. In fact, there’s even a formula to show how messy that can be:

So, if Abby and nine other people all communicated directly with each other about project work, there would be:

Having played “telephone” before, Abby knew how messages getting passed around to different people keep gradually changing over time. She imagined how rampant misunderstandings would be, even on a small project like this, if there was no thought put into the flow of information ahead of time.

This work really convinced Abby that she was right to give some thought to how to effectively communicate with everyone on her team. To structure the project communications, returned to her org chart. Abby thought it would make good sense to put a few of her friends on each major portion of the WBS, and to structure her org chart to look like the WBS. She would have specific friends working on each main aspect of the party – they would send and receive communications specifically for the part of the WBS they were working on. Those working on food wouldn’t have to worry about communicating project details with those working on décor, for example.

Birthday party project org chart with communication flows.

After detailing that, Abby went a step further and added plans for communicating with a few other groups of stakeholders – Mom and Dad and the party guests. She wrote down specific communications they would need and who on her team would help Abby to provide those communications. Again, Abby designed this flow to ensure messages sent to stakeholders would be clear, accurate, and consistent.

The need for clear, accurate, and consistent communication got Abby thinking that she also needed to consider communication technology, communication models and communication methods that would work best for everyone. For technology, Abby kept it simple – face-to-face communication with her project team, e-mail and phone calls with the vendor, and face-to-face, calls, and texts with Mom and Dad. Depending on the invitees, some would need paper card invitations and some would prefer e-mail invites. This combination would be a good blend of communications tools people had available, that they liked to use, and that worked well for their stake in the project.

Luckily for Abby, she learned about the richness, or warmth, of communications modes in speech class last school year. Each of these different ways of communicating would require good judgment about which to use and when. Phone calls would be rich in vocal cues like tone and emphasis of key syllables, e-mails would be very thoughtfully worded and include attachments or screenshots, and texts would be very short and to the point. When would a model be a poor choice? One example could be trying to text someone a long set of instructions that would be better covered face to face or by e-mail.

After thinking through the strengths and weaknesses of different communication modes, Abby made decisions about when to use each one and how to ensure everyone got all of the information they needed. Sometimes, it would work best to have the information where people can grab it when they need it, like standard birthday package information on a party shop’s website. This is an example of a pull communication. Other information would be better delivered by a push communication, where the sender tells the receivers about updates on a regular time interval or some event that triggers a communication. Updates to let Mom and Dad know that certain party preparations are all set would be a good example of this. Both of these examples generally don’t require much back and forth, also known as interactive communication. An e-mail thread between Abby and a party shop about package details or a phone call with Mom and Dad to discuss buying an extra item for the party would be good examples of interactive communication.

Some communications are one-to-one or one-to-many, but there is also a lot of group communication to collectively talk through how to best do something on a project, in the form of meetings. Abby was already doing this with her team to brainstorm requirements, and as they bounced ideas off of each other, a requirement mentioned by one person sometimes caused another person to think of another requirement. Later, she would also need to hold another meeting when it came time to set up the picnic shelter where the party would be, to ensure everyone would understand the plan for setting that up and have a chance to ask any questions.

Taking all of this into consideration, Abby had a good idea of the best way to communicate depending on the stakeholder and the situation, and how to use each technology to maximize clarity of communication. Of course, some follow-up and deeper discussion would be needed to clear up confusion, but Abby had a good plan to limit problems from unclear or incomplete communications. Below is a table of thoughts Abby put together about each type of communication, and how each one might work best for each different group of stakeholders on the project.

Communications plan for communicating with stakeholders.

Some of Abby’s communications would go out on a regular basis, like showing her team how they were progressing on getting all of the prep work done for the party. Other communications would only be sent out as they were needed [9], like if Abby needed to ask her parents about reserving the kitchen table on Friday afternoon to provide extra workspace during that time.

[9] Sometimes called ad-hoc communications.

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 of 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 of 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 of 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 of 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 of 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 of 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