PMI PMP Project Management Professional – Introducing Project Schedule Management
- Section Overview: Introducing Project Schedule Management
Welcome to this section on schedule management. Whenever we talk about schedule management, people get really excited. Well, maybe excited is not the right word, but they get very interested because it’s in this section that we’re going to talk about Float.
So yes, this is is where you want to be if you want to hop in and really nail down how to find Float, how to find the critical path. But that’s not the only thing we’re going to talk about. There’s a lot of other terms and things that you need to know when it comes to schedule management. So if you’re following along in the Pinback guide, this section on Schedule Management is chapter six in the Pinbox on Schedule Management. So we’re going to talk about, as always, trends and emerging practices in schedule management, some adaptive environment considerations.
We’ll talk about creating the schedule management plan, defining the activities and then doing some rolling wave planning. New term for you, creating the activity list, then a milestone list, how those two are related. And then we’re going to sequence the activities. We have to put the activities in the order in which they should happen and that will allow us to create a project network diagram. So setting us up for Float in the critical path. We need to consider though, two new terms that affect our scheduling and that’s leads and lags. So two new terms we’ll talk about in this section estimating activity durations. We have to know how long an activity is going to last in order to predict the critical path. So we need a duration on our activities.
Then we’ll develop the schedule. We’ll look at any constraints or assumptions that affects our schedule or may affect our decisions and scheduling. And then we get into Float schedule network analysis. So how to find Float? We’ll talk about that in this section, of course. And I have an assignment for you where you’re going to complete a Float network diagram and find Float. And then we’ll come back and talk about agile release planning, something you need to know for your exam, controlling the project schedule and then measuring project performance. So, a lot of information to talk about in this section. I know you’re eager to get to it, so let’s start that now. Go ahead and let’s go to the next lecture.
- Trends and Emerging Practices in Project Schedule Management
Let’s talk about some trends and emerging practices that you should be aware of for your exam. In light of project schedule management, we want to think about the different sizes of projects and how those different sizes of projects can have a different approach to scheduling. In smaller projects we can create a single single process out of the idea of defining the activities, sequencing the activities, doing duration, estimating for the activities and creating the schedule model.
So rather than making those distinct processes, those all kind of meld together in a smaller project, it’s kind of hard to do in a larger project. We also have to consider the time, the level of effort for knowledge management, for risk processes and any value added activities. So those are things that are in addition to our schedule model. So you may have some interruptions in the execution as far as cranking out the work because your team has to come and participate in risk identification and risk planning and any other project management activities where I need the team to serve as a subject matter expert.
Some other trends we need to talk about in emerging practices is this idea of iterative scheduling with a backlog. Typically we see this in an adaptive environment. The idea is we have a product backlog and then we select the activities that we can do for this iteration for this time box duration typically two to four weeks and then at the end of that we have incremental deliverables so we add value incrementally. It’s ideal for adaptive. We could do it in a hybrid or maybe a predictive, but typically adaptive or hybrid predictive is usually we plan out exactly when activities will take place and when requirements are created. This is an example of rolling wave planning that we plan and we do and we plan and we do.
So it makes these waves of planning and executing. Multiple teams could be doing the work. We just have to be careful that we don’t step over each other. So interconnected activities where these two activities are dependent on one another, we have to be aware of and plan accordingly or separate those from the two teams so it doesn’t get as cumbersome in our planning and in the execution. So this is an example of a sprint in an agile environment and we’ll look at that in a little bit more detail. Coming up. Another trend is to use a sign board or a Kanban system. Kanban is a way to show the work in progress or we call the whip. So you can see these little posting notes, these little sticky notes if you will.
They show the different user stories, the different requirements in each phase of the work that they’ll move through. So as you complete a user story, you move it to the next column all the way over till it reaches to done or published or whatever the last phase of your project may be. Lean Manufacturing is where we have a backlog of assignments, and then as team members become available, it goes to the next available team member.
So the assignments are just published to the next person. So it’s not as much planning where we’re going to choose who does what. This makes the assumption that the person that receives the assignment is capable of doing the work. So we want to be aware of that. In Lean Manufacturing, of course, we can tailor our schedule management processes, like all of the processes in the Pinbuck guide. So some things that we can schedule in regard to or tailor in regard to schedule management, the lifecycle approach. So we choose the most appropriate life cycle for our project, the resource availability. So what factors can we tailor or adjust when it comes to people and when it comes to materials or resources? So it’s just using some planning here to take advantage of when people are available or resources are available. And then what activities do we have that can fit with those resources? The project dimensions.
The project dimensions is just a way of describing the characteristics and the logistics, the complexity, any uncertainty. And there’s a term I like called product novelty. What’s the characteristics of the thing that you’re creating? How quickly can you do execution and then how will you track that? So all of those logistics about the project dimension and then the technology support, how will you support your schedule to develop it, to record it, to share it, and then make sure that we have a store, a storage location for the project model, that we don’t want multiple versions of our network diagram the project model. We want to be able to capture that and store it in one place. And then if it’s updated, we baseline it, we version it. And so we always make certain that we’re on the last version. But we need a system and approach to how we control that versioning and changes to the schedule model. All right, good job. Keep moving forward.
- Considerations for Adaptive Environments
In the last lecture we talked a little bit about adaptive environments. We talked about the idea of a product backlog and how that feeds activities into the iteration or into the next available or for the next available resource.
Let’s take a little bit more in-depth look. Now when it comes to scheduling in adaptive environments we know that an adaptive environment uses short iterations of work and in Agile we call those a sprint. So these sprints or short iterations are typically between two weeks and four weeks. This helps with quick feedback though in our review cycles it’s part of the plan when it comes to adaptive that we create the product and then we have the review, the retrospective of what worked and what didn’t work. We want to do this quickly and accurately and on a regular schedule because we don’t want to hold up the next iteration of the project. So we need to schedule that and have a cadence down of when do we do these retrospectives exactly? We have a prioritized backlog of requirements. That’s the product backlog. We’ve talked about grooming the backlog and the product owner and how those requirements are fed into the iteration. User stories are what we call the product backlog. Those items in the backlog remember the user story.
We talk about the role and the benefit and the motivation and what is the user story, what does it create, what does it satisfy? Of course, in an adaptive environment change is welcome, but change goes into the product backlog and it’s prioritized by the product owner and the project team. The project manager role in an adaptive environment takes on this idea of servant leadership where it’s different than a predictive where we are directing and telling the team what to do and we’re really kind of in charge. A servant leader is still in charge of the project but it’s not this almost autocratic role. It’s really the project team or facilitator. They make certain that the team has the items that they need. A phrase that we use in Agile or adaptive is this idea of carrying food and water for the team. We aren’t literally carrying food and water, but it’s a way of ensuring that the team has what they need in order to do the work, in order to get the work done. Now, in the Pinbach guide the project manager has the same role in an Agile or adaptive as we do in predictive.
So some of you may be a Scrub Master, a certified Scrub Master or some other adaptive certification. And that’s fine, that’s great. Just know there’s a small difference in the Pinback guide than what you may have learned in your certified Scrub Master course or in another adaptive certification. So we want to think about the project manager has the same role. So a Scrum Master is analogous to a project manager in the Pinbox. In an adaptive environment we have this idea of what’s to do. We have the whip, what’s in progress and what’s done. So this is the idea, just to be clear, of a Kanban board. It’s Kanban means sign board because it is it’s like a poster or a whiteboard that everybody can see. It’s very easy to see what’s to do, what’s in progress and what’s done. So a Kanban board, another term we want to be familiar with is the theory of constraints. The theory of constraints is based on a book called The Goal. It’s a pretty interesting book. After your exam, you should pick that book up and read it. The Theory of Constraints is where we examine the most limiting factor in our processes and then we want to improve that constraint so it’s no longer the most limiting factor.
So for example, if our most limiting factor is time, what can we do to address time so that it becomes more flexible, it being the constraint. And then that allows us then to look at now what’s the most limiting factor, and maybe that’s the budget or money. So then we examine all the attributes there for the budget and why is it the most limiting, and then we attack that and work on that and manage it more closely. So now it’s not the most limiting. Well, now it’s resources and so on. So it’s a scientific approach to improvement. This is the concept behind lean manufacturing and to some extent our lean in an agile environment, or lean in an adaptive environment, I should say. So, theory of Constraints you attack the most restrictive constraint. Let’s have a big picture here of an agile environment. So we have the product backlog. We’ve talked about that. It’s a prioritized list of requirements.
The product owner owns the product backlog. The team determines how many user stories it can take on based on what’s in the product backlogs. Remember, the requirements are prioritized, so the team gives points to those user stories. They only have so many points to spend in the current iteration that then identifies the tasks that we’ll do in the current sprint, the current iteration. So then we go into the time box duration, the sprint. Typically it’s two to four. It could be one to four. It can really be whatever you decide. But two to four is pretty typical. But one to four is not unrealistic. Once we’re in the sprint, there’s no new work during that sprint. So any changes that are wanted have to go into the product backlog.
They don’t touch the current work every 24 hours, the project manager or the scrub master, they work with the project team through a 15 minutes daily scrub meeting, sometimes called a stand up meeting because we all stand and you only talk if you are part of the team and the project manager. Then we go into the end of the sprint and we have some deliverables. We have increments that we can deliver and then that gives us an opportunity to do a Sprint review. So what worked in the Sprint? What did we create? And then the Sprint retrospective with the project team with what did work and what didn’t work, the Sprint review is an opportunity to think about, okay, what didn’t we get done on? How can we improve upon it? And the product owner may be involved in that. The Sprint retrospective is just the team. So what worked or what didn’t? How can we improve upon our Sprints? So that’s the big picture there with agile or an adaptive environment in this product backlog. All right, good job. I’ll see you in the next lecture.
- Creating the Schedule Management Plan
Our first process in schedule management is to create the schedule management plan. So we are planning schedule management. This is the plan that will tell us how we do the other processes in this knowledge area. So how will the schedule be defined, how will you manage the schedule, how it will be executed and how will it be controlled. That’s schedule management, the process. Let’s look at the Edo’s here for planning schedule management. We have the project charter, we have the project management plan which includes the scope management plan and the development approach. So predictive or adaptive and then we have some EEFs and Opus tools and techniques to create the schedule management plan.
Expert judgment, data analysis and meetings. And there’s only one output, but it’s a big output and that’s the schedule management plan. I want us to look at for a moment the enterprise environmental factors to create the schedule. Remember, enterprise environmental factors are like the policies, the rules that we follow in our organization. So they have a pretty big effect on how we create the schedule management plan. So we have to think about the organizational culture and the structure. So the culture is important because it’s like a person’s attitude towards work. If you’re in a volunteer environment where everybody’s a volunteer but you’re the project manager, it’s a little different attitude how you treat those volunteers than if you have employees and there’s an employer relationship that this is when you will do the work.
So the structure as well, if you’re in a matrix versus a project centrix, or if you are in a hybrid or a simple, there’s a whole different approach to how you do scheduling and different layers you have to go through when it comes to planning the schedule. We have to think about resource availability, when people will be available and when physical resources are available because that certainly affects our schedule. Now most likely you’ll be using some scheduling software like Microsoft Project or Primavera or Basecamp or whatever software that you like to use. But a software, your PMIs will help with the scheduling.
You might be using a commercial database to predict durations. A commercial database is a way of putting in the factors, putting in the types of resources, and that it will predict how long it takes. So in construction you might say you have 3000 sqft that you have to frame out or you have x amount of electrical jobs to do and then from that all those different factors that you have, it would predict how long it should take. So that’s a commercial database. What exactly do we get in the schedule management plan? Well, you get your schedule model development.
So how will you create the schedule model? The schedule model is the flow of your project activities, the actual activities in your activity list. It’s how do you get from the start of the project to the end of the project? So it’s that picture or the flow of the project work? What’s your level of accuracy? So plus or -10% or plus or -3%? So how accurate do you have to be when it comes to scheduling? What are your units of measure? Typically days on a smaller project, maybe hours and a big project, you might say weeks, typically days. What’s the organizational procedure? Links. So what’s the link when it comes to procurement? Or the link to talk to functional managers and get people on your team? Or the link to reserve resources, physical resources.
So those are all items that we have to define in a schedule management plan. How will the model be maintained? If you have a scope change, it’s probably going to affect the activities because you have to create that scope change and then it’s going to affect your schedule. So you want to go from a two bay garage to a three bay garage. So now we have new work to do, new activities that updates our schedule. Well, how will you maintain that schedule? What’s the process like? Will you do versioning or baselining? So you can’t just fire up Microsoft project and start adding stuff. There needs to be a way that you communicate that and capture that and see the before and after when a change happens. It’s also dealing with control thresholds that if we’re late, if our activities are late, at what point does it become an issue or a risk to our project?
So you have control thresholds, a percentage or in earn value management will do a schedule variance or a schedule performance index. So what’s the control threshold that signals you need to address what’s happening in the project as far as scheduling, what’s performance measurement like for your schedule? Are you doing your own value management? Are you just tracking actuals against what was planned? So schedule variance and then how will you report schedule? So this ties into our communications management plan in chapter ten of the Pinball, but we need a way to report scheduling. So you just say number of activities on time, number of activities in queue, in progress and complete. So what exactly are you reporting in regards to the schedule? All right, great job. Keep moving forward. I’ll see you in the next lecture.
- Defining the Project Activities
Once we have the project management plan created, in particular the schedule management plan, the subsidiary plan, then we can go about defining activities. This is to create the activities list, all of the activities that we have to do in order for the scope to be complete. So to define activities we’re talking about taking our work breakdown structure and the smallest item in the WBS is a work package and we’re correlating that work package to the activities that are needed in order to create the work package. So I need the WBS, I’m going to rely on the decomposition of scope to identify the work package and that allows me then to create the activity list. The activity list is really needed because it helps me estimate those are what I’m going to schedule and also to control the work. Along with our activities, we’ll define what are the activity attributes.
So each activity will have different attributes or characteristics that we want to be aware of. The milestone list shows all of the activities that lead up to creating that milestone. So recall typically at the end of a phase we get a milestone or you have a key deliverable in your project that’s a milestone. Well as far as activities go, we can see the activities that are needed in order to create that milestone. Let’s look at the edo’s for the activity list, our inputs, the PM plan in particular the schedule management plan and the scope baseline. Remember the scope baseline, scope statement, the work breakdown structure and the WBS dictionary and then we’ll have EEF and OPA, some tools and techniques here expert judgment, decomposition, rolling wave planning and meetings.
Our outputs will be the activity list, the activity attributes that milestone list we were just talking about, you could have change request, we might have updates to the project management plan, in particular your schedule baseline and your cost baseline could be an output here. Defining the project activities so the project work and project manager work. So there’s a difference here the project works we’re talking about the activities that will create the project scope. The project manager work, sometimes called loe level of effort are the activities that you have to do in order to manage the project. So quality control, the inspection, the creation of a report that’s PM work planning is PM work. While those are needed, they don’t necessarily contribute to the creation of the project scope. But often we still need to schedule those activities to make certain they happen.
So you might schedule quality control inspection after key deliverables or you might schedule when reports are to happen on a regular basis or when meetings happen on a regular basis in your project. So that’s project management work that doesn’t necessarily contribute to the scope, the creation of the product scope, other planning processes. So you think about in each one of our knowledge areas that takes time to plan. So you think about scope and cost quality planning for HR communications planning and risk will spend a lot of time in risk planning and then in procurement you may have some planning issues there in stakeholder engagement and planning is iterative so you’re never really done with planning until you finally go into closing. What about the procurement time and the sequence of activities?
So the sequence of activities we’re talking about, what order should these happen? So that helps us to create the schedule or at least the flow of the work, the procurement time we have to consider the lead time to purchase something. So I need these cabinets installed in 40 days from now. Procurement takes 30 days for it to happen to get the materials on site. So I have to think about 30 days from now I need the cabinet. So that affects my schedule. Internal and external events. So internal events could be things like resource availability, company holidays where resources are used at other projects or somebody’s taking a vacation. External events the weather laws and regulations the vendor has an issue with getting the materials. Those are really outside of your control. Known and unknown events. Known events we’re talking about risk that I know these things are going to happen.
Unknowns are no one knows that a project team member could quit in the middle of your project or the project could get canceled. May I have the money to put into the project to continue to fund it? So unknown events can obviously wreck your schedule. The decomposition of project activities we’re talking about taking the work packages in the WBS and then breaking those down into the work the activities to create the work packages. See in theory if we do the activities, we’re creating the work packages. If we complete all of the work packages then we’re completing that deliverable in the WBS. If we create all the WBS deliverables then we have satisfied the project scope. You satisfy the project scope, you’ve met the product scope and then your project is accepted. So that’s kind of the roll up of activities here.
There’s that little rule you ought to be familiar with called the 880 rule. When we decompose the work breakdown structure, we don’t want to get so granular that we just keep breaking things down or breaking things down all the way down to the screw that goes into a cabinet. We want to use a general rule here. It’s called a heuristic that we say between 8 hours and 80 hours. That’s how long each work package should take to create. So if it’s installing a doorknob, all right, that might take 2 hours, that’s a little too granular. We might just say install the door. Well, that might be 4 hours. So we might say install all the doors or complete the finishing for each room. So it’s just a way of sizing the work that needs to be done. It’s a general rule sometimes you might want to be very clear. We need a door, a special door that’s going to go into the laundry room. All right, so the 880 rule is just heuristic. So anything less than 8 hours in your activity list is too small. Anything greater than 80 hours, though, is too big.
So it’s just try to stay in that window between eight and 80 hours. The decomposed of project activities, three inputs that we really need. The scope baseline, because we’re talking about the WBS and the WBS dictionary and the scope statement, enterprise environmental factors, and OPA, that those are all things that we need to decompose project activities. Some other planning components to consider. We have control accounts and planning packages. I talked a little bit about this way back in the scope management. Let’s just have a clear definition here, a control account or a control account plan. It’s like a little marker in your WBS. So recall that I’m building a house for you. And in this example, we know we need a kitchen. I don’t need to know everything today for the kitchen deliverable, but I know that we need a kitchen.
And that kitchen is going to have a budget of 75,000, and most kitchens take us about a month to complete everything. So 75,000 and about a month of labor, not saying just one contiguous that much labor equates to 30 days. Well, you have to make decisions about what goes in to the kitchen. We have $75,000. So you have to decide what are the appliances, what’s the countertop, what’s the cabinets you would like, what’s the flooring. That’s all part of the kitchen. All of those decisions are planning packages. So planning packages, as you say, well, I want this countertop, and it’s going to cost $10,000. Well, that planning package is now worth $10,000, and we have $75,000. So you have 65,000 left to make decisions on appliances, on counters, on flooring, and so on. So it’s some accountability in that control account plan based on your choices will determine how we consume the budget and the time to actually make that happen. Now, there can be some issues that happen here with planning components.
For example, we have to know what type of countertops you want by December 1. So if you don’t tell me by December 1, then we’re going to be late, because I need to know, do you want a marble? Do you want granite? Do you want poured concrete? What’s the material or the type of countertops that you want? And we have to know by December 1, so you have deadlines. If you miss the deadline on the decision, then some of your choices might go away. All right, you’ve missed the deadline. You can’t do marble now because it takes too long. So now you have to choose one of these choices, or it could just be an issue that’s going to push the project. So those are planning components that affect scheduling. Great job. Keep moving forward.