Critical Path Modeling Using Microsoft Project: Lesson 3 – Leveling and Resolving Resource Conflicts Transcription

Please find below a transcription of the audio portion of Sam Bell’s course, Critical Path Modeling Using Microsoft Project (Lesson 3: Leveling and Resolving Resource Conflicts), being provided by MPUG for the convenience of our members. You may wish to use this transcript for the purposes of self-paced learning, searching for specific information, and/or performing a quick review of webinar content. There may be exclusions, such as those steps included in product demonstrations. You may watch the recording of this course lesson at your convenience.

Melanie: Hello. Melanie here with team MPUG. Welcome to Critical Path Modeling Using Microsoft Project, part three. Today, we are talking about leveling and resolving resource conflicts. We’ve had great interaction for the last two sessions with Sam. Thank you, audience, for participating. We invite you to join in with questions today. There is a chat/question feature in your control panel for GoToWebinar.

Melanie: You can pull that out and expand it if you’d like. Please get involved with those. We’ll also be doing a couple polls today. Your polls are completely anonymous, but will help all of us see where we are anonymously. I will be sending thank yous to our audience members today getting involved, please make sure I have your address in your MPUG account. Now I’d like to introduce our very excellent presenter and wonderful organizer of this event, Sam Bell. Sam, I’m going to hand the conn over to you.

Sam Bell: All right. Excellent. Hopefully you can see my screen now, Melanie.

Melanie: Yes, I can.

Sam Bell: Excellent. All right. Great. Well, thank you all for joining me this third lunch hour in a row. Really appreciate you taking the time out of your day to talk about a topic that’s near and dear to my heart. My name is Sam Bell. I’m the senior cybersecurity consultant and chief information security officer at Edwards Performance Solution. Been doing project management work for over 35 years. This is part three of an approach that I developed to help me survive managing large software projects.

Sam Bell: So example is withdrawing from that domain, as you all probably know by now, but the principles we’re applying here will work really for any project that you have to manage. So, just quickly to talk about where we are and where we’re going. Let’s just do a quick recap of what we’ve been over in the last two sessions. We talked about identifying different resource types and talking about resource groups as opposed to individual named resources when you’re doing your initial planning.

Sam Bell: We talked about using a modified standard calendar to establish the resource availability that takes into account holidays, sick time, and so forth, vacation and the like. We also to talked about using individual resource calendars to vary the availability of each type of resource that you’ve got. We also talked about work types, so fixed work and fixed duration and when to use each. We’re going to see that today in action.

Sam Bell: Then talking about the project plan structure and dependencies, basically keeping your predecessors at the same level in your hierarchy throughout your plan as well as the key predecessors as far up in the plan and as far left as you can within the project structure. Then we also talked a bit about support tasks and how to model common scenarios that usually are difficult to model using standard tracking mechanism.

Sam Bell: Today, we’re going to talk about the different leveling options available to you in Microsoft Project and talk about the whys, when, and how of project leveling and some of the different views that you can use as you go through the planning process and the resource allocation process. With that, I’d like to go ahead and throw out the first question, if we could, try to understand how many of the folks on the call actually do use resource leveling within Microsoft Project or if it’s used more as maybe a calendar type of scheduling type of thing.

Sam Bell: Resource leveling is something that maybe has been either scary or not used or not necessary for the way that you use Microsoft Project. It’d be interesting to get everybody’s sense of that.

Melanie: We are 70% voted. Okay. We had 27% say yes and 73% no.

Sam Bell: Excellent. Excellent. Well, that’s great. Hopefully, some of what you’ll hear today then will be useful to you and will get rid of some of the mysteries and the scary aspects of leveling. I, throughout my career, have had many folks, different project managers telling me leveling doesn’t work. I took that challenge and developed this approach to answer that and hopefully you’ll find it helpful for you all as well.

Sam Bell: Let’s talk a little bit about leveling, when you want to do it, and how and so forth, and just some general pieces about it. Once you’ve got your initial structure set up based upon all of the criteria we talked about in the last couple of sessions, you’re ready to level your plan, it is an iterative process. And it’s more iterative than what you’re going to see in today’s demo. Trying to keep the demo rather contained for everybody’s benefit here.

Sam Bell: You may find that there are a lot of iterations you’ll have to go through before you get a plan structure and resource curve that works for your particular project. And that’s okay. What I hope to show you here is some of the tools that are in project that will help you do that. You basically are going to change your plan, modify either your resources or your tasks to address any over/under allocations and then run leveling again.

Sam Bell: I like to take it in two approaches. First, focus on establishing the best project structure, and that really involves your use of summary task and task predecessors and successors. Then from there focus on shifting to your allocation of resources, because if your project structure isn’t clean and tight and neat, no matter how you play with the resources across that structure, you’re going to have some challenges leveling. So if you think in two chunks there, it can be very helpful as you work through the process.

Sam Bell: We’re going to talk about the resource leveling options now. Now, again, there are a lot of options within Microsoft Project for leveling. These are the ones that I have found work for me in this approach, not to say it’s the only way to use leveling. But for this approach, you definitely want to stick to these particular options. You’re going to notice the first thing is that we’re using ID-only leveling. This is really key because what this is allowing you to do is control the leveling process by how you order the tasks in your project plan.

Sam Bell: It really gives you a lot of granular control over when Project is going to try to assign resources to which task. The other types of leveling orders really don’t give you quite that flexibility and may give you a slightly tighter plan, but is harder to manage as you start iterating through your leveling option. The other thing we want to look at here too, is that for the most part, except when you’re doing multi-phase projects, which we’ll talk about in a bit, you do want to clear your leveling values before leveling.

Sam Bell: That wipes anything that you’ve done before clean and then starts fresh, not leaving anything from maybe a previous structure or whatever in place. You also want to look for allocations on a minute by minute basis. So as you have a task that takes 15 minutes, at the 16th minute, that resource is going to be able to then start the next task in their queue. Also, other thing here too, you don’t want to allow it to create splits in remaining work.

Sam Bell: Generally, splits happen when you’ve already started to track some percentage complete against the project and then you’re leveling. At this stage of the game, we really don’t want to have any resources with any percentage complete against it because this is all a forward-looking plan, so you’ll want to leave that off. So these are a couple of the options you want to make sure that you have set this way as you go through it.

Sam Bell: Now, there’s a couple of views, and we’ll see this in a minute, that you can use to really help you understand where you’re over and under-allocated and what you need to do either with your project plan structure or for getting new, additional resources on your plan to address the over-allocation. One of the views that I love is the Resource Graph view. I go to this often because it really gives me an idea of how tight my plan is and also which resource is the most constrained.

Sam Bell: In this case here, we can see in the resource graph a couple of key pieces I want to take away. The first thing you’ll note is that this black line here is the amount of the resource that’s available. We talked last time about setting resource availability and using that to determine the number of people that are on your project plan. In this case, you can see we have a resource availability that somewhere, beginning of April, we have now two business analyst resources that are available to us.

Sam Bell: Before that time period, we only have one, and hence in this case, we have an over-allocation that’s a result of it. So you see this and then you say, “Well, gee! What am I going to do about that?” Well, the next thing to look at from there is the Resource Usage view. This view takes each of the resources and then takes the tasks that they’re working on and cascades them down. And you can see the work that’s being done as well as the date that it’s being done.

Sam Bell: We can see here that we have an over-allocation because we really need about an analyst and a half in order to complete this work that’s scheduled in February, on the week of February the 20th, and right now, we presently only have one. You can then use that to tie back to, which tasks are the ones that are getting most clogged up, if you will, or most constrained? And then either rearrange the tasks, if that’s necessary, or get additional resources to resolve the over-allocation.

Sam Bell: So flipping back and forth between the Resource Graph view and the Resource Usage view, making some changes to your project plan, and then you’ll do that in the Gantt Chart view. I have a couple other views that I use here as well, but basically, this is probably the view most folks are familiar with where you have your task, your start, your stop, the amount of work, and then all the dependencies showing here. What’s really nice about the Gantt Chart view obviously is you can see the predecessors and successors.

Sam Bell: You can see how the work is being divvied up across the different resources, and by following these lines again, as we talked last time, you can get an idea of where the critical tasks are in the project and where you’re trying to optimize that work across your resource pool. All righty. Let’s just summarize real quick here. There’s one other view actually before we go on, and that’s the Constraint View. And you’ll see, I spend a lot of time in this view.

Sam Bell: One of the things that I think folks had asked for as well was, would you be able to download a copy of the project plan? We are making arrangements to have that project plan posted on our website. Melanie will be sending out the link when she sends out the closeout materials. It has some of these views in here, so you don’t have to add all the columns that you need and so forth. You’ll have these views in that sample that you can use as a template.

Sam Bell: But what I like about the Constraint View is you’re having all of your constraint dates there, the types and the dates, right in line with the amount of work, your start, your finish, as well as priority and your predecessors and successors. Also, if you put this screen down the bottom with your predecessors and successors, you can see that when you’ve selected a given summary task, or any task for that matter, you can see what its predecessors are and what its successors are without having to scroll up and down the plan.

Sam Bell: So this, again, really switching back and forth between these several views, help you identify where you’re under-resourced or where maybe your task sequencing is gumming up the works and causing you to have over-allocation of resources while you’re there. I guess before I open up the plan, I guess I’ll stop for any questions that anybody has, if there are any.

Melanie: No questions yet, Sam.

Sam Bell: All righty. Great. Let’s quickly just do a quick summary then. Before we go into the plan, always looking for over-allocations minute by minute. We’re doing ID-only leveling order in order to give us maximum control over what Project is doing when. You don’t want to let it split tasks, unless you absolutely have to. We can talk later if there are questions about what to do if you’re midway down the project and you’re trying to do this type of approach.

Sam Bell: Using the Resource Graph, the Resource Sheet, and the Gantt Chart views to really, back and forth, to identify where your constraints are and resolve any sequences that don’t make any sense, make sure that you don’t have any gaps in the plan, and making sure that you understand all the resources and how they’re being allocated across the plan. Now let me open up Microsoft Project and we hopefully get the right one here. Okay. Hopefully you all are seeing my project plan here now.

Melanie: It’s up.

Sam Bell: We’ll start off here. All righty. Great. As I was saying before, this is the Constraint View that I’m real fan of using here. I call it task sheet with constraints. I like him because I don’t have the Gantt Chart over here, but also it gives me, as I say, the constraint and the date and the type as well as information, my overall project cost, and so forth, predecessor, successors, and the resources that are being allocated across the plan.

Sam Bell: And of course, as you can see here, what am I dependent upon and what’s dependent upon the tasks that I’ve got highlighted here? So let’s just walk through this approach here and just take a little look at, all right, if I was looking at this plan, how would I figure out if I’m healthy? What’s this thing look like? The first place I would go after I have a structure that I think looks right is I would go to my Resource Graph and I would start to look at the resources that I have allocated across the plan.

Sam Bell: You can see here now we’ve got one developer cranking at 100%, so one person doing the whole length of the project here. But if we look at our business analyst resource right now, we have a couple things going on that probably are less than ideal. The first one is you can see we’ve got an analyst resource here. Ostensibly, they are doing test requirements creation here. Again, this is a software project by sample. Then down the end here, this is where they’re doing all the test case execution and turnover to the application support teams.

Sam Bell: But you’ll notice here that we’ve also got this huge gap that’s in the middle here. Now, those of you who’ve worked in matrixed environments know the first thing that happens when you have a gap like this and you go to your management, they say, “Well, who do you have available?” And, oh gosh, all of a sudden now, I’m going to give up my business analyst and hope that I get them back into September to continue testing. We all know that that doesn’t necessarily work well.

Sam Bell: We also know that invariably while development is happening, there is some support time that’s necessary to make sure that if there’s any questions about the requirements, if the requirements need to be updated based upon how things actually have to be built and so forth, there’s a lot of support work that has to be done there. So how do we go ahead and model that? What we’ll do is we’re going to go back to our Constraint View and we’re going to go down to that task.

Sam Bell: If we get down here, what we’ll see is where we don’t have any work going on is this period from 3:16 to 9:16, because right now we don’t have a business analyst resource on this at all. So I would always argue that you’re probably going to need at least four hours of support a week from somebody on a project like this. So I’m going to go ahead and model that. Now, if we now go back to our Resource Graph view and take a look at our business analyst resource, you can see now we’ve filled in the gap and now we’ve modeled that that analyst needs to be here.

Sam Bell: I need to be counting on them spending about four hours a week, I need to make sure that that’s in my project cost as well, and I need to make sure that nobody takes that analyst off my project while I’m running things until we’re ready to get into the test phase. But you notice here that we’re still over-allocated on the resources themselves, okay? What we’re going to do instead is we’re going to go ahead and we’re going to level the plan. Now, let’s just pull up our leveling options.

Sam Bell: You can see we have minute-by-minute clear values leveling the entire project. We’re going to go ahead and we’re going to level this, hit Level All, and we’re going to see we have an over-allocation here. So what’s happening here? Well, when we take a look at this, we’ve got to slide out over-allocation around October 2nd. If we now go into the Resource Usage view… Oh, sorry. We can see then that that over-allocation… There’s a better view that will show this.

Sam Bell: Sorry. There we go. This guy should show a little bit better. We can see we have an over-allocation on the BA resource. If we scroll over here, we can see here that we have a certain period of time where they’re booked a little heavy, they actually have a little extra support. And we can see here that that’s basically from a support task that we have here between development and integration. Now, chances are in reality I would probably just zero out this 1.2 hours in order to make it go away.

Sam Bell: But just for sake of argument, what we’re going to do instead is let’s just say we want the project to go a little bit faster. Let’s go back to our Resource Graph view. Now let’s go ahead. We can just click on this and we also can get the resource availability page as well. Let’s go ahead and just crank up our number of business analysts to two analysts starting in April. So anytime in April, we know we have some extra availability.

Sam Bell: Now what you’ll see, even without leveling, a couple things happen. We’ve resolved this over-allocation. And again, you can see this black line here comes up and you can see now that it’s showing the amount of BA resource that’s available on our project. Okay. But now this thing is still taking too long and we’re saying, “Gosh! We really would like to get this down a little bit faster. Where am I constrained?” Well, as I start scrolling across my resources, I can see that my real constraint here is my development resource.

Sam Bell: So what happens if I decide to put more resources, another developer on the project? Before I do that, let’s go up to our Task Sheet with Constraint View and let’s just make a note here that we’re looking at about 262,450. Now, if we come back to our Resource Sheet again, go to our Developer Resource. There’s a lot of ways you can get to the same screen here. You’ll notice this time I clicked on the Resource Sheet itself. Let’s go ahead and crank that up to 200%.

Sam Bell: Well, now that I’ve cranked it up to 200%, you can see though I haven’t changed the duration. Why? Because I haven’t leveled the plan. Now all I have to do is come in here and level the plan again, and all of a sudden now, all these tasks come in and then we get a much prettier curve. The nice thing to see here too, though, is look what happens to my business analyst resource. Now, automatically because of that automatically growing and shrinking task that we created, those with the start-start and the finish-finish dependencies as milestones under a summary task, this has automatically changed without me having to touch my project plan at all.

Sam Bell: But what’s interesting is, if we take a look at this, if we come back to our Task Sheet with Constraints View, adding two developers does not make it go twice as fast nor does it make it cost half as much. You can see we’ve only dropped the price about $25,000 or so. So we can come back again and we can do the same thing again. Come back to our Resource Sheet again, let’s go to another developer, let’s crank them up and say, “Well, gosh! If we had three people, it’s got to happen faster than that.”

Sam Bell: We’ll level all, we’ll come back to our Task Sheet with constraints, and lo and behold, yeah, we’ve shortened it a little bit, but not even anywhere near as much as the first person did. So we can see we’re getting to a point of diminishing returns. If we look at our Resource Graph and we look for our developer resource now, you can see how that pans out.

Sam Bell: That’s because as the work has been laid out, since the work is being dished out and there aren’t any dependencies there that aren’t true dependencies for the work, when some work finishes and the next phase hasn’t started, we don’t get a full resource utilization across the board. But the thing I think you can see from this is this really gives you the flexibility to play with different resource curves across your project plan and see what kinds of dates you can get and whatnot and how adding additional resources to a project plan will save you time and at what point if you’re not going to save any more time by putting more people on a project.

Sam Bell: I am going to stop and take a breath for a second. Melanie, I’ll throw out there now. Maybe there’s a question or two now.

Melanie: We do not have any questions yet.

Sam Bell: Okay. All right. Well, then we’ll keep going. Let’s talk through this just a bit more and talk about some other scenarios here that you might have. Sometimes-

Melanie: Sam?

Sam Bell: Yes, ma’am.

Melanie: Not to interrupt you, but a question just came in if you’d like to tackle it. Can you show how you might work with teams, dev one team, dev two team?

Sam Bell: Yeah. Essentially, you have dev one team, dev two team, are they different skill sets? Because if they’re not different skill sets, I would just say create a developer pool with a total number of developers that you have. If you have a team one and a team two, you could basically make one resource dev team one and another one dev team two. And if that one team has five members and one team has three members, one would have 500% availability, the other would have 300% availability.

Sam Bell: You could certainly do that and then lay those teams across your project plan. Now, what I might suggest doing, and we’ll talk about this in the last slide, is to start with, to try to understand, how tight can I really make the plan before the team structure constrains my plan? I might start with a grouped pool of… Let’s say there’s five and five, right? I might start with a group pool of 10 resources if they’re all the same skillset, see how tight I can get the plan, and then come back through and assign that work into dev team one and dev team two as a second slice.

Sam Bell: I’ll talk about adding named resources to project plans in the last slide here. By doing that two-step approach, that will let you not have the effect of the team structure give you an artificially long project plan out of the gate. You can at least get a sense as to how tight your plan can be and then see how much longer does it get by chopping it up across two different teams. Hopefully that answered the question.

Melanie: Tim, let us know if that does and we can keep going. We have a couple more questions. He said thanks and I agree with him.

Sam Bell: Brilliant.

Melanie: George asks, what is the reason for using ID only?

Sam Bell: Well, truthfully, the honest answer is I found it worked, I’ll be honest with you. Because ID only essentially says, “Start at the top of my plan and assign resources going down in order,” and I like that. I have a bit of a programming background, not that I program for a living. But I like that, that’s just appealed to my programmer brain, if you will, because I could then think of, okay, “If I do it in ID order, I then can control what work gets done when by doing that.”

Sam Bell: We’re going to see an example in a second as to how that really plays for you, especially if you want to do a multi-phase project, which we’ll talk about in a second. Other than it works, and the same thing with putting the predecessors on summary tests instead of on detail tasks, again, I came across this approach because I found that it worked. I think if you play with it a bit and after you play around with the project plan and download it and play with it, I think you’ll start to see some of the benefits there and hopefully you’ll even see it as we talk about multi-phase projects.

Melanie: We’re rolling in questions here now. So if you’re ready, I have more.

Sam Bell: Brilliant. Oh yeah.

Melanie: Mike asks, “How do you feel about leveling individual resources versus the whole project?”

Sam Bell: Well, I like to be as lazy as possible and just level the project, but what you do find, and we’re going to talk about this phase, leveling, sometimes you do have to level in chunks. Sometimes you may find, especially if you’re in a very resource-constrained project, you may find you will have to level your most resource-constrained project, your most resource-constrained tasks first, and then flow everybody else across them or some other strategy. It really is. It’s just going to depend upon what the resource availability is there.

Melanie: Okay. Another question from Tim. “Can you assign resource based upon task priority?”

Sam Bell: Resources based upon task priority? I’m not sure if I’m following your question because I don’t think you’re talking about using the priority field. What I would argue is, task priority, that again comes back to the ID-only leveling. By using ID only, you basically are saying the orders that I put the tasks in my plan is my priority, if you will, and then I want you to assign resources across that from there. Again, you can if you want to level in chunks or level certain resources first and certain tasks first. You can do that.

Sam Bell: Depending upon the complexity of your project, you may need to do that. But I would argue that you might want to try first restructuring the plan, because if you got the right project plan structure, you shouldn’t have to do a whole lot of back and forth playing with individual resource assignments. You should just be able to push the button and it works. But I recognize that doesn’t work in all cases, and especially not in the case of multi-phase plans.

Melanie: Well, he said that-

Sam Bell: I can show you the technique of that.

Melanie: He said that-

Sam Bell: I’m sorry.

Melanie: … he could make that work. So that’s a great answer. We have another one here. “How far into the rabbit hole of the Priority do you go to adjust leveling?”

Sam Bell: Okay. And I’ll talk about Priority. I assume now you’re talking about the priority field now. I use the Priority field in a binary fashion, and I’ll show you that momentarily. I basically use it to either lock tasks or let tasks float. I’m, again, not really doing a whole lot of scaling on that, because again, my approach is to use the ID and the project structure to drive a lot of that so that you don’t have to use the Priority number to do that.

Sam Bell: And again, I think this will make a little more sense when we get to the multi-phase example in a second. I’m sorry I keep holding out on that multi-phase example, but I think with the Priority piece, if I follow where y’all are going, I think my sense is is that you’ve been using Priority in order to help with making sure the most important task got done first and I’m just basically swapping that out with the sequence on the plan.

Melanie: Yeah. And he was using Priority number to adjust that. Okay.

Sam Bell: I’ll show you a different way to play with that on the multi-phase example in a second.

Melanie: Thank you. That’s all the questions for now.

Sam Bell: Okay. All right.

Melanie: Thank you, all, again.

Sam Bell: Thanks, guys. This is great. These are all really great questions. I’m learning a lot as well in terms of the different ways that folks are using Project and using the different features of Project in order to navigate getting things prioritized the way that you want to. So I’m finding the questions as informative as anything. So this is great stuff. All right. So let’s talk about step-by-step leveling from here.

Sam Bell: We’re going to go through this in a minute, but I basically use the Priority field in a binary fashion, if you will. The range is from one to 1,000. 500 is the default and 1,000 locks tasks. Essentially, for my approach here, I try to just basically use 500 and 1,000. I use them in a step-by-step approach as I work down through my plan in order to do the leveling. From that sense, I’ll be changing the Priority as I work through this leveling, this step-by-step leveling process.

Sam Bell: It’s not like I just set a Priority number and leave it there. But we’ll talk about what that looks like and see what that looks like in a moment. You’re going to basically want to work top-down through the plan, and then once you’ve got that section tight, lock the dates by setting your Priority to 1,000. Then the one change you will make, and I had mentioned this before, was the check leveling values before leveling in the Leveling Options.

Sam Bell: That will be something after you’ve done the first slice, you’ll uncheck that to make sure that the initial leveling stays in place and then the other tasks start to feed in below that. One of the things I always get myself in trouble with when doing it would be to lock up my roll-up tasks. You don’t want to lock those because that can give you some really goofy results. Then rinse and repeat as needed. This is something that there will be a lot of rinse and repeat as needed here to work your way through it.

Sam Bell: Let’s take a look at what that looks like in practice. All right. Now I have a bit of an ugly multi-phase project here. Basically, what we’ve got here is we’ve got a multi-phase project. You’ll see we have phase one. And all I did was copy phase one and duplicate it and call it phase two. You’ll see here that, again, when we talk about the hierarchy and the indentation of things, both of these are at the same indentation level. And since we’re using ID order only, it’s going to try to level what’s in this chunk first and then come down and level this second.

Sam Bell: But what I’m going to do in order to make sure that that actually happens the way I wanted to is I… For right now, I have put a start, no earlier date constraint in here, and a day to year out in the future to say, “Okay, right now, push phase two all the way out,” and hopefully it won’t be in my way. From the examples we’ve seen, we know that the project plan, even with only one resource, won’t run into ’23.

Sam Bell: So what we’re going to do is, for all the tasks that are inside of phase two, they’re set at 1,000, and for all the tasks that are in phase one as well as these summary tasks that roll across the entire project, they’re all going to be set to 500. Before we begin anything, let’s just try to get a sense as to what does our resource curve look like around this thing? What’s our resource usage look like? Is there any opportunity to tighten things up a little bit as we go through the project plan and what’s that all look like?

Sam Bell: Oh, sorry. We’ll look at the Resource Graph for that. As we come up here now, and you can see we’ve pushed some things out, so we have this project starts out, we’ve got that three developers that we left on our plan, and we have the work cranking out through the year. We then see basically it’s the same chunk of work, only we have it starting in ’23 instead. And yeah, we’re way over-allocated out here because we didn’t worry about trying to make these dates work right now.

Sam Bell: So what we’re going to go ahead and do, and let’s take a look at our business analyst resource also. It’s our business analyst resource. Again, we can see the same pattern that we saw from the last example here. Then of course, it’s repeated again, but of course some over-allocations because we haven’t tried the second chunk of work. Now let’s come back into our Task Sheet with Constraint View. All right. We’re going to go ahead and level all.

Sam Bell: And actually, now if we go back and we look at our Resource Graph, we can see we still have some things… Well, these guys didn’t move, but everything else is nice and tight. Now what we want to do is we want to come back to our Constraint View, or any one of the Task Sheet views, and we’re going to take this guy and change him to 1,000. We’ll go ahead and we’ll just scroll that all the way down. Sorry guys for all the bounciness. Then for phase two, now we’ll take all those and make them 500.

Sam Bell: Whoops! A little too far. All righty. Then what we’re going to do now is we’ll come back in here and we’ll level all again. If we come back to our Resource Graphs, let’s see how tight we are now. Well, we’ve got some dev resource over-allocated here like crazy. That didn’t give us exactly what we wanted there. So let’s go back now. Same Task Sheet with view and let’s just go ahead. Now we’re going to go ahead and let these guys float as well.

Sam Bell: And you have to play with this. Sometimes, this will behave in interesting ways. Again, it is very much an iterative process that you have to go through. But now if we hit Level All again and we come back to our Resource Graph, now we can see our developer resource is all the way tight, but what did we forget to do? Forgot to remove that constraint on the phase two work. Apologize for the scroll. He’s there, so we’re just going to make him as soon as possible.

Sam Bell: We’ll level all again, kills that over-allocations, then we go into our Resource Graphs again to see how we’re doing. Now we see that the work from phase two has filled in as many of the gaps as possible into the phase one work as well. While we get a couple of weeks where we maybe get a couple of dependencies hanging out there, we get a plan that’s fairly tight and that works within the amount of resources that we have. And we can come back to our Constraint View and then we can see, all right, at a summary level, all right, phase one’s going to wrap up around 8:19, phase two will wrap up around 11:29.

Sam Bell: And again, the thing to note here is, because we have these what I like to call growy, shrinky tasks or self-adjusting tasks, or whatever you care to call them, the two milestones with a start-start and a finish-finish, all of our project lead time, project management time, is automatically growing and shrinking according to the needs of the project regardless of how your resource is spread across the entire project. So this, I will say, and as you’ve even observed here in this example here, is a bit of a black art.

Sam Bell: So I would say that it’s a lot of playing around. I would definitely recommend save often as you go back through and as you’re doing this. Before you start doing a step-by-step leveling, save off a copy before you start playing around with it, just in case you get things really crazy you have somewhere to go back to at the end of the day. Now one last tip and let’s talk about your team one, team two, or even if you’re trying to assign Abby, Sue and Frank to a project.

Sam Bell: Assigning named resources obviously is the next thing on your plan because you want to make sure that you’ve got folks that are actually accountable for the tasks and that there’s not a question of who has that work. But doing a named resource assigning to a plan that has already been leveled is much, much easier than doing it to a plan from the outset where you’re trying to start off with Abby, Sue, and Frank across all the different tasks.

Sam Bell: So you want to also make sure that as you set up these resources, that they’re using the same calendars that you used to build your base project. If they’re not for whatever reason, understand that that’s going to make impacts to your overall project schedule. Again, then you want to proceed top-down, same way we did for multi-phase leveling here, assigning named resources and re-leveling as you need.

Sam Bell: Then you can obviously use Priority field to lock the project plan in chunks and to give you that more granular control of leveling if you find that things are squirreling around on you. You don’t need to use the Priority field for this unless you need to use the Priority field for this, if that makes any sense. In other words, I would start without trying to use Priority issue doing named resources. That’s just a good last way to lock tasks and to do things in chunks if you need to.

Sam Bell: Then the last thing I want to call out is the use of specialized calendars. We mentioned this ways back. But if you have activities that can only happen on certain days, let’s say there’s a change control meeting that has to happen on Tuesday and your change has to be represented on that meeting and then it’s pushed on the following Thursday, well, that kind of scenario can very easily be handled with calendars that have specific dates.

Sam Bell: In fact, actually our sample plan, I think, has a deployment calendar that only deploys on Tuesdays and Thursdays. Having that in your pocket there, that makes sure that your plan is going to align to the dates that your organization requires externally without having to remember to track those dates or put them on your plan if you know that it’s the dependency of another team or a set meeting or something along those lines. So, just a couple of tricks there in that space.

Sam Bell: All right. So a quick walkthrough, what we talked through today. From a leveling perspective, this approach really relies on using ID-only leveling order, doing things minute by minute, and using Resource Graphs and Resource Sheets to understand where your over-allocations are in the work that’s being done there. Then also using the Gantt Chart view or the Constraints view to identify where you’ve got tasks that maybe you’re split or things that just don’t make sense, sequences that aren’t right, or if you’ve got gaps in the work that just don’t seem to make sense.

Sam Bell: Sometimes they show out best in the Gantt Chart view. Use that Constraint view for planning because it gives you all those fields you need and a nice, tight, and tidy view. Step-by-step leveling helping you with multi-phase projects to make sure that the work gets done in the appropriate order and that the first phase’s work is prioritized over the second’s. Then of course the use of the Priority field to lock down your plan and to give you more granular control of your leveling as you work through things. With that, that’s our summary. I guess I’ll throw it out for any questions that anybody has out to the group.

Melanie: We have some great questions.

Sam Bell: Excellent.

Melanie: Okay. From Joseph, “Do you consider the as central as possible approach when developing a schedule? In other words, make initial tasks constraint type as late as possible and later task as early as possible to keep the majority of work in the middle of the project?”

Sam Bell: Well, I’ve always come from an environment where they’re, “How cheap can we do it and how fast?” So, all mine have always been as soon as possible, because again, if you have the right project plan structure, when you do your leveling, it’s going to smooth all that work out for you. I mean, essentially, that’s what you’ve seen today with the developer curve where we went from 100% to 200% to 300% just by changing that percentage.

Sam Bell: That does all of that for you and structuring the plan this way does that for you so you don’t have to make them as late as possibles or early as possibles. I mean, I would say you only want to use those types of constraint types if it actually models the work the way you want it to be done. As an example, maybe if you are writing up a technical document and you want to wait until you’ve done your first deployment or get as close to your first deployment before you write that technical document, I could see that might be a good use case for using as late as possible.

Sam Bell: But just to get your project plan to work, I would always use as soon as possible and then play with your resources and your dependencies and your indentation and project structure in order to drive the allocation across your plan.

Melanie: Thank you for that. So do you prefer the SS, FF, growy shrinky task versus setting up the hammock task and cut pasting special to begin end dates?

Sam Bell: I have to confess, I’m not familiar with the term hammock task.

Melanie: Okay. So let’s see.

Sam Bell: So I apologize there. But basically, those start-start, finish-finishes, I have found has been a great way to model those tasks where you need to have resources on a plan and it’s really the structure of the work that’s going to drive what that period of time is. And I find in most cases that is things like support during development and those types of things where there’s not a specific task you’re doing, but yet you know you’re going to need to have folks that are working and engaged on the project to do documentation and to keep things in sync.

Melanie: Thank you.

Sam Bell: I hope that answers the question because I don’t… I’m going to have to look up hammock task now.

Melanie: How do you handle task where resources assigned, say for 20 hours of work over a three-month duration, and then as that duration changes, the hours automatically increase to full hours versus keeping the 40 hours for the task?

Sam Bell: Used fixed work, not fixed units. Fixed units winds up growing and shrinking the number of hours on the task because their assumption is, “Oh, well, if it’s going to go longer, we need to have more people still working on this.” You want to use fixed work, because fixed work is the guy that says, “Okay, if I get 10 people working on that… ” Assuming you can do that, right? “If I put 10 people on it, they can knock it out?” And it does not bring duration into the math from a leveling perspective.

Melanie: Thanks. Thanks for that. He’s going to try fixed work. He’s going to use that more.

Sam Bell: Yeah. Big one. Big one. Made me crazy before I figured that out.

Melanie: What about leveling across a portfolio of projects when using resource pools versus named resources?

Sam Bell: Yeah. So when you start talking about using the resource pools within Project server and whatnot, I’m not going to go there with this approach because this was more of a standalone approach. But I will tell you, it was developed too level a project where we basically had a shared service project, we had development project, we had database project, all kind of running in sequence with each other, and I had to bring all of those back together into one common program plan. So it does work in that environment.

Sam Bell: What we wound up doing was linking all the projects back together so we could see what the overall curve was. But we also did have separate teams for some of the work. So it comes back to that team one, team two approach. We were constrained by that because different teams were working on different parts of the program. So that may also help you keep those resources separate at the end of the day. But if you need to share them across all tracks, then you can put them all in one big project plan or in a bunch of linked project plans that all tie back to the same set of resources in the master plan and do it that way.

Sam Bell: I would probably be inclined to just dump it into one big monster so that I had control over it and didn’t worry about how everybody else’s plan was structured and whatnot. And that’s actually how I managed that when I took their plans and then integrated into one master plan so that we didn’t have to worry about everybody handling things differently on their teams.

Melanie: Thank you.

Sam Bell: It’s a tough question. It is a tough one. I recognize that one. And there’s a bit of art to it.

Melanie: But yeah, they had a couple questions around that as well. Do you use fixed work or fixed duration on summary task?

Sam Bell: All summary tasks are by definition fixed duration. The only thing is that you may not be actually setting the duration, the work underneath sets the duration. So if you open up any fixed… I can pull one up right now here. Let’s just pull up any. If we take a look at this guy right here, let’s just take a look at his task type here. So you see any summary task is by default fixed duration, can’t even change it.

Melanie: Thank you for that. And did you want to launch another poll or are we all done with polls?

Sam Bell: Oh, bugger! I’m sorry. I blew right past that one. Didn’t I, Melanie?

Melanie: Yeah. Is it still?

Sam Bell: Yeah, it doesn’t matter, I don’t think, at this point.

Melanie: Okay.

Sam Bell: My apologies there. I had to type the whole thing up and blew right past it. That’s what happens when you don’t pay attention to your speaker notes enough?

Melanie: Well, you’re paying attention to the question, so thank you for that. So it sounds like we are ready to close here. Please keep sending us your questions though if you have any more and we will get ready to close up. A big, big, thank you to Sam for an excellent session and for engaging with all these questions. A big thank you to our MPUG community today for asking questions, for choosing us to grow your skills with today. The PMI PDU for today is up on the screen and it is mpug012622.

Melanie: Again, that’s the activity ID. Following today’s events, I will be sending you a link to this recording. I’ll send you a quick survey for you to share your thoughts. I’ll also be sending a quiz out to you for this series. This quiz is for you to test your knowledge. We don’t keep copies of it, we don’t see your results. So please download your results for your own reference or for career development. You’ll also see on the screen Power Automate is coming up, which we’ve had a lot of people in our poll say this is something they’re interested in. So please sign up for that.

Melanie: And we have a JIRA panel discussion coming on. We’re bringing in experts to answer your questions about JIRA. If you open up your newsletter from last week or this week coming up, you can submit your questions early so the panel can dig into them before the session and present you those answers. So please feel free to jump in that poll and tell us what you’re interested in and we will dig into JIRA on February 23rd.

Melanie: Thank you again for your live attendance today and asking your questions and for being part of our community. Thank you again, Sam. I will keep this PDU number up here for you for a while. And if there’s any more questions, I’ll stay on for a bit and we will answer what we can. Thank you so much.

Avatar photo
Written by Community
Where Project Managers and Microsoft® Meet.
Share This Post

Leave a Reply