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

               The next day, Abby continued to work on the schedule of setting up the party. Most of the work on this was done, but she needed to make sure everything could get done in time for the party. To do this, Abby would calculate a very important timeline in project management known as the critical path. The critical path is the absolute minimum amount of time required to complete all the work for a project from start to finish, and any delays in the tasks on the critical path will cause a delay in when the project is finished. If you want to finish a project as soon as possible, what are the tasks that all have to happen one right after another with no break in between them?

               To figure out the critical path, Abby needed to review what tasks had dependencies and how long they all took. When she was sequencing tasks the day before to make sure everyone was available to do tasks at the right time, she made a big flowchart of her tasks to help her to visualize the sequence of tasks from start to finish. Using this flowchart, she started to put little numbers in the upper corners of each box that represented how many minutes into the project a task would start and finish. The range between the little numbers represented the number of minutes expected to complete each task [12].

[12] Note that on a real project, these numbers will likely be in hours or days instead of minutes.

Abby beginning to illustrate the forward pass of sequenced project tasks.

In the upper-left corner of the first task, Abby wrote the number 1. The first task would start in the first minute of party setup. It would take 30 minutes to bring décor and games to the pavilion, so she put a 30 in the upper right-hand corner of the task. This task would be executed from minute one through minute thirty. In the next task after that, she put a 31 in the upper-left corner, as that task was scheduled to start on minute thirty-one. She estimated how long the second task would take and added that duration to 31, the number at the start of the second task, subtracted one, and put the resulting number in the upper-right corner of the second task box. So, for a task following the first one that would take three minutes, she had a 31 in the upper-left corner of that task and a 33 in the upper-right corner of the task (31 plus 3, minus one equals 33). Abby’s décor team would spend minutes 31, 32, and 33 inspecting tables, so that’s why a three-minute task starts at the beginning of minute 31 of the schedule and finishes at the end of minute 33. Performing these calculations similarly for all other tasks in Abby’s network diagram, Abby determined the earliest that all tasks could start using a technique known as the forward pass.

Abby completing the forward pass.

After completing the forward pass, Abby started to do the reverse of what she had completed, now performing a procedure called the backwards pass. As you might guess, Abby started at the very end of her sequence of tasks, on the far-right side of the chart. She had the number 108 (minutes) as the largest number in the upper-right corner of all final tasks on the right. This amount of time was the very soonest that all tasks could be finished.

Abby starting the backwards pass.

That same number was put in the lower-right corner of all three final tasks, as shown below. From that, she subtracted the duration of that task to get the number in the lower-left corner. Then, Abby went to the task boxes just before those final tasks. In the lower-right corner of those boxes, she added the same number as in the lower-left of the final task box, subtracting one. Next, she subtracted from that number the durations of all those second to last tasks, adding one, to figure out the number to put in the lower-left corner of those boxes, and so on [13]. For example, the “Set up food at pavilion” task ended at minute 108 and had a 30-minute duration, so the number in the lower-left box of that task would be 108 minus 30 and plus 1, or 79. Then a task just to the left of that, “Make and pack non-meat food”, would need to end at latest on minute 78 (79 minus 1). Since that task had a 45-minute duration, 78 minus 45 and plus 1 would be 34, so the latest that task could start without delaying the project would be minute 34. As shown in the figure just below, the “Make and pack non-meat food” task would not be able to start before minute 16 of work but needed to get started by minute 34 at the latest to get the project completed on time.

[13] Don’t worry, in the project management world, they use computer software to calculate all this quickly. It’s important to understand how the software works, though, so you can make sound evaluations and decisions based on what the software tells you.

Abby completing the backwards pass.

Abby continued this analysis for all the tasks in the network diagram. It was a lot of work and took her a while to complete, but she finally finished it and checked everything over in time for lunch. Once she had finished it, Abby knew which specific series of tasks would take the longest to complete and thus knew which tasks couldn’t be delayed if the project were to finish in the shortest time possible – she had found the critical path! Finally, Abby had a complete picture of what tasks had to get done without any delay at all, and which tasks could wait a little while if needed. She also understood how long of a wait was too long for any task if the party was to be ready on time.

Abby’s completed project network diagram – note the matching forward and backward pass numbers along the red critical path, where the float is always zero.

Abby now knew how much wiggle room, known as slack or float in project management, she had for tasks that weren’t on the critical path and thus didn’t have to be started as soon as possible. While some tasks can be delayed somewhat without delaying completion of the project, there is a limit to that. Once that limit is reached, a further delay in a task that’s not on the critical path can then cause a delay in finishing the project. Abby could now see how long any of the party’s tasks not on the critical path could be delayed before it would delay the completion of the project and cause the party to start late.

Now that the network diagram was complete, Abby could set the schedule for all the tasks to be done in the right sequence. Her friends knew what tasks they needed to do and when, as well as how long it was expected to take. With the scope of work and the work schedule both defined, Abby was ready to dive into the third primary domain of waterfall project management, developing a budget for the project.

Next post in the series: Making a Party out of Project Management: Chapter 4 - Paying for the Party - Part 1 of 2

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

               With the requirements and scope in mind, Abby was ready to start developing a project schedule for her team to use. Would they be able to fit all the scope they had planned into the time left before the party? If not, Abby would have to identify what would be the easiest thing to cut out of the party, but even that would be a hard task and she really didn’t want to do that. De-scoping a project is never easy, but especially when it would take away from the fun of something like a birthday party.

Abby had another thought as they reviewed all of their requirements to decide what to start working on, “We’ve got a lot of great ideas for what to do for the party, but how should we decide what to do first, second and so on to get everything done in the right order, and in time for Nathan’s birthday?”

This is where Abby realized she would need something called the schedule management plan. She would have a method to decide when to do what, which would ultimately lead to her getting the project schedule figured out. She and her friends would have to identify the activities they decided to do, what the right order of those activities would be and how long it would take to do the tasks in that order. With a schedule determined after all of that, Abby would then need to assign tasks to people to perform at their scheduled times.

To start the work of identifying all the detailed tasks to be done, Abby pulled up her work breakdown structure. Within the main categories of items for the party, there were some specific items to be included, but in order to make these items, there would be specific tasks that someone would have to perform. Abby and her friends examined each work package in the WBS to determine what would need to be done, who would need to do it and what resources they would need. What materials would they use? Would they need training on how to use the materials and tools to create the item? Whenever she could, Abby would close her eyes and visualize the task being done to help her best envision and identify everything that would be needed. For work that Abby could envision in detail, she made specific plans for how to get that work done. There were some things that were hard to know about exactly right now, and for those things, Abby typed up some general points to figure out in greater detail later; as Abby and her team got closer to when that work would be needed, they would have more knowledge about the specific work to do and would write more detailed plans closer to that time. This is called progressive elaboration, planning something in more and more detail as you get closer to doing it and learn more about how to do it.

After some hours of diligent, focused work, Abby and her friends finally finished detailing as much of the WBS into specific tasks as they could. They had a very long activity list, giving best guesses of the task durations as they went. Just like with the WBS, the detailed activities for each WBS work package were kept in organized groups, allowing Abby and her team to see how completing large sets of small tasks led to reaching the major milestones of the project, which are points when a major portion of the project work would be complete. For instance, the completion of all planning activities is a significant project milestone.

On regular work projects, milestones usually coincide with events called gate reviews or phase gates. This is where the project manager meets with the sponsor to report on how the project is going, so the sponsors know what’s going well or what may need to improve, and if they need to give the project manager help with those trouble areas. An example of a gate review would be Abby sitting down with her parents to show them the project plans before starting party setup or making purchases, such as supplies and party packages she might want to purchase from a party shop. If Abby’s parents evaluate her plans to be thorough and well developed, they will encourage her to make purchases and begin leading her team in performing setup activities. If not, they might ask her to consider making some updates to her plans and then having another discussion with them to get approval to move forward.

               With an activity list full of specific tasks, Abby needed to sequence the activities in a way that made sense. Different tasks for completing each requirement would have to happen at various times, and not everything could be done right away. Some tasks depended on other tasks getting done before they could start; this relationship is called a dependency. Luckily, Abby set up her requirements list to have a place for noting these dependencies, so she could use that to figure out the right sequence for getting the tasks done. Tasks required to get done first are called predecessors and tasks that come after those are called successors.

               Abby reviewed all the activities listed in the best order she and her friends could come up with. Now that they knew when all the activities would need to happen, Abby would assign an activity to one or more people, based on any special abilities they had and if they were available to do the activity at the time needed. With her resource calendar entered into the calendar app on her tablet, Abby was able to quickly see that most of the tasks could be easily assigned to people who would be skilled at doing them. There were a few, though, which she hoped to assign to a specific person because they had an ability to do the task especially well.

               “How long will each task take?”, Abby asked around. Going down the list, everyone who had done the individual task before offered a guess of the time it took. For a few tasks that none of her friends had done, some advice from her sponsors came in handy.

               “It’s really hard to tell how long it could take to decorate the tables,” Abby’s mom remarked. “Really, it depends on how fancy you want to make them. I recommend identifying what’s really important and what’s just pretty and nice to have. You may have to break the requirement for decorating the tables into two requirements in order to document that difference and just meet the simpler requirement if you run out of time.”

               “Thanks, Mom!” Abby cheerily replied. “That’ll be a nice way to give us some wiggle room in case we need it, but if everything goes smoothly, we still have something planned to make the party even better!”

That conversation with her mom got Abby thinking, “If we start with a more basic table arrangement and decide later that we want something fancier, what would be the full extent of making that change? We would have to buy extra materials, maybe the people making the fancier tables would need to be trained on a special skill like curling the ribbons or arranging flowers, and I would have to add extra time to the planned duration of setting each table.”

For now, Abby would just have her friends put a tablecloth over each table with a balloon anchored to the center of the table, but this was a good example of all the things she and her friends would have to consider for any changes they wanted to make on the project.

               Getting all the scheduling details figured out was a lot of work, and Abby was tired from working so hard on her plans all day. So, she took a break for the rest of the evening to eat some dinner and go watch a movie with her friends. Both of her parents were happy to see that as much as Abby cared about planning a great party for her little brother, she hadn’t forgotten the importance of some time away from work to have fun with friends and relax.

Next post in the series: Making a Party out of Project Management: Chapter 3 - Figuring Out the Details - Part 4 of 4

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

               The thought of the requirement to get the meat hot enough to be safe to eat stuck out in Abby’s mind as a definite risk to everyone’s safety, and it would really ruin the party if not successfully prevented. That would be a terrible way to remember Nathan’s 10^th birthday. Just the thought of it jolted Abby with a split second of fright.

               “This would be devastating to Nathan’s party…I need to make sure this doesn’t happen and also try to think ahead to anything else that could cause big problems.”

               Abby wanted to make sure that she and her friends would identify as many major risks as possible, as well as to find a way to deal with each one that they could. How might they go about this? Just like in other major parts of the project, Abby needed to figure out how she would do this part before she actually started working on it. What Abby needed was to create a risk management plan, which would help her to have a consistent way to identify and respond to risks that threatened the party’s success.

For the people dimension of risk, Abby reviewed her list of all the stakeholder groups involved with the party, including her project team. What were risks that each group faced, and what risks could each group pose to the party? Could the boys end up playing a little too close to the picnic tables and accidentally land a football in the potato salad five minutes before lunch was to start? Or knock a glass of punch off of a table and onto grandma’s dress? While not ready to focus on identifying as many risks as possible yet, a few ideas like this did start to enter Abby’s mind.

In addition to brainstorming with her friends, Abby knew her parents would be able to provide expert judgment based on their years of life experience and having thrown many of their own parties in the past. They could also review risk response ideas that Abby and her friends thought of and offer alternatives if they thought it would be worth mentioning. One thing Abby’s Dad recommended was to review the WBS and try to think of risks that could exist for each item on that.

               Abby gathered her friends together to discuss possible risks that the party had. She shared the project plans that they had developed so far, as many of them would be worth reviewing for not only identifying risks, but also noting limitations to how they could respond to those risks. They couldn’t spend infinite amounts of money and they only had a handful of days left until the party – those were two obvious limits. Also, they couldn’t work round the clock or obsess with everything being perfect. It would be a matter of optimizing between reducing risk and not working harder than it was worth. Once again, Abby had to use cost-benefit analysis, now to determine the best way to manage project risk.

But first, Abby decided that they should focus on just identifying risks; coming up with the solutions would be done after identifying those risks and analyzing them to determine which ones were most important. Together, she and her friends engaged in techniques also used in requirements gathering – brainstorming and the Delphi technique. They also tried to engage in some root cause analysis, examining specific risks as potential problems and looking for ways to prevent the problems from happening by addressing what would cause them. For example, they agreed they could have a real bee problem in the food line if a bunch of drinks and desserts were sitting out uncovered for very long. Why? Because the bees would be attracted to the smell of the sugar in those items. So, they noted this risk and decided they could address its root cause by putting plastic wrap over the containers.

               After some time of thinking through the planned events and the risks that could come from them, Abby and her team had a good starting list of risks to consider. Initial thoughts about risk responses were also recorded, though it wasn’t yet time to come up with detailed solutions. The result of this work was a document called the risk register, which recorded not only the risks but key features of each risk that would come in handy for the upcoming risk analysis. At this point, the stage was set for Abby and her team to size up the risks and deal with the most important ones.

Template for Abby’s risk register.

Abby’s risk register with risks identified and about to be analyzed.

               Now that Abby and her team had created an initial list of risks in the risk register, and they had noted certain attributes of each risk, it was time to review the risks as a whole and perform some analysis to figure out which ones deserved the earliest or closest attention. Could some risks be best mitigated by doing something now to prevent them or make them less likely to be realized? Would some risks become very problematic issues [11] if not addressed promptly or by a specific deadline? Are there any risks that can simply be accepted, as they aren’t very likely to happen and if they do, there won’t be much consequence? Qualitative risk analysis is the process of finding answers to questions like these, prioritizing the biggest risks and helping the team to manage them efficiently.

[11] An issue is a risk that has occurred; a risk might happen, and an issue has happened. There is a risk that you might fail a test if you don’t study for it ahead of time; that risk becomes an issue if you didn’t study and now you’ve failed the test.

               So, Abby and her team began analyzing the project risks that they identified and determining what they might do about them. They had a framework for how to respond to risks from the risk management plan, and they had a concrete list of risks to respond to. There would be different options for addressing each risk, and some options would be more suitable for a given risk than others. Since most of the risks were negative in nature, the team focused on risk response strategies used for those:

-        Avoid: Taking preventative action to keep a risk from happening, like holding the party inside to prevent some rain from spoiling the party.

-        Transfer: Hiring someone else to manage a risk and deal with it if it happens, like hiring a party shop to provide, set up and operate a bouncy castle, and promptly fixing air leaks if any are found.

-        Mitigate: Taking action to make a risk less likely or less consequential, although not entirely preventing it from being able to happen, like measuring food temperatures to reduce the risk of the food making anyone sick.

-        Accept: Doing nothing about the risk and hoping it doesn’t happen, like holding the party outside when it may or may not rain.

First, Abby and her friends reviewed each risk item and decided which of these four options to choose. Most risks they thought of really weren’t that big of a deal, so they decided to accept a majority of the risks and were comfortable with many of them happening. There was one risk they decided to accept even though it was significant, and that was holding the party in the park. Abby knew that Nathan loved having his birthday parties outdoors, and the benefit of him enjoying being outside outweighed the potential cost of holding the party at the park on a rainy day. She decided that they needed to do something about the other significant risks, though.

               Specific inputs help to provide context for analyzing the project’s risks. The risk management plan told Abby what information to include about each risk in the risk register, helping her to adequately define and categorize the risks as they were identified and added to the register. Another input is the project scope; knowing what will be done on a project and the context in which it is done allows the project team to better predict risks that could become issues or events that hamper the project’s success. Contextual (enterprise environmental) factors can also present risks, like rain impacting game options for the party.

               Abby’s mom stopped by the table for a moment to see if anyone needed anything, and to see how things were going. They told her about all that they were thinking about to keep risks from ruining the party.

               “That’s great that you thought of all that together. I can’t think of any additional risks off the top of my head that you should add,” said Abby’s mom. “There are a few things you should do before you call this done, though.”

               “Sure, Mom. What else do you think we should think about?”

               “Well, the first thing is to make sure you have good quality, relevant data for the risks you analyze. That’s great that you’ve got the weather forecast and checked a few years back to see what the weather was like at this time of year. If you were looking ten or twenty years back, that weather data probably wouldn’t help you predict the next week’s weather as well.”

               In the world of project management, this practice recommended by Abby’s mom can be called a risk data quality assessment.

               “I see that you have the risks organized by what part of the WBS they impact – that’s great!” she continued. “I was just about to recommend you do a risk categorization of some kind and then I saw that. Another way that is sometimes helpful is to organize risks by their root cause; then you know that by addressing the root cause, you’re preventing multiple risks from happening.”

               Abby’s mom pored over the list some more, “I’m glad to see you’ve done a risk urgency assessment to determine how time-sensitive it is to deal with each risk. Some risks have to be taken care of by tomorrow if you don’t want them to mess up the party, like ensuring you have the pavilion rental form and fee turned in to the city parks office on time. Great job there!”

               Like in many other parts of the project, expert judgment was important for helping Abby and her friends to size up the risks that the party faced. They used expert sources of information like the local health department’s website to confirm proper cooking temperatures for the foods, as well as their local news station’s weather forecast to assess the rain risk, instead of just guessing about these things. For example, they could have decided that the burgers would be done when their juices turn clear, but then they would feel terrible about anyone getting sick. So, they relied on the health department as an expert source and followed their recommendation to verify the temperature of the cooked food with a food thermometer. Referring to expert recommendations like this to ensure the appropriate quality standards are used to evaluate project work is called performing quality assurance. If someone were to ask Abby why her dad needed to cook the meat to 165° F, she could explain that she got that standard from knowledgeable experts at the local health department; it wasn’t just an arbitrarily chosen number.

               Going line by line through their risk register, Abby and her friends gave their best guesses about how likely a risk was to occur, and how much impact it would have on the party. Some risks they could research, like looking at historical weather records and the near-term forecast to decide the percent chance of rain. They assessed the impact of this risk as high; it would restrict the games that could be played and would cool the air enough that guests might get cold. Together, they spent an hour or so assessing the items and deciding which risks were worth still worrying about. Some, like the risk that the oven would stop working when Mom needed to bake the cake, were remote enough that they decided not to worry about it (they accepted the risk), especially when they could ask a neighbor for help if that did happen. It’s important to note that when a risk is accepted because it is considered minor, that should still be documented in the risk register for future reference, especially if that risk could become more threatening to project success later.

               Abby took a few minutes on her tablet to make a chart with the risk assessment they had just completed. Doing this made clear which risks would be most likely and problematic, thus focusing Abby and her friends on the biggest threats to the party. This chart is known as a probability and impact matrix. If it was forecasted to start raining during the party, that risk would have a fairly high likelihood (or probability) of happening, and it would of course have a high impact on the party, being outdoors at the park. A risk like this, with a high chance of occurring and high impact to the success of the project, is a top priority risk that requires very close monitoring and very thoughtful and effective risk response. Abby would be very smart to come up with a good plan for getting everything under cover ahead of time, instead of waiting until the rain started falling to figure out what to do.

Risk probability and impact matrix.

               In the course of identifying everything that could go wrong with the project, Abby and her friends also realized there were positive risks (sometimes called opportunities), which were things that might or might not happen but would be good for the project if they did. Strong winds would be problematic for blowing people’s plates and other items around, but a gentle breeze would be great for keeping the mosquitoes from biting the party guests. So, Abby and her friends noted that the right amount of wind could actually be helpful to a successful party, and that the occurrence of wind wasn’t inherently bad.

               There are four main strategies for maximizing positive risks on a project as well, and one of them (accepting the risk) is also one of the strategies for negative risks. While Abby and her friends accepted the positive breeze risk, here are ways they could have used the other three positive risk strategies, just for illustration:

-        Exploit: Abby and her friends could set up a few box fans along one side of the pavilion to ensure a steady breeze through it.

-        Enhance: Abby and her friends could set up a wind tunnel of tarps to make it more likely that the pavilion would receive a steady breeze during the party.

-        Share: They could have made a deal with the vendor that if he helped to set up the wind tunnel of tarps, he could go through the food line and take a break from his work to eat.

-        Accept: Doing nothing about the risk of a breeze and hoping it does happen, providing the party guests with a gentle and pleasant breeze while they eat.

               At the end of the qualitative risk analysis, Abby made a reminder to review the status of any high risks facing the project every day, and to check for any new high risks. That way, anything not going the right way could be dealt with before it became a huge problem. After all, Abby’s parents warned her in their discussion at the beginning of the project that it’s a lot easier to address risks as soon as they emerge instead of having to take drastic action at the last minute when the risks turn into issues.

Abby’s risk register with risk attributes filled in.

               To further prepare for the most important risks of the project, and to help Abby and her friends gauge the size of those risks, they needed to perform quantitative risk analysis. This would help them with planning risk responses, as they would have a better idea of how much money a risk could cost if realized, or when a risk would start to become an issue with an unacceptably high impact on the party. Performing quantitative risk analysis would require some of the same inputs as qualitative risk analysis (risk management plan, risk register, EEFs and OPAs), but would focus more on schedule and cost than the scope of the project; how much money will risk management likely cost, and how much time could be lost to a realized risk? Quantifying risks would come in handy soon when it would be time for Abby to put together the project schedule and the budget.

               As a starting point, Abby and her friends reviewed the risks that were the furthest to the upper right on their risk probability and impact matrix (presented earlier but also shown below for reference). They decided that three of these risks had quantifiable impacts; weather and food safety were really important to the party’s success, but it was hard to determine a monetary or schedule cost associated with those risks.

Risk probability and impact matrix with three quantifiable risks singled out for analysis.

               Abby and her friends reviewed the main risks from qualitative analysis to estimate the contingency reserve they should have for the project; this is an amount of money that should be budgeted on top of confirmed project costs, to fund various risk responses that might be needed during a project. Being aware of the risks but unable to pinpoint how much they would cost the project in total beforehand, these quantified risks were Abby’s known-unknowns. Costs for each quantified risk were estimated by noting the probability of the risk on the probability and impact matrix and multiplying that by the cost of that risk if it were to be realized. Some risks would happen and some wouldn’t, so the overall pool of money should be enough, or at least close to enough to fund any risk responses that end up being needed.

Quantified risk-impact spreadsheet with computation of contingency reserve for the three risks.

Abby felt reassured after they had figured out what to do about each of these risks. Sure, there might be more risks that could pop up, but at least now there was a very good chance that the party would go smoothly. In addition to deciding what to do about the negative risks, there was the positive risk mentioned earlier that could be used to the party’s advantage: if there was a slight breeze that wasn’t too strong, it could actually be nice to have enough wind to keep the bugs from bothering everyone while they were eating!

               As a result of all this risk analysis, Abby and her friends felt like they had a pretty good idea of what risks to keep track of for the time being. They recognized that they would need to review the risk register every day to ensure the big risks weren’t becoming issues and the small risks weren’t becoming big risks, but at least now they had specific things to focus on. Qualitative risk analysis helped them to make a smarter guess about how likely and consequential certain risks probably would be, and quantitative risk analysis helped to estimate how much money to budget for offsetting certain risks. It was also clearer how to manage risks through a step-by-step series of actions, starting with what responses Abby and her friends would need to take right away.

To wrap up risk assessments and planning for the time being, Abby went through her main project plans that she had so far and updated them based on what she and her friends were going to do about the project risks. She made notes in the schedule for any time-sensitive risks and identified how the big risks could affect stakeholders. Once all her project documentation was updated with the project’s risks and planned responses, she moved on to the next phase of planning.

Next post in the series: Making a Party out of Project Management: Chapter 3 - Figuring Out the Details - Part 3 of 4