PMI PMP Project Management Professional – Introducing Project Schedule Management Part 5

21. Using a Project Simulation

One of the fun things that you can do in project management is to play some what if games. So what if this activity gets done early or gets done late? How does that affect my schedule? So with a schedule network diagram and a piece of software, you can play some what if analysis. So basically you ask what if X happens in the project? So it helps you find some different outcomes, some different possibilities of outcomes. It helps you compute different outcomes and the most likely feasibility of your project schedule. You can do this most easily in your PMIs.

So a piece of software. There are some add ons, like to Excel. Or you can buy a standalone package that has what’s called a Monte Carlo analysis. Monte Carlo, it’s named after the world famous Monte Carlo games of chance and gambling hall and casinos is all of the different possibilities, like on the roulette wheel. So if you’re using a three-point estimate, optimistic, most likely pessimistic. You could say if these activities come in as optimistic and these come in on time and these come in pessimistic, what will that do to my project?

So you can place some what ifs and set some goals and some variations here. It’s also used in risk. So we’ll see this again in chapter eleven on risk management. It utilizes different things like you test your assumptions and constraints. Obviously, risk what if an issue happens and then it gives us a probability distribution. Let me show you.

This is a probability distribution. This is a Monte Carlo add on for Excel. So if you search the web, you could find this little tool, but it’s just a way of seeing the sample percentages and what’s the average, what’s the max? And it will build out a most likely scenario based on what you put into this worksheet. So this is one that someone has created, but you can also go out and buy some packages to add on to Excel that are a little bit more serious and project oriented. But this is a Monte Carlo example. So be aware of this for your exam. You’ll also see it in risk. It’s great for what if analysis. All right, good job. Keep moving forward.

22. Applying Duration Compression

Once we have created our network diagram and we know the critical path that tells us the earliest we could finish the project, we might be challenged, let’s say, by management or stakeholders to, well, can’t you get done faster? Can you compress the schedule? So we have developed the schedule, Joe. We have our milestone charts, we have our bar charts.

We have evidence of why the project is going to take so long. You can look at our network diagram, right, and see this is the flow of the work. But customers will often say, well, I really need it done faster, so I can’t necessarily work faster. But are there some things I can do to try to compress the overall duration? And there are two terms that deal with schedule compression. Crashing means you add more people, imagine they’re crashing into each other. So you crash the project, you add labor to get done faster. Crashing, though, increases cost. Crashing is also prone to the law of diminishing returns. You can’t just keep adding people and adding people and adding people to get done in five minutes, right? Work takes some amount of time to do, and we’re just going to get in each other’s way if you add too many people.

So crashing, you pay for the labor and it increases cost. Fast tracking is where you take phases or activities, but typically phases, and you allow entire phases to overlap. So fast tracking is increasing the risk. Have you ever seen, like, a football stadium being built? So over here it’s all mud and dirt and still under construction, but on the other side of the field, they already have the bleachers going up into the stands. So that is fast tracking. You have two phases that are overlapped because it’s such a huge project. Fast tracking, though, increases risk, because if we discover an error based on an earlier phase, it could affect that phase that’s overlapping, so it increases risk. You have to be much more cautious when we do fast tracking. Now, let’s talk about resource leveling heuristics. Resource leveling heuristics means we have a rule, a heuristic about how many hours a resource can be utilized in a time period. And typically we’re talking about people like 40 hours max.

So this little bar chart, this histogram, each different color you see there represents the amount of hours. One of our project team members, they’re working this week. So you can see that bright green one and that blue one and the turquoise one and so on. They’re well above our max, our heuristic of 40 hours. So we have to level that. We say, no, you can only work 40 hours max. So all that extra time then gets put on to next week. So they’re limited, they’re capped at 40 hours, where they could get all this work done this week in five days. But because we’ve limited it to 40 hours, our schedule is likely to increase because we can’t do as much effort in five days of duration. The effort is still the same.

It’s still the same amount of labor. It’s just not compressed. It’s going to take longer. So this is resource leveling. You have a heuristic. There’s a similar term called resource smoothing. Resource smoothing is where we keep the 40 hours max, but it only applies to activities that are not on the critical path. So we do smoothing on those activities that have float because we take advantage of that time to increase their overall duration. Those activities that are on the critical path, we generally allow people to work more time. If we’re doing smoothing, our goal is to adhere to the deadline in our project. So Leveling, everybody, regardless, 40 hours smoothing. Everybody, regardless, except for if you’re on a critical path activity. So know those terms for your exam. Leveling and smoothing. Keep going. You’re doing great. I’ll see you in the next lecture.

23. Agile Release Planning

Agile release planning is something that we do in an adaptive environment. It’s where we are creating a high-level summary of when we expect the product to be released. So we’re creating a schedule for our release. Typically every three to six months is what we’re aiming for here. We’re creating a roadmap and a vision and we’ll look at that in a moment. Moment. It helps also to determine the number of iterations or sprints that we’ll do in that three to six-month period and then how much needs to be developed in order to have a deliverable of value. So what’s our increment?

What’s our deliverable at the end of our three to six months? And then how long will it really take to have a releasable product? So let’s look at our product vision and release planning here. So at the top we have the product vision. The vision of the product is really what’s driving the roadmap. So yours is going to look totally different than this. Of course if you’re in Agile or Adaptive. So you can see we have the first release there. In our first release we have all of our iterations. So iteration one or zero if you subscribe to that like setting things up. But iteration zero all the way to iteration in however many iterations you can get done in three to six months.

So that’s our release plan of when we expect to have an iteration and when will that begin to create our deliverables. And you can see we have different releases. This is for the first release, then the second and the third across the top there. Our release plan feeds into our iteration plan. So each iteration, remember, is like two to four weeks. We do iterations of activities and that’s where we begin to schedule our development based on the user stories. And then that helps us create our tasks, the activities that we’ll do in that iteration.

So if you start at the bottom and you see like task D 12 hours, all of those tasks, those different hours are contributing to one user story. And then we have user story two and three and so on. Remember, user story is a requirement here. So all of those packaged up feed into iteration one. So in our release plan, the sum of x amount of iterations will equate to the first release. So this is a deep composition if you will, of when will you have a release, what does it take to get to the release? So it all adheres to the product vision. Release planning is when will the thing be released. Great job, keep moving forward. We’re almost done with this section. I know it’s a lot of material. You’re doing great. We’re almost done here with this section. Keep pressing forward.

24. Controlling the Project Schedule

Another process in project schedule management is control schedule. So we’ve planned it, we’ve done some executing and now we have to control. We want to ensure that the execution, the activities that are being done are being controlled and done properly. So control schedule in this process, we’re talking about schedule control and integrated change control, measuring performance. So it’s setting us up here for our next chapter where we’re going to see earned value management, looking for variances updating our schedule, doing corrective actions as needed and documenting what we’ve learned. So our lessons learned register our edo’s here for control schedule, our inputs. Obviously your project management plan will need our schedule management plan, our schedule baseline, our scope baseline, and our performance measurement baseline.

Remember the PMB, really it’s a combination of scope, time and cost baselines, project documents, the lessons learned, registered project calendars, the project schedule resource calendars and scheduled data. And then of course, we have work performance data. This is the raw facts about what’s happening with our activities. How many are done, how many are pending, how many are in motion, how many are late. That’s all work performance data. And we’ll have OPA tools and techniques to control schedule. We’ll do data analysis, we’ll use earned value analysis. We’re going to see that in chapter seven in the Pinbox, the very next section in this course, we’ll have an iteration burn down chart. We’re going to look at that. How many tasks are remaining? Performance reviews, trend analysis, variance analysis, what if scenario analysis, the critical path method, project management, information system, resource optimization and leads and lags, those are all tools and techniques we can do in control schedule.

Our outputs here will be our work performance information. We’ll take that data, we analyze it, and then we get information. We’ll do schedule forecasting, change request. You might have updates to your project management plan. So the schedule management plan, the baseline schedule and cost and performance and then we have updates to our documents, assumption log, basis of those estimates, lessons learned, register updates to your schedule, to your resource calendars, to the risk register, and then you’ll have some scheduled data that may have to be updated. When we talk about control schedule, we’re really talking about integrated change control. Recall that integrated change control is any change has to be examined for what effect does it have on the remainder of the project.

So what effect does it have on time, on cost, on quality, on scope, on HR, on communications, on risk procurement and stakeholders? So it’s the whole picture is integrated change control.

Part of integrated change control too, when it comes to controlling time is we want to influence the factors that create changes. A nice way of saying your project team and vendors, we want to reconsider schedule reserves. Have we put enough time back to account for things that may disrupt our project? Has the project schedule changed at all? And then do you manage changes as they occur? Yes. So when a change happens, if someone’s late, you look immediately at what does it do to your project? And you react to it. When there’s a problem, we always go immediately to the problem. Now, an Agile or schedule control is a little different. In Agile we’re looking at how much work was actually delivered in comparison to how much work did we say we could do? So remember the user stories and we have story points. If we say we can do 24 story points and that’s way too aggressive, we only get done with 15.

We need to adjust in our retrospective what worked and what didn’t work. Should we adjust the amount of story points we say we can get done? So that helps us reprioritize. Also in Agile, we determine the rate that deliverables are actually produced, the rate they’re validated and their acceptability. So that’s called velocity. It’s basically how fast can you get from creation to acceptance? Has the project schedule changed and Agile? If it has, then we have to manage that change. We have to figure out based on the number of resources we have or our deadline that may have been shifted. That affects the amount of work that we can do in that three to six month window for our release planning. So in Agile, typically we do accept change, but we also have to have some vision as to when the project’s going to end. Great job. Keep moving forward.

25. Measuring Project Performance

Of course, we’ll measure project performance often. As a project manager, we have a real good idea if our project is going well or not. Before your exam, we’ll need to have some insight into some techniques to measure project performance. So things like earn value management, which we’re going to look at in the next section. Schedule variance is one of our EVM tools. Schedule performance index just shows how healthy your schedule is. And then we have what’s called a TCPI, the two complete performance index, the likelihood to finish the project and meet your budget so you’ll learn all of those formulas. A little teaser for you in the next section. Corrective actions is something that we’ve talked about already in the course.

When it comes to our schedule, we want to see, well, what corrective actions can we do to make certain that activities are happening as scheduled? Make certain there’s as little delay as possible doing some root cause analysis when it comes to schedule variances. And then what measurements do we have to take to recover when we do have a delay? A burn down chart. We often see in an agile environment, a burn down chart is a way to identify basically how much more work do we have to do. And so the closer you get to the bottom, the closer you are to being done. So across the bottom, we have iteration days. So however many days are in your iteration, you would put across the bottom. And then on the y axis, we have work to be done. So there are, in this example, 400 tasks to be done. Pretty aggressive, just for an example here. So our burn down shows our target of when we should be done with those activities.

The dash line is our forecast based on what we’re experiencing now. And then you can see the little actual line that we’re drifting away from what was planned. So it’s a way to identify trends and where we likely to end up based on what’s happening in the project. So you’re burning down. You’re getting closer to the bottom, but then you can begin to see, is it shifting? And now it’s going to take longer than what we planned. So let’s respond to and control those changes. All right, good job. You’re almost done. Keep moving forward. I should say done with this section. All right, I’ll see you in the next lecture.

26. PMP Coach: Control Your Schedule

A ton of material right in this section on schedule management. I know there’s lots and lots of processes and terms here. It can seem a little bit overwhelming, but it’s really important for you to know these terms and to know how to apply these terms and your role as a project manager and for your PMP exam. So the information that we talked about in this section, what’s most important? I think what’s most important will be the terms. The terms will help you answer the questions. So if you understand the terms, you can answer the questions.

Don’t get bogged down and float. That’s a very tedious process, and it can take some time to draw all that out and to find the answer. So when you’re faced with one of those questions, what I encourage you to do is to read the question and to really understand what the question is asking, then immediately find the critical path. And often that can clue you in. And then use deductive reasoning and use process of elimination. So let’s say you’ve identified the critical path and the question says, well, how much days of flow can you use on activity G? If you use T two up on D? So now you would say, okay, well, D is not on the critical path, and neither is G.

So then I can compare the duration of the paths and see if any of those answers fit. It’s dangerous, though. Don’t always assume that it’s going to be the difference between the duration of a path and the critical path. You have to really examine a network diagram, but if none of those choices fit, then you know something’s not right in your math. So it gives you an opportunity to go back and check your math. Don’t overthink these questions. Most people spend way too much time on float in the network diagram and not enough time knowing the terms. There’ll be a lot more questions about terms than there will be on finding float. If you just can’t do it, if you just think it’s too tedious and you don’t like it, you’re not going to have 200 questions. I think it’s questions in your favor. You can always guess. Maybe you’ll guessed right, but I would spend more time learning the terms than I would be mastering how to do float. All right, so that’s my advice for you. Keep moving forward. You’re doing great, making great progress. Rest.

27. Section Wrap: Project Schedule Management

Great job finishing this section on project schedule management. Covered a lot of information in this section. I know the big thing that you learned about was float, about network analysis. And so that’s a question that I get from people all the time, is, does this course cover float? Well, now you know that it does. And you’ve got a good grasp on what is float and how do you do the forward pass and the backward pass. And that helps you find float in the critical path and so on. So you’ve got that mastered. Now, if you don’t go back and watch that section a couple more times, do some more assignments or exercises, create up your own, but you can do it. I have confidence in you that you can do it. That’s not the only thing we talked about in this section that was just the most popular.

We also looked at adaptive environments, trends and emerging practices, creating a schedule management plan. Then we talked about defining those activities. And then once we have those activities defined, that we can sequence the activities to create a network diagram. We looked at leads and lags. Once we have that network diagram created, we also need to know activity durations, how long will things last? So that that tells us how long our project is to last. That also helps us to develop the schedule and consider any constraints or assumptions that will affect our scheduling. And then we looked at float network analysis. We talked about controlling the project schedule, and then we talked about measuring project performance. And then I gave you a little coach here about controlling your schedule, that you want to be smart, but to some extent maybe a little aggressive. Don’t wait too long. Okay? Great job finishing this really big section here about project schedule management. Keep moving forward. I have confidence that you can do it. And I’ll see you in the next section.