Critical Path Modeling Using Microsoft Project: Lesson 2 – Leveraging Work and Predecessor Types to Structure the Plan Transcription

Please find below a transcription of the audio portion of Sam Bell’s course, Critical Path Modeling Using Microsoft Project (Lesson 2: Leveraging Work and Predecessor Types to Structure the Plan), 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’s lesson at your convenience.

Melanie: Hello, welcome. Melanie here with Team MPUG. Welcome to Critical Path Modeling. Today, we’re doing lesson two leveraging work and predecessor types to structure the plan. And we have our wonderful presenter, Sam Bell, back with us today. I would invite you today to share your questions via the MPUG chat and question feature on GoToWebinar. You can extend this box out and type your questions in the box and I’ll present them to Sam as he takes breaks throughout the session. And with that, I will hand things over to Sam, and we will begin our session.

Sam Bell: All right. Good morning, everyone. Or good afternoon, I should say. Sam Bell here. As Melanie mentioned, we’re here for session two about critical path modeling using Microsoft Project. I’m a season project manager, been doing project management about 35 years. And I’m also the chief information security officer for Edwards Performance Solutions. I’m going to be sharing with you part two of the approach that I developed ways back for surviving large commercial software project development and using Microsoft Project to figure out my resources and determine what the critical path of the project would be and how we could get the work done as efficiently as possible.

Sam Bell: I’m going to share that second part with you today. With that, we’ll go ahead and we’ll get started. Let’s just baseline where we are. In the last session, we talked about the initial work breakdown structure, tasks, lists, resource types, and resource availability. We talked about using the standard calendar and a modified standard calendar to adjust for different work availability and using that different calendar to also support things such as recurring meetings and the like, which oftentimes can gum up a project plan when you try to put them down as specific activities.

Sam Bell: We also talked about the ability to use different types of task types and whatnot for each task. We’ll be going into that today, understanding how the project plan and the structure and the dependencies drive the actual leveling of the project plan within Microsoft Project and how you can also use support tasks to model some of those activities where you need to keep resources on a project, maybe between work to make sure your project stays fully loaded.

Sam Bell: But you need those support tasks to grow and shrink over time based upon the amount of work and the resource curve that you apply to your overall project plan. That’s where we’re going to spend our energy today. And then in our next session, we’ll talk about project plan leveling, how to level, why, when, and the approach to do that. With that, as a background, we’re going to drive into the different task types that are available inside of Microsoft Project and how they allocate resources.

Sam Bell: You basically have two different types of project task types that we’ll be using within this approach. They are generally fixed work and fixed duration tasks, so the two types of tasks that we will be using. Each of these does work differently with regard to leveling and how it applies resources to the individual task. And so, we want to talk about what those two are, and then I’ll mention the third one that we won’t be using for this approach. The two that we’re using is fixed work.

Sam Bell: To the degree possible, you want to use fixed work tasks as much as possible throughout your project plan anywhere where it requires a certain number of resources to complete the task. You’ll want to use a fixed work task. If you apply more resources to a fixed work task, it will get done in a shorter period of time. Obviously, if you take resources away, you burn them in a partial percentage, the duration of those fixed work tasks will actually stretch out.

Sam Bell: You really need to be using fixed work as much as possible as you develop your project plan and structure it so that you can model different resource curves and have project be able to take advantage of the work type in order to apply those resources as you amp up the number of people that you put on a project. The other one is fixed duration. Basically, a fixed duration task happens in whatever time period you’ve specified there. Usually, fixed duration tasks are measured in days.

Sam Bell: And the other thing to call out too is that any summary tasks within your project plan are fixed duration tasks, even if all the work underneath of them are fixed work. And we’ll start to see how that works as we drill into the project plan itself. Let’s talk a bit about fixed work task type. As I mentioned before, this is the one that you want to use as much as possible. If you right click your task in your project plan, you’ll see the screen here.

Sam Bell: And if you go to the advanced tab, you’ll see that the task type there is fixed work and your constraint type is always as soon as possible, unless there’s some reason why it shouldn’t be. We don’t want to use any of the calendars at the task level or constraint dates unless they’re necessary, we’ll go ahead and we’ll use the resource calendar on that particular tasks. And the work really should always be estimated in hours, best way to do that, to make sure that you’re tracking it and you’re not confusing your fixed duration tasks with your fixed work tasks.

Sam Bell: And then if you are given estimates as durations, that’ll take me a week to do. Take a look at that and see is that really 40 hours’ worth of work for one person, in which case, it’s best to really shift those to be fixed work types, even if folks are giving you the estimate as it’s a week’s worth of work. You really only want to use fixed duration tasks where the work, the amount of time that the work takes cannot change. A good example of this might be curing concrete. Concrete is going to take as long as it takes to cure. There’s really putting more people on the project.

Sam Bell: That’s not going to make the concrete cure any faster. And for those types of projects or project activities, then you’ll want to use a fixed duration to accurately model the fact that no matter how many resources you put on it, the task is still going to take the same amount of time. As I mentioned before, rollup tasks are all shown as fixed duration. And we can use these fixed durations for modeling support time. From the software domain, a couple examples here, developer support during requirements, so the requirements were being developed.

Sam Bell: You have to have a developer on hand maybe to understand how to best write the requirements, to match the way that the system has been built. BA support between test case creation and system test is another case that often gets forgotten, and obviously, your developer support during system test and during user acceptance testing. Many times these types of tasks that we’re calling out here often get forgotten in a project plan.

Sam Bell: And if they’re left out, oftentimes, what can happen is another manager may say, well, if you don’t have any resources working on your project or your resources aren’t working on this project, then we can go ahead and assign them on this project over here. Modeling some of those activities with fixed duration tasks, make sure that your project plan is fully loaded, and that you don’t have any gaps in the plan where you actually need your team on site, but your project plan doesn’t show them doing any specific work. And so, we’ll take a minute to talk about that.

Sam Bell: I’ll take a second, Melanie, just to ask if there’s anybody has any questions about these two different task types. There is one other task type that I will mention called fixed units. We’re not really going to talk about, I’m sorry, fixed units. Because essentially, the way fixed units work is the number of people that are assigned to a task doesn’t change the amount of time that the task takes to be completed. This also happens to be, unfortunately, the default task type for most projects, project tasks.

Sam Bell: You’ll have to go in and set that as your default as a fixed work in your project settings so that any new tasks that you create are fixed work. And generally, fixed units for this approach isn’t really helpful. It doesn’t get you to where you need to go in terms of mapping out your resource curves against the work that needs to be done. Melanie, I will take a second if there are any questions, just about the different types of task types before we move forward and just talk about how we then use those.

Melanie: No questions yet, Sam.

Sam Bell: All righty, very good. Now let’s talk about some of those support tasks that we talked about earlier. And essentially, I found that it’s really effective to model these tasks with what I like to call a rollup task, if you will. And essentially, what this approach will allow you to do is to allow fixed duration work to vary based upon the amount of resources that are being applied to other work on the plan. As an example, I’m giving here development support during system tests. But obviously, really, anywhere that you have to keep folks on the project plan.

Sam Bell: And yet at the same time, maybe their work is they’re not doing specific work, they’re providing support. These rollup tasks can be really helpful in modeling those and making sure you don’t give up your resources on your project plan. Now, in order to do this, it requires using a bunch of different predecessor types that are available to you within Microsoft Project. Let’s talk about predecessor types just for a minute. In all these cases here, as I’m talking through it, we’re going to assume that task A is the parent and B is the subordinate tasks, the tasks that we want to happen afterwards.

Sam Bell: The one that I think we’re most commonly familiar with is a finished start type of predecessors. Task B will start when task A finishes, kind of makes sense, this then that. But there are a couple others that really can be very, very helpful for you. The next two, a start start and a finish finish dependencies and predecessor types can be really helpful for modeling some of these rollup tasks that we’ll see in a moment. And then the last predecessor type that’s available to us that I haven’t really found much use for it really is best when you’re trying to do tail end loaded schedules and you want the work to complete as late as possible.

Sam Bell: And that would be a start finished type of task where Task B finishes when task A starts. What we’re going to find throughout the balance of this presentation and next weeks is that we’ll be using the first three of these, the finish start, but then we’re also going to lay into it the start start and the finish finish to help us model some of those rollup tasks. Let’s just see what that looks like. If we talk about a rollup task, now one of the things I want to call out here as we’re doing this, and I call it out in the introduction to the first class, the approach that we’re taking with predecessors here may not align with what some of your clients are looking for you to do in your actual functional project plans that you’re using to run the project.

Sam Bell: What I want to call out here is the approach you’re seeing here will show you what’s possible, and we’ll model what is possible for you in your project plan. You may still need to take some of these predecessor approaches that I’m showing you here and then refactor them into whatever your clients are requiring to meet their project check guidelines and whatnot. And if we have questions about that as a little bit down the line, I’ll take some questions on that as we get a little bit further down here.

Sam Bell: But first, I want to take some time to just talk through how this works. In this example here, we have a system testing, test case execution that’s being done by a business analyst resource. And we basically have gotten … It’s a real simple plan, so we have a main screen, a detail screen, and then doing regression testing of all the functionality that is in this particular module that we’re testing here. Now, while this developer or while this business analyst is doing their testing, we need to make sure that we have a developer available to support that testing to fix any bugs and whatnot.

Sam Bell: And that developer is going to work for whatever that duration of the system testing is. Now, in this example, we are assuming here that the developer can fix any of their bugs during the system testing time period. We are making that assumption right here right now. But if you can just go with that for the moment, this has worked out very effectively in practice as well, as long as your analysts are serving things up in a timely fashion.

Sam Bell: But the thing that I want to call out here is that you’re going to notice that we’re doing something a little bit different with the resource and we’re doing something different with the predecessor. What we’re doing with the resource perspective is we’re putting the developer resource on the summary task. Now, I know that may seem to some as a no, no, and I would argue that with the exception of this very specific use case, it is absolutely a no, no.

Sam Bell: However, in this case, putting the resource at the summary task level and then putting two milestone tasks underneath of that, one with a start start dependency and one with a finish finish dependency ensures that this time period here and the amount of developer resources are going to needed, are going to grow or shrink and stay in line with the amount of time that the system testing takes for this particular module on the project plan. This is, again, the only time you’ll ever want to assign resources to a rollup task. It’s a very specific use case.

Sam Bell: But this can be really helpful for project manager support during your entire project or for some of these gap tasks that happen throughout the project that may vary depending upon the resources that you apply to the project itself. Now let’s take a look at that a little bit more detail and what does this look like. We take the same example and we’re going to look at two different examples here basically snapped from the project plan. This first example here, you can see we have 94 hours’ worth of business analyst work and we have 94 hours’ worth of developer work.

Sam Bell: We basically have one analyst working through and at the same time, we have one developer supporting them. But now what happens if we say, okay, we’re going to double our analyst resources because we want to get this work done faster, 94 hours is just too long, we got to get it done in under two weeks. In that case, you might take your BA resource and ramp them up to 200%. And if we go ahead and do that, in this example, you can see what happens to the work here.

Sam Bell: Essentially, because we now have two business analysts working on the work, the amount of time that this takes has been reduced to 54 hours. Because essentially, one analyst resource can go ahead and do this 40 hour task. The other analyst resource is doing this 24 and 30-hour task, meaning that the overall duration of the testing, the longest pole in the tent, if you will, is this 54 hours. And you can see that without doing anything to the developer resource line at all, the amount of resources here automatically adjusted based upon the work that was driving it above.

Sam Bell: This is really critical and very helpful way to model different resource curves and have the support task grow and shrink without having to do a lot of manual maintenance around those support tasks. Again, I’ll stop for a second. I don’t know if folks have got questions at this point on this, Melanie, but I know this one is one that might be a bit different than folks are used to seeing.

Melanie: I haven’t seen questions come up yet, you must be explaining it perfectly.

Sam Bell: Okey-doke. Okay, very good. Let’s keep moving forward then here. A couple things to consider here. As you model these support tasks with rollup tasks, from a software development perspective, you can see a number of types of tasks that can be modeled there to make sure that your project stays fully loaded. Another thing to indicate, too, is that sometimes you may need to use a finish finish plus a day and a start start minus a day to avoid an overallocation.

Sam Bell: If you’re trying to do a fill in task there, depending upon what work is being done there, you may need to shorten it by a day on both end to avoid it from being overallocated. But this really is a great way for you to model and see how your project plan will change as resources are adjusted here. Now what I’d like to do, I’m going to switch over just for a minute to project itself, and let’s bring over our project plan. We’ll just talk through this guy just a little bit here. And we’ll see where we’re using some of these rollup tasks throughout the project plan.

Sam Bell: As we look at this particular plan here, I want to call out right at the top here. We have most of the development work here working underneath task nine. And then my project lead time here and my project manager time is basically set up to grow and shrink with a start start and a finish finish milestone for all of the development work that’s there. I do the same thing with my project manager resource here as well. And what this allows me to do is that over time, I’m able to see how much PL and PM resource I need to use without having to actually adjust these lines as I adjust the work in the project plan farther down the amount of hours that both of these take will automatically grow and shrink based upon the work that’s happening in task nine.

Sam Bell: Let’s take a look at this. Right now, we have developer support during requirements and we have no resource there. And we have a little farther down, we have some business analyst resources that aren’t allocated as well. Let’s take a look at what does this look like from a resource curve perspective and what’s the problem we’re trying to solve here. If we go over here, if we take a look at our resource graph for our developers for the period 21 to 218, if we look from 21 to 218, we can see that really, right now, we don’t have any developer resources on there at all supporting us during requirements.

Sam Bell: But if we just come back over here to this task and we take this developer resource and now let’s go ahead and let’s just say, for example, that we’re going to take him up to 25%. We need somebody available, hey, 10 hours a week just to answer questions to make sure that our requirements are appropriate as we go through. We can see now that that’s given us 20 hours here. And if we go over to our resource graph again, we can now see, when we go to the developer resource, we can see now that we’ve got developer support laying in here as a result of adding that task.

Sam Bell: Let’s do this again. We come back down here. Again, if we take a look at our analyst resource as well and you can see here, we have a number of cases where we’ve added, say, an analyst resource here to stay on during development, during the different phases of development as well to glue these things together to make sure that our BA resource doesn’t get taken from us and pulled off onto another project because we don’t have them assigned to any tasks.

Sam Bell: And if we come back to our resource graph, again, for the BA resource now, we can see here that we still are now keeping them engaged on the project at some percentage, at 10%, as opposed to if we didn’t have those tasks there, this would show that, oh gosh, we have about two months of time, maybe where this analyst resource isn’t … We don’t need an analyst resource. And then they go off on to other projects. And then when it’s time to ramp your project back up again, those resources aren’t available to you.

Sam Bell: By adding these tasks and allowing them to grow and shrink as you modify the actual fixed work tasks and the resources that are assigned to the fixed work tasks. These tasks allow the rest of your plan to grow and shrink without having to do a lot of manual updating of dates and whatnot. It’s a great use of using a start start and finish finish predecessor, and a great use of putting a resource on a rollup task just to make sure that your project stays fully loaded throughout the time. All righty, so let’s talk a little bit about project plan structure and dependencies, unless there’s any questions, Melanie. We still good?

Melanie: We are still good.

Sam Bell: Awesome. Okay, so now let’s talk about the project plan structure and task dependencies. Because in order for this approach to work, structuring your project plan appropriately to take advantage of the type of leveling that we’re going to be using, and these predecessors is really key. Let’s talk about some of the concepts there that we really want to make sure are in place and that you’re following as you’re structuring your plan to best take advantage of this approach, but also to make it as easy as possible for Microsoft leveling engine to do its job.

Sam Bell: Now, this is the one, as I mentioned before, that may cause people some gas. I know that in some cases and some project guidelines you were told that essentially, every task has to be dependent upon another task and should not be at the summary task level. But for this approach to work, we want to do exactly that. We want to keep our predecessors as high as possible in the hierarchy and making sure that we don’t have a subtask from one summary task being linked to a subtask from another summary task.

Sam Bell: And the reason we don’t want to do that is, in addition to using the predecessors, when doing ID order leveling, Microsoft Project is also going to take into account this indentation. And it actually becomes part of your project structure and part of how Microsoft Project is going to try to level the plan and to try to assign the resources. The more that we can keep these dependencies as high as we can in the plan, the better that Microsoft Project can do this from a forecasting perspective.

Sam Bell: And also, if you think about it from an actual work perspective, if I look at what’s going on here, in this particular case, I have to develop and set up the environment first before I can then build the UI underneath that. These tasks here really can’t start until all the tasks here have been completed. That’s another rationale for having that at the highest level, because it actually models the work in the way that it is going to be done. But this is really key to try to keep the number of predecessors as low as possible and to try to keep the predecessors at that same level in the hierarchy with regard to summary tasks in order to allow project to do its magic.

Sam Bell: Another thing too to call out here, and you’ll see, is that you want to try to keep them at the highest level possible in the hierarchy. In this case, we’ve got two different tasks here that are both dependent upon system test case execution. And they both have got dependencies that are rolling up at the highest level here. We don’t have anything from this summary task tying to this summary task at all. Really, these are independent chunks of work that both can get started when system testing is complete here.

Sam Bell: You want to model it that way so that if work can be done in parallel and multiple summary tasks can be done in parallel, that you allow project to do that by not inserting predecessors that aren’t necessary. That’s another piece that you really want to, to keep in mind as you structure the plan. And as we go back to the plan in a minute or two, you’ll see how we’ve kept to that as we go forward. Let’s talk about this. Before we go into the actual plan itself and start looking at it, you want to think in terms of the network diagram that you’re creating.

Sam Bell: If you think in terms of that indentation that we just talked about a minute ago and if you think in terms of the predecessors as defining that network diagram that you’re trying to get through or what’s the fastest way to get all of the work done from beginning to end, if you think in terms of that network diagram and keep things as high as possible and as far left as possible, you’re going to have much more success when it comes to working with leveling your plan.

Sam Bell: The other thing that I want to call, and then again from a predecessor perspective, for those of you who do program, you want to think in terms of good programming practices, no spaghetti plans, don’t have predecessors jumping all over your plan. Because the more of those that you create, the more difficult it is for Microsoft Project to determine what the best approach that the fastest way to get the work done is and to have the least number of false constraints that are there as a result of the structure of the plan.

Sam Bell: For those folks who maybe go way back, it’s really almost like programming back in the day of go-tos. And I know that I’m going in the Wayback Machine there. But you really have to be very, very tidy in terms of your indentation, your predecessors and trying to keep things tight and componentize, so that you’re creating that network diagram that then project can optimize for you. A couple things, too, we want to call out. Don’t insert predecessors just to make the schedule work. I’ve seen this happen time and time again and been guilty of doing it once or twice myself.

Sam Bell: But if you do, make sure that you’re color coding them so you can find them later. Because, again, you’re doing that to try to understand and try to demonstrate what an optimal work breakdown might be at the end of the day. When you take this approach then and actually start to shift over into named resources, understanding where you’ve made those decisions in order to keep things together is key because you’re going to need to be able to make sure you manage that as you actually apply the resource, the named resources to each of the tasks that we have there.

Sam Bell: Definitely would consider restructuring your plan first. Nobody likes a false dependency in a project plan review. Now, the other thing I want to call out about project structure here is that this project structure may not look pretty from a management high level milestones type of approach. You may not get things nice and neat and indented, so you get all your dates exactly where you want them at your summary task level. That’s okay.

Sam Bell: Because what we’re trying to find here is the fastest way to get the work done with the resources that you have available or might have available. That’s okay if that’s the case. You can always work through that at a later point in time. One other tip, though, that I will say, is to somewhat make sense to inserting predecessors that aren’t really there if you know you’re working with a particular set of tasks and you know you want to make sure that it stays with a particular analyst resource as an example.

Sam Bell: Inserting those predecessors then will do a pretty good job of making sure that that one resource, if you will, is getting all of that work. Because the predecessor, they’re going to be the next available resources as you go down through it. You can do that, recommend not doing it unless you absolutely have to. And again, do make sure that you color coded so that you can find those letter later. It’s only going to work if you have tasks that are all together on a plan in order.

Sam Bell: You can’t do it across different chunks of the plan because as we mentioned, then you’re having dependencies that are going across subsections of the plan. But in that one instance, that is a case where you can do that if you really want to make sure that you’re modeling one resource working through that. However, you have to be really careful that you’re not creating a false critical path by putting all those predecessors on the plan. Let’s take a minute now to, again, switch over to Microsoft Project.

Sam Bell: And we’ll just talk through a bit on what this looks like in real life here, okay? And again, this is a sample software project designed to be pretty simple and pretty straightforward, however it is, actually was at one point in time a real software project. This actually did get the work done as well. And I guess a couple things that you’ll notice, we talked about the management tasks and all and then all of the work, really, that’s being done being under task nine. But you’ll see here that we’ve really tried to chunk things up.

Sam Bell: Technical design is the first high level task, and then development support during requirements, test case creation, predevelopment work, the actual development itself. And then as we come down here, a little bit of support between testing, and then testing. Now, the thing to call out here, you’ll notice is that usually when we talk about things, we say, requirements, design, test. What you’ll notice here that what we have in the indentation doesn’t really align with that.

Sam Bell: And we have a lot more things that are outdented, if you will, shifted left as far as possible because that actually represents the predecessors for the work that we have on the plan here as well. Again, other thing that you’ll notice here is inside of a given chunk of work, so test case creation, we can see that that’s going to be dependent upon task 10. Another nice thing to do, too, if you don’t use this view, having this predecessor successor view, in combination with your Gantt chart here can really help you.

Sam Bell: Because this will actually give you the name of the predecessor without you having to scroll up and down to figure out what you’re actually dependent on and what is dependent upon the task that you have here. But you can see, we have really very few predecessors going on here and test case creation starts after technical design is complete. But then test case creation, the actual test case development itself has no predecessor. There are no predecessors for any of these test case creations that are happening here at this point.

Sam Bell: They are all independent chunks of work and we don’t put predecessors because when we start to model different resource curves against this, we want to be able to have one person take the first task and a different analyst take the second task and a different take the third task, if that’s appropriate. And that’s as you structure your plan, you want to make sure that the work is broken down in that way so that you can do that. Additionally, you’ll see here at the same time that predevelopment work is happening at the same time.

Sam Bell: As quickly as we can get that work done, it’s happening, there really aren’t any predecessors to it. Because as soon as you’re ready to, again, have some availability, the developer should start getting the environment ready. Instead of putting predecessors here, we’re allowing that work to flow in and happen as soon as possible based upon the project plan. And then you can see here, we do the same thing throughout the project plan. Now one other thing I want to call out here, another technique you can use when you’re doing your planning.

Sam Bell: Off times, there are things, in this case, deploying to development, the quality environment, the production environments, so that you can get through your unit testing, system testing, and then full blown production. Off times, those are tasks that are shown somewhere in the middle of your project plan. Okay, well, we’ve got all our stuff, it’s in dev. Now, okay, we’re going to push it to dev. But putting that task in the middle of your project plan when that work may happen once, twice, several times during that phase, trying to model that dev deployment in the middle of the work somewhere down here would probably be very difficult and require some dependencies there that you may find later or challenging for you.

Sam Bell: In this case, we know that we’re going to have to spend 30 hours deploying to development, the qual, and the fraud environment. In this case, what we’ve done is essentially just front loaded this at the beginning of the plan so that that work is planned for and taken into account. And the dates that we get at the tail end of the project, which, of course, is usually what most folks are worried about, those dates that come out at the tail end of the project will be as accurate as possible.

Sam Bell: And we don’t have to worry about pushing these individual tasks around, laying them exactly in on the right spot on the project plan just to figure out what our date is going to be. Again, remember, this is a forecasting tool, we’re using this to figure out what’s possible. We don’t have to model that that deployment is happening on Tuesday in April if we know that we’re going to spend about two weeks’ worth of deploying throughout the project, frontend loading that, then allows us to focus on modeling the true dependencies, the true work dependencies that are there before you go as you map out your project plan.

Sam Bell: This is really a key approach here, is the use of as few predecessors as possible, keeping things out dented if you will, as far as you can. And then using those support tasks and whatnot to fill in the pieces, if you will, to fill in those extra time, support during integration testing, shared service support during integration testing. In this case, we have two different teams that need to support during integration testing, so we can show that all happening in parallel.

Sam Bell: And then by doing this, essentially, at the end of the day, as you model and as we will see in the next session, as we start going through playing with different resource curves and different end dates, having your project plan structured this way is going to enable Microsoft Project leveling engine to do its job as simply as straightforward as possible and get you where you want to be without having to do a whole lot of back and forth and playing with percentages and playing with individual percentages on tasks and all those other things or inserting false predecessors, all those other things that we do to try to get a project plan to line up.

Sam Bell: If you follow these couple of guidelines around the resources, around the project structure, keeping things as high as possible, not inserting predecessors unless the work is actually dependent, all of those things together really help to create a workable project plan that can grow and shrink over time as you apply the different resources. And as we look at the Gantt chart here, you can see it’s a pretty clean project plan. There’s not really a whole lot of mystery here.

Sam Bell: Through these rollup tasks, we can very quickly see, what are those critical things that have to happen before the next part of the project can proceed? I guess one last thing as we’re looking at this project view here, there are some things you can do, either by using custom columns and whatnot. I actually use a custom column with a yes, no field called is it a milestone? And then if it is a milestone or it is a particular task that I want to report on from a status reporting perspective, I can use that is this a milestone task to just call out the key phases in the project that I’m worried about, such as development, such as technical design.

Sam Bell: And I can call those out as high level milestones to manage and communicate the things that management’s interested in, while at the same time still keeping my project structure in a way that works for me as a tool to allow me to modify and apply different resource curves against the work to see how fast can we go and at what point do we hit diminishing returns with regard to resources that are available to us. Let me just switch back then to the summary here, and then we’ll go into any questions that y’all might have around this, anything you’d might like to see here as well.

Sam Bell: Let’s just talk about it from a general, we want to keep it as high at the same level in the hierarchy throughout, don’t start creating spaghetti plans and those types of things. Keep them at the same level, keep them as high as possible in the hierarchy as well. Don’t use false predecessors. Or if you do, certainly make sure that you go ahead and highlight them so that you’re able to find them and remove them at a later date. We’ll talk about this and the next one. We’re basically using ID order leveling, so you want to organize your plan to take advantage of it.

Sam Bell: Essentially, the way that by using ID order leveling, it’s going to come down and assign resources from your top of your plan, all the way down to your bottom of your plan. What we’re using is the project structure along with that top down flow in order to control how the resources get assigned and what that network diagram of the work actually looks like at the end of the day. Other things you want to take into account, if you do have a more complex project, you may want to structure the plan around your resource types or your project phases.

Sam Bell: Sometimes you may have to jigger what you’re grouping together in order to get the project plan to flow out and make the best use of your resources there. You want to look at both of those, both the phase, as well as the resource types. Definitely think about that network diagram you’re creating with the hierarchy as well as the predecessors and definitely, no spaghetti plan. No predecessors all over the place that you can’t track and follow because the more of those you have, Microsoft may give you, be able to level and give you a date for that.

Sam Bell: But as soon as you start to play with that, as soon as you start to move some tasks around, those spaghetti predecessors will cause a whole lot of grief as you’re trying to maintain your project over time and keep it current with the way the work actually winds up panning out at the end of the day. With that, I’ll open up the floor to any questions. If anybody has, anything anybody would like to go into specifically around this, either from this session or from the previous session, be happy to take any questions and go from there.

Melanie: Yes, please share your question. There’s a lot here. And we’d all benefit from your questions, and I’m happy to send you all that a little gift for getting involved today. One question we do have out here from Ben, large school of thought says no dependencies on summary task, as all work should happen at the detailed task level. What are your thoughts on this?

Sam Bell: And I knew that was going to be probably the biggest question that folks might have around that. And I have a couple thoughts around that. First of all, when I look at a summary task, to my mind, a summary task, all the work has to be completed for that summary task in order for that chunk of work to be used. If we’re thinking, let’s just say, from a manufacturing perspective, if I’m building a washer motor or windshield washer motor for my windshield washers on my car, well, incorporating that washer motor into the car is not dependent upon any other tasks other than completing that washer assembly and building it.

Sam Bell: I would argue that that summary task, essentially, is that chunk of work that needs to be complete before you can incorporate that work into the next phase of the project plan, if you will. I would argue that not having them rollup at the summary view creates a lot more work for Microsoft Project and for you managing your project plan, because you basically then have to take that thinking of I finished this washer motor and go, well, wait a minute here, my task for finishing the washer motor is putting the last four screws in the washer motor.

Sam Bell: And then I’m going to make installing the washer motor based upon putting those last four screws in the washer motor itself. To me, it makes more sense that, hey, those four screws complete the washer motor, and then at that point, it’s ready for integration. I do think also, having all of those predecessors down at the detail level makes it much, much harder to see what your project structure really is at the end of the day. Because we are not taking advantage of the fact that the summary tasks are exactly that, summary of a bunch of work that needs to happen before you can move to the next one.

Sam Bell: What I would say is this, because I know that this may give folks gas going forward, what I would say is this, if you look at this approach, if you’re in an environment that says, hey, absolutely, we’d never put predecessors on summary task, period, don’t ever do it. What I would argue is this, think of this approach as a logical view of your project plan, what can be done? You can then take this and it’s the same thing with named resources as well.

Sam Bell: If you take a plan that has already been structured, leveled, and hammered out using this approach, it’s a whole lot easier than to then go and switch. And if you have to put those subtasks dependencies on there to go ahead and do that with a plan that is already leveled and tight, because your dates won’t move around all over the place. Same thing with adding named resources. If you use this approach and you figure out that, let’s say, three business analyst resources is 300% of a business analyst resource is what you need, if you do that step first and then go through and go, Joe, Sue, Frank, Joe, Sue, Frank, across the analysts tasks, you’ll find that having the plan pre-leveled start with makes that step a whole lot easier.

Sam Bell: In those environments, think of it as a planning and what’s possible tasks. And then from there, okay, let’s shift into an execution mode and comply with some of those other requirements with regard to dependencies. But philosophically, I think doing that makes it a whole lot harder to work with the tool.

Melanie: Thank you for that. This is from Mike, do you ever create a dummy or anchor task to hang the first dependency off?

Sam Bell: Not exactly sure where you’re going with that, but what I find is that there’s oftentimes a lot of refactoring. I may say, oh gosh, I think test case creation is the high level task, and I start hanging things off of that. But then as I start to blow out the detail underneath that, then at that point, and I start to look at those dependencies, I find sometimes that I have to rearrange or reshift what I’m hanging things off of at the end of the day. It really is a try something, see what works, see what kind of resource curve it gives you, and then go from there.

Sam Bell: And we’ll spend some more time talking about how you can use the resource usage view and the resource graph view to understand where you’re stuck. And then using that to reshift some of your tasks around to optimize that better. I don’t know if that answered the question, Melanie, so I’m going to throw it back out there. Did that cover what you’re looking for, or am I not following?

Melanie: We’ll wait to hear back from Mike on that. Another question … That was okay, he said. Another question we have is, is can we get the MPP file for the audience that’s something we can share that you’re using?

Sam Bell: I’m going to have to check on that. I have to see because these are internal templates here. But I can certainly check to see if that is something that we can share.

Melanie: And if that’s possible, we will share a link with that in the next session, follow on email.

Sam Bell: Sure.

Melanie: And then we have from Charles, what does the network diagram for this model plan look like?

Sam Bell: Okay. As far as actually printing it out, I can’t really show you that offhand. But what I would say is that, as we go ahead and we look through this plan, let me just get them up here a bit, we can see, by even just looking at the overall predecessors and these dependencies at the highest level, we can see what those highest level tasks are here. As we follow this through, we can see this technical design phase is really the first part of this. And then from there, picking up with the test case creation is part of it.

Sam Bell: But the actual real long pole here, since this also comes down here, is the development work. By looking at the predecessors of each of these things, we can see that here, our development work winds up being the longest pole here. And then as we get down to testing, we can see then the getting the integration testing and all and doing all of that alignment after the UI has been developed and all of this stuff has been done, getting that development integration is the next piece that’s happened here. And we can see how all that work is stacking up right off of that.

Sam Bell: And then from there, you can see the next phase we’re going into is the system testing phase. And then user acceptance testing is the next chunk of work, and then doing burn and support and transition as well. The thing I like about this is you can really … Yes, there are tools and whatnot and ways to get a picture of the network diagram. But at the end of the day, to my mind, it all comes back to what does my Gantt chart need to look like, and do I have any spaces where I’ve either got split tasks or a lot of hang time or a lot of dead air there?

Sam Bell: Or do I have a plan that is reasonably tight there as well? I generally use the Gantt chart view, and I’ll show you next week with the resource graph and the resource usage, where you can actually see the individual tasks that folks are on. You can get even more detail as far as what is the dependency and what’s driving that overall project plan time here.

Melanie: We have a couple more great questions. Tony asked, if linkages are performed at the summary task level, don’t you miss the detailed task when filtering for critical path?

Sam Bell: Well, again, what I would say here is you have to look at this as what’s possible, in terms of your managing the actual tasks that are underneath and making sure they get done. That’s one of those cases where, yes, having those additional predecessors and shifting into an execution mode, which show you what those tasks are, I tend to look at it as, as we’re walking the planet, as we’re working it, we’re working in a chunk of work or working within a phase of the project.

Sam Bell: Generally, you’re managing a phase of the project at a time and keeping an eye on what all those activities are underneath. That’s essentially how I keep an eye on my critical path, is I’m looking through and this is getting more into tracking, which is a little outside the scope of this. But as I start tracking, my percentage completes down through all of this. If I see that some of this stuff is lagging here and I know that there are tasks that are hanging off the end of this, like DAO development, in this case, data access objects, I know I have these tasks that are dependent upon it there.

Sam Bell: This is going to then let me see what are the chunks of the project that are dependent upon this piece getting done. To my mind, it’s more managing the phases of the project than necessarily dishing out individual tasks, per se. I would say that’s probably more of the execution approach where you’re trying to say, okay, what’s my status on this task? What’s my status on this task? What’s my status on the next task? But just in order to manage the project at the end of the day, applying your percent complete against this and then tracking those summary tasks that are on your critical path and making these summary tasks, basically, these represent key things that have to happen in order for things to move forward. If you start to see tasks slipping under need this, then you’ll know, okay, well, I’ve got slipping tasks that are happening here. This summary task is probably in jeopardy there.

Melanie: Thank you, again. Matthew asked, do you always use work or have you used duration as well for the long term projects to track required time per task? Is there even a difference? Also, can the critical task highlight, or is it only visible in the Gantt view?

Sam Bell: Yeah. I know that there are some tools that will also show that critical path for you. But right now, I mean, the approach that I have always traditionally used has just been looking in the Gantt view. Because invariably, that ties back to a project plan that everybody can wrap their heads around. Folks are used to looking at Gantt charts. I’ve found that this has been an effective tool for managing that. Again, the goal here is to try to get the work as tight as possible with no dead time wherever possible and all of the dependencies satisfied as quickly as possible here. This view really does help show that all by itself.

Melanie: A question from Dipa, as employees get pulled off tasks for other higher priorities, how do you adjust fix units to reflect that?

Sam Bell: Well, I don’t use fixed units. That’s the first thing. I only use fixed work. And we’ll talk about this a little bit as we talk about the resource calendar. We did talk about it the last time. But essentially, what we would do if we went into, let’s just say, our resource sheet here, and let’s just say that I’ve got a business analyst resource here, and right now, I’m showing that they’re available forever at 200%. Well, let’s just say as an example, now that somebody has come along and said, well, yeah, Sam, I’m sorry.

Sam Bell: You’re only really going to be able to keep DiPA through 331. And then after that, hey, you’re on your own, you got to find somebody. The way I would then model that would be like this. So I have 200% up through the 31st, and then I would just adjust my resource availability down to 100%. And then once I’ve done that, I would just level all my resources. And, of course, I’m demoing on the fly here right now. And this plan cannot be satisfied with just one resource. We would now have to go back and actually see, okay, where is our constraint there with that resource.

Sam Bell: And what I would have to do now is go back and look at this overallocation, try to figure out why with only one resource my project plan now is saying that the work can’t be done. Because apparently, there must be somewhere where I have business analysts supporting something as well as work getting done at the same time. I would dump that into the actual resource, re-level, see where I’m in trouble, and then basically re forecast the plan with those new resources once I understand what that looks like for me.

Sam Bell: And we’ll spend a little bit more time doing that next week as well. The key there is using that blended resource. The key is then going back and let’s just go ahead and fix them in this case, let’s just say in this case, fine. And then going back and then seeing what does that actually do to your project, where are you overallocated. And then, okay, if that’s the case, what’s that going to do to my end date once I re-level and square things away?

Melanie: One last one, if you’re willing.

Sam Bell: Oh, I’m willing. Absolutely. I’m just making some notes here because that might be what I just showed you might be a good example to use for the next one, for the next session. Just want to make a note of that. What else you got? I’m good. I’ll keep going if you want.

Melanie: And we just got a thank you, that quick example of resource allocation was helpful. All right, so here we go. Since there are a number of missing predecessors yet, there are different start dates in the network. Are you applying start and finish constraints to individual task?

Sam Bell: No, I am not. Let me show you that. Basically, I am only applying constraints where constraints actually exist, where something really is dependent upon something else. As an example here, for all these test case creations, and actually truthfully test data setup probably should be dependent upon all the rest of these guys, but all of these different test case creations here, really, can be done by different people right now according to this plan. All those test cases can be done by four different people at the same time and it wouldn’t matter.

Sam Bell: There’s no reason to put any kind of predecessors here because I want project to throw bodies at this as fast as it possibly can. If I put a predecessor in there, it’s then not going to assign a body until maybe that previous task was done. By keeping it as light as possible in terms of predecessors, keeping the predecessors as high as level as possible, making things as left as far as possible, and then keeping the dependency as simple as possible project then, and by using ID order leveling, pardon me, which means it’s going to start at the top of your plan and go all the way down.

Sam Bell: We are definitely taking advantage of that ID order leveling in the structuring, and it is something that really makes this approach work well. Because then if you have to force something happens before something else, when it isn’t really a dependency, you move that task above the other one. It’ll get resources allocated to it first. But we’re not creating a case where we’re saying that the work has to happen in a particular order. We’re letting the work structure itself drive that based upon the things that are actually dependent.

Sam Bell: And I will say, and I know I mentioned before, you may have to shift back to other approaches from a execution stage, especially if you have some requirements around no summary tasks and whatnot. I will say that I have, for years, used this approach with these high level predecessors and all the way through execution on a project. And it’s been very successful for me. This approach will work all the way through to execution. But what I’ll say there is that you have to make the call as to what works best for you in your environment.

Melanie: Thank you so much, Sam. This was excellent. Thank you, MPUG audience. The questions really make this session … We could feel the community here. Thank you for that. Thank you for choosing us to grow your skills with today. I’ll be sending Sam all of these questions as well. If there’s something we need to go over in next session, we will do that. And following today’s event, we’ll send a link to this recording a quick survey. So please share your thoughts of what you thought of the event.

Melanie: If you got involved today, please make sure I have your contact information in your MPUG account, so I can send you a little thank you. And please join us again next week for leveling and resolving resource conflicts. And then also, we have some great upcoming sessions as well. We have three tips to power automate your project beginning February 9th, and then we have some sessions on Excel coming and power apps and really good things out there. Thank you again, and I will keep the PDU up for anyone who missed it today.