LightBytes – APM Scheduling and Critical Path

Welcome to another episode of ByteSize Project Management, brought to you by Training Bite Size. As always, I’m your host George, and today we have our lead APM trainer, Callum Downing, here to discuss the critical topics of scheduling and critical path management. With his extensive experience, particularly in defense, Callum is well-placed to guide you through these essential project management concepts. Whether you’re preparing for an accredited exam or seeking to enhance your project management skills, this episode will provide you with valuable insights and practical tips to help you manage your projects more effectively.

Hi, you’re listening to ByteSize Project Management, a podcast about all things project, program and IT service management. As always, I’m George and I work for Training ByteSize, a family-run training provider with a passion for project management. Our podcasts will bring you top tips such as how to pass your next accredited exam through to unique industry insights and conversations with industry experts.

Please let me introduce you to our lead APM trainer, Callum Downing. He’ll be taking you through the key areas of scheduling and critical path this morning. Callum has a wealth of pragmatic experience in project management and has a fantastic way of bringing the guidance and methods to life which helps your attention to information.

So Callum, over to you. Thank you very much. Sorry to cross yours.

I forgot you were going to celebrate me a little bit. Thank you very much for that. Good morning, everybody.

Welcome to a relatively mild Tuesday morning here. But today we’re going to talk about scheduling and critical path. Very briefly, just introducing myself.

So yeah, Callum Downing. I work for Training ByteSize. Wealth of experience coming mostly, well, my background is in defense, so MOD is where I worked for the majority of my career.

Now teach project management. I want to talk to you today about how, particularly how the APM recommend running a schedule. So you’ll often find there’s a lot of crossover with other methodologies here.

So you should be able to see the screen, hopefully. I’m going to just walk through the PowerPoint. If you don’t mind, if you can save questionsb for the bit where I bring up the screen saying there are questions now.

If you do want to just ask a question, just pop it in the chat though. If it’s just an online off un-miked question. All right.

But if you want to speak up, if you could please wait until the slide that says any questions. Now I’ll indicate when that is. We can do that.

But for now though, let’s get started. So this is a just very quickly, I don’t know, spend all too long on this slide. Just want to quickly whiz through a few things.

I want to just talk about one of the things at the top here, which is work breakdown structure before I start talking about critical paths and what they are and what they mean. But I want to introduce you to work breakdown structure. This is part of scoping.

Now, scope, which is a term, so maybe maybe all of you have heard, is in simple terms, the breadth of what the project is trying to achieve. That includes the work packages, the products we’re trying to produce, costing all that up and everything. So the top half of this screen up down to responsibility side matrix is all about how we start working out the scope.

It will help us to build up a really strong scope profile. And I think before I go into schedule, I want to talk about one of the key scoping documents, which is the work breakdown structure. Now, you may have seen these before, especially if you’ve used any tools like Primivorous 6, which is a project management scheduling tool.

You may have seen a work breakdown structure in software like that. I usually use something like Mirrorboard. When I first started doing these, I used Post-it Notes.

But effectively, they are hierarchical diagram and you break down your project into its constituent tasks, starting with the biggest task at the top, the largest task, which is decorate room in this instance, which might be part of a bigger project, which might be to renovate a house or recreate a house or something. And then it’s just breaking it down into smaller tasks. So rather than simply decorate room, it’s what tasks do we need to do to decorate a room?

So paint walls. And then you break that down. So we need to paint the walls.

What tasks do we need to do in order to paint walls? So that would be choose paint, buy paint, paint walls, buy equipment, et cetera. Now, one thing this does not show, this work breakdown structure, since it’s a hierarchy, I always refer to it as a family tree diagram.

So it looks like a family tree. You’re breaking it down into smaller and smaller pieces. Is it does not show sequence.

This purely is a hierarchy. So this diagram here is not showing us that we have to do the management first, then the purchasing, then the design work. It’s simply saying, in order to decorate a room, we need to do those four things.

Management, purchasing, design, work inspection. How these work is you start broad and then you refine it over time. And you want to do this as a collaboration.

This isn’t for one person to create. This is a, certainly I find it works best as a collaborative exercise with your project team, with your stakeholders. It gets everyone discussing.

It also helps to avoid making, avoid missing things on here. If you have a collaborative approach to this. But effectively, this is kind of, you need to have something like this before you can schedule.

Because if you just start scheduling, we’re just randomly sticking tasks into a sequence. Then how do you know it’s relevant? This helps to make sure the tasks you’re doing will connect to another task to make sure that they are, they’re in line with what we’re trying to achieve overall.

And this is almost the backbone of the scope in a way. So you need to have, you need to have something like this. Mirror boards, lucid spark, primiviris six have this stuff.

There’s loads of tools out there that you can use to create these. But obviously today is not about scoping, it’s about scheduling. So in order to create a schedule, what we want to do is work out what order these go in.

We want to create what’s called a sequence or a network. And again, that will be usually a collaborative thing. We don’t want to, we need to work out with our team, what order we do things in.

So for example, I can’t paint a wall until I’ve bought the paint. I can’t buy the paint until I’ve chosen what type of paint color I want. So you’re going to find there’s a logical sequence.

But again, as a project manager or a project professional, we don’t have to be an expert in everything. This should be a collaborative exercise about assembling this into a logical sequence. And your sequence will look something if I just move the slides along slightly.

There we go. Something like that. Just in very simple terms, we want to call, we want to put things into dependencies, which is your logical sort of sequence of events.

So in this instance, we’ve just used letters as the task names rather than actual tasks names, but we’ve got task A and task B. And dependent means I cannot start doing B until A is finished. I must have finished A before I can do B.

And I show that with an arrow going from the right hand side of A into the left hand side of B. And that’s called a finished start relationship. That’s now showing me that I cannot do B until I’ve finished A.

And notice for moving from left to right as well, it’s a very traditional way of doing it. If any of you have ever used anything like Microsoft Project or Primitive Area 6 or anything like that, you’ll often find there’s a button in the top corner or somewhere in the software that will have something like network written on it. If you click that, you’ll see this that sits behind things like Gantt charts.

Those bar charts that turn on their side to show the durations and how the tasks connect. This sits behind those. And then we can make it a bit more complicated.

So for example, on the bottom right hand side of the slide deck there, we got to do A before we can start doing B, but we got to a finished B before we can start doing C and D. So C and D can be run concurrently, but as long as B is finished. So these are called dependencies.

This is showing that logical sequence of events. In reality, you’d have task names in there, obviously. So this is what it starts to look like.

This is a very simple version of what I’d call a network diagram or precedence network, productivity network. Again, there’s the beta band what people want to end up calling them. I’ve always referred to this precedence networks or precedence diagrams, but this is a more comprehensive way to show a schedule.

There’s no dates on it. There’s no kind of resources assigned to it. It’s simply a raw mathematical look at your schedule.

Now, we don’t tend to have to do these by hand anymore. We used to, when I started, I used to draw, I used to create these on Excel and stuff like that. But nowadays, the software does a lot of this for us.

But it’s worth knowing that this sits behind the software. There’s a couple of things on here that are really worth knowing. So across the top, we’ve got what we call the earliest start, duration, and earliest finish.

Let me just see if I’ve got a note. So these are called nodes, these boxes, without going too far down rabbit holes. These are called nodes.

And I’m not going to go through all the numbers on the nodes. The left and right indicate the finishes. And the left is the start of the task, right is the finish.

So if you’re looking at activity A, you start on day zero and it finishes on day five. Now, the top middle box is the duration. So that’s how long activity, so activity A has a five in the top middle there, which means it’s going to take five days if we’re using days as the kind of time scale.

Therefore, it finishes on day five. The key number that’s worth knowing here, so if you look at the top right-hand side of the activity F there, which is the last task in the sequence, that finishes on day 16. So we have a 16-day project.

That’s what that’s saying. Again, I’m not going to go through how this works. The maths is fairly simple, but again, the software will do all of that for us.

So I’m not going through the maths today. It’s not what we’re doing. What I do want to draw your attention to is the bottom middle number.

So activity A has a zero in it. Activity B has a five in the bottom middle. Now, those numbers relate to what’s called total float.

It’s the amount of float or total floats that task has captured in that bottom middle. So what that means is for activity A, which has a zero and it’s marked in red, and that is very traditional as well. We tend to mark the, if there’s a zero, we often will mark it in red.

If there’s a zero in there, which there will be a line of zeros. If you’ve done the maths correctly or if you’ve programmed the software to do it that way, it will show zeros in the bottom middle. There will be pretty much in every project.

There will be a line of zeros if you look for it or you design, if you’ve done it properly, as it were. That shows me that activity A, for example, which has zero in the bottom middle, so zero total float, has no wiggle room. There’s absolutely no space on that task to be late or extended or expanded in any way, because if task A is late by a single day, because there’s zero days total floats in it, it will mean that the project will take longer.

Whereas activity B, if you look at that one, has a five in the bottom middle. That indicates it has up to five days total float, which means it can be late or extended by up to five days and not affect the end date of the project. So it’s telling me I have a bit of space on that task to play around with and still deliver my project on time.

Whereas activity A, C, E and F have no wiggle room on them whatsoever, which is the critical path. The critical path is the path of… Well, I’ve been careful my language here.

It’s the path at the greatest risk to your deadline. Not that it’s the path at the most risk on it in general. It’s the path with…

For those tasks to be late, they’re the tasks that will affect your end date, if any of them are late. So hence critical path. They might be…

If your project is very time critical or very, very focused on deadlines, then by knowing the critical path, then you know where you might want to prioritize things like resources, money, effort, stuff like that, because you know that if activity A is late, then the project will be late. Whilst activity B and D both have a little bit of wiggle room in them. If you’re looking at that bottom, middle sort of section of the node there, that five and the four, so five for B, four for D.

It’s telling me I have a bit of space on them. So it might be I take some resources. I was going to give the task B and give them to activity C, just running concurrently or could run concurrently, because activity C is on the critical path.

So critical path. I wanted every project, every linear traditional waterfall project will have a critical path in some way, shape or form. You may not have found it, but it will be there.

It’s worth identifying it. Gantt charts can show it as well, but you tend to find that people can fudge gantt charts quite easily. So when we very mindful, if you see a gantt chart, there’s no obvious critical path on it.

There may be a problem there, because there’s no kind of… There will be one. It’s just you need to identify what it is.

There will always be a critical path of some kind, because this is all based on logical sequence, which task has to be done first, and what the priority of the task structure is and everything. There will be a critical path in some way, shape or form. There can also be more than one.

There’s not… You’re not limited to just one critical path. You can have more than one, but there will, I won’t say always, but nearly always, there will be a critical path of some kind in your traditional waterfall project.

And you want to know it is, because it’s the path at the greatest risk, it’s the path with zero wiggery on them, so you know where to prioritize resources, etc. And it will show… Again, like I said, it shows why the project is as long as it is.

That’s what those are the words I’m trying to look for there. So if you add up the durations of activity A, C, E and F, which are all the tasks on the critical path, if you add up those durations, which is the top middle, you will find that they add up to 16. So the reason my project is 16 days long is because of the critical path.

So if my stakeholders are screaming at me saying, I want it in 10 days, then this will show them and shows me that I cannot do it in 10 days. The quickest, the shortest possible duration, based on my estimates, which we’ll talk about shortly, the quickest, the shortest possible duration this project can be, based on the critical path I’ve identified, which is again based on logical sequence and collaboration, hopefully with your colleagues and stakeholders, to establish what that logical sequence is, is telling me and my stakeholders the quickest I can do this is 16 days. So it’s a piece of evidence to show stakeholders and your colleagues or whatever, why the project is the duration it is.

Because you might be given unrealistic, you might be given ridiculous deadlines. I’ve been given loads of stupid deadlines in my time, ridiculous, I just plucked it out thin air. I want it in 10 days, there we go.

This demonstrates that you can’t have it in 10 days. So it’s a really strong piece of evidence, again that you will display as a ganchard, you wouldn’t display it like this, this sits behind your ganchard, like I said. But if you fudged a ganchard and you haven’t been mindful of this sort of thing, with the connections, those arrows, those dependencies, which task must be done before this one starts, and then where the critical path is, then people will challenge you and say, I want it in 10 days and you can go, I don’t know, I can’t say no to it, because I don’t know where the time scales have come from.

Whilst if you can think about it this way, then you have that really strong evidence to say, actually I can do it in 16, that’s the shortest possible duration it can be. There is a load of maths in this, nothing complicated. Today is not about going through maths, it’s just talking about what the critical path is and what it’s for.

It’s about showing that, it’s evidence piece almost, it’s showing you where you have that wiggle room, and where you don’t have that wiggle room. What I want to talk about though that ties into this is how we get those durations, because you need to establish the durations of all these tasks in order to do the critical path. So estimating is a key part of this, estimating obviously can be done for costs as well, this discussion I want to have here is not exclusively about time scales, it’s about costs as well.

There are a few different types of four estimating techniques that are either top down or bottom up. Top down refers to, if I just go back a slide, couple of slides, there we go. So top down estimating refers to the kind of perspective and bottom up looks as another perspective of how we, the information level we have in order to make an estimate.

So top down is almost looking at the top of this breakdown structure, so high level. It’s something we do early on in the project traditionally, because we don’t have a lot of information, we haven’t broken the scope down into its constituent parts yet. What’s bottom up is we have the detail, we’ll look at the breakdown structure from the bottom, starting with all the small things, working how much all the small tasks cost, and then kind of working our way up, which will help.

So if you know how much all the small tasks costs, then we’ll know in much more detail how much the overall project will cost. But you can’t really do that early on, because you don’t have that level of detail. So top down, bottom up estimating are both the categories, as it were, to try and figure out what those durations would be in that top middle of this network.

So top down approaches them. And imagine most of you have done, probably at least a couple of these approaches, whether you’ve been in projects or not, you’ve probably done some of them. So for example, if I want to know how much something costs, then I might go to an expert.

Someone or it may be that I’m an expert, and I have a load of experience or historic data that I’ve gathered up. I always think of my friend who’s a drystone wall, when I think of this one. He’s done it for 20 years nearly.

He’s got nearly 20 years worth of experience, which says I know how much my rates will be. I know how much materials cost. I know if I get materials from this query, it costs more than I forget it from this query.

I know if I work with this in this supply chain, then I’ve got to worry about this thing, which means I’ll charge more money. If I work in this location, there’s additional risk, because it’s on public property, whatever. He will have experience, and he has a database, and I’ve seen it, it’s on Excel.

Very proud of him for trying. But he’s made this database on Excel that kind of shows him his rates based on his clients. So if he’s working for certain clients, he’ll charge more.

If he’s working for other clients, he’ll charge less, because he’s got experience working with them. So parametric estimating is we have this database of historic experience data evidence that allows you to kind of use a formula almost. If you’ve ever had a quote from a builder, they’ve walked around your kitchen, let’s say, and then gone five grand, they’ve probably done that.

They’ve probably used their experience and their knowledge of their materials and size of the room and everything to create a parametric estimate. The other kind of top-down approach is analogous. Good luck.

It used to be called comparative, that did, but it’s been changed to analogous, just to mess with everybody. So analogous estimating is comparing to a similar project. So if I’m doing a kitchen, for example, then I’d go next door and say, you know, you did your kitchen a year ago, how much was your kitchen?

You’re in a similar size house to me. So you’re comparing to a previous similar project. So parametric is we’ve got a database of experience, lots of different projects, lots of different things, all in the same ballpark, though, a load of data.

Analogous is comparing like for like, is it worth? So how much does your kitchen cost? And it has to be similar enough for it to be relevant.

So it can’t be the kitchen that’s 50 miles away in the mansion. It’s got to be, you know, within a reasonable location. If they did the kitchen 20 years ago, it’s not relevant anymore either.

So it has to be kind of similar enough to the comparative. And that might be one of the ones we use right at the start of a project, actually, when we’re just getting started off, it may be we say, right, how do we figure out how much this project’s going to cost us? Just loosely, just to get us going.

Because we’re not going to know in detail at the start of a project, absolutely not. We can get a fairly reasonable estimate from looking at previous projects that are similar. But we have to accept that every project is different in some way, shape, or form.

And those differences can be tiny, but they can also be massive. And any differences will mean those estimates. We have to acknowledge that, and this is estimating in general, just the word estimate has this in there, is going to be a lot of guesswork in it.

So we have to acknowledge that. So top down is we can start using very early on on the project in theory. We have to accept it’s unlikely to be particularly reliable.

It’s going to get more accurate as we get further into the project. We have more detail, which is when we can start using these bottom-up approaches. So analytical, that’s using that breakdown structure.

Which is kind of what I described earlier on, where we had you look at your breakdown structure, you tend to have been, again, you have to be a little bit way into the project before you can start creating breakdown structures, because you’re trying to understand all the constituent tasks you need to do, which takes time and obviously understanding to develop. But rather than costing up how long does it take to do a kitchen, it’s how long does it take to fit a tile? How long does it take to buy the tiles?

How long does it take to install the tiles? That’s just just tiles. That’s just tasks all around tiles.

And how long does it take to paint the wall? How long does it take to fit the washing machine? How long does it take to fit the sink?

It’s you’re breaking it down into all its individual tasks and then working how much time that task will require on an individual basis. It’s much more refined. It tends to be much more reliable.

But as I said, you probably not be able to use it right at the start of the project, because you need information. You need to have gathered information, not about other people’s projects, but about your own. The other two at the top there, top down rely on previous experiences, past projects.

And the typical is we’re breaking down our project and trying to understand our project. But obviously that’ll take time. So the last type of bottom up is Delphi.

Only careful with this one. This can go down rabbit holes in a way. This is a consensus estimate.

You traditionally might do this when there’s not a lot of evidence in previous projects or people haven’t done it or there’s not enough data on previous projects to use. This relies on a workshop. It’s an estimate by consensus in a workshop effectively.

You gather a group of experts together or stakeholders, usually experts of some kind though, aren’t they? We gather them together and go, right, how long do you think it’s going to take? How long do you think it’s going to take?

And you go around the room and you do it anonymously. You can traditionally, it is done anonymously. It doesn’t have to be.

And then you gather experts from all of them and then you do an average and go, right, this is the situation. And then I always think of when you’re buying a train ticket to London or something, if you go around and ask people, how much does it get to London? You’ll have wildly different answers based on, I haven’t told you where we’re going from yet.

I’ve just said we’re going to London. You’ll get wildly different answers based on those people’s experiences. But if you were to say to them, I want to go on Sunday this week, then you’ll start getting slightly different answers.

If you say I want to go from Sunday on Sunday this week from Bath Spa, then you’ll get better up. So it’s kind of workshopping the estimates. So as you gather more information about your project, you’ll plug more information into this workshop and you’ll find that those estimates should refine over time and reach a consensus where if you kind of get to a point where everyone’s saying the ticket will cost between 50 and 70 pounds, then I know how much I need to budget or if they’re saying it takes an hour and a half, then you know how long it’s going to take.

You have an average through consensus. It takes a bit of time to do that one, but can generate some really strong estimates. So those are the estimating techniques.

And you’ll use those techniques to plug information into your network, your schedule. So I want to whiz through this bit as well. I don’t want to spend ages on this one.

Because of the timing obviously. Single point estimates when you get one value from an estimate. So you may have come across these with someone says that it’s going to take five days to do the kitchen.

Nice and straight forward. But it does mean that people will start taking or making assumptions based on that. If your kitchen takes longer than five days, people are going to be unhappy with you because you said five days.

But again, it’s an estimate. It might be wrong. Three point estimating, but single point estimating is good for budgeting and scheduling because you just said five days, you stick in a schedule.

Three point estimating is taking a best case, a worst case, and a most likely and considering the spread. So it could take three days, might take seven days to do the kitchen. We expect it’s probably less.

Let’s go with some slightly wider values there. So we best case is going to take three days to the kitchen. Most likely is going to take 10 days to do the kitchen.

Worst case, 20 days. So you now have a spread of values, which is more realistic. It considers the uncertainty in an estimate.

It’s better for managing realistic expectations. So for example, if I said it could take up to 20 days and it takes 15, then the stakeholders will be, okay, well, you did say it could take up to 20, but you did recommend it would take 10. But you did say it could take up to 20.

So it’s more realistic expectations around a three point estimate. However, we’ve now got three values. So which one do you use in a schedule?

Which one do you take and put into your critical path? You do an average. The problem with doing an average, a normal average is it balances all the numbers.

They’re all considered the same rating. Whilst one of those is known as most likely. So let’s weigh it in favor of the most likely.

So we do this per estimate, which is per stands for program evaluation review technique. You will never be asked what that stands for in any exam, the APM, or any exam as far as I’m aware, stands for. But if you’re curious, program evaluation review technique.

And there’s the formula. You take one times best case, one times the worst case, and then you add it to four times the most likely. And because you added six numbers to get you to five by six, that gives you a weighted average, which you then take into your schedule.

And it gives you a better, more realistic estimate, which considers the best case and worst case, but converts it back into a number for easy scheduling. What you want to be careful of doing is taking things like worst cases. I do see that a lot where people take the worst case and stick the worst case into a schedule, which gives them a buffer, absolutely gives you a bit of time to play with.

But also, if tasks finish at reasonable times, you end up with a load of dead space. Or you’ll find that people will not commit to projects, and they’ll go, it’s taking a bit longer or costing more than we’d like it to, or less just can it. So you want to be careful of taking worst cases.

Per is a great compromise. And it’s used all over the place, believe me. If you’ve ever heard of Monte Carlo, you may have come across Per.

Monte Carlo, not the place, it’s a technique, by the way. Pesticistic is dangerous if you’re not careful. Obviously optimistic as well, because you don’t want to give best case estimates across the project.

But use those estimating techniques to create the durations in the schedule. Again, nowadays with software, you plug those durations into your schedule based on your manager dependencies, your programming dependencies in, and your schedule create in your Microsoft Project Primavera 6, pretty much automatically. The reason it’s worth knowing some of these things is because estimating changes, reality is a bit more complicated than just a plan.

Plans change inevitably. But also, you can double check things are correct. If you just, as I said earlier on, if you fudge a schedule, then there’s no evidence.

You can’t justify your decisions as easily. Whilst if you provide evidence behind your decision making, you can challenge bad decisions that were made earlier on the project, or challenge earlier estimates. Other estimates we have to accept, because they’re a little bit broader, will probably be wrong.

As we get more information, as we start using analytical approaches, so bottom up estimating, we can know our estimate’s going to get better, but we have to accept until we get right to the end of the project, it is going to be an estimate, which means there’s going to be some guesswork in there. So if you ever do PFQ, or if you’ve ever done PFQ or PMQ, you may have come across this term estimating funnel, which is just a reminder that, and as if you imagine a funnel, estimates get better and better, so they get narrower and narrower and narrower as you get through the project, so you get more and more accurate. You don’t want to just leave the estimates at the start and never estimate again.

If you do that, they will be wrong pretty much every time, because they were made without much information. Cool, right, that’s that bit done. So let me just move Zoom back over to my other screen in a second so I can see.

So are there any questions for me from anybody on this? So I’m sitting in the chat either. No?

Okay, cool. Well, there’s another option at the end, so if you’re nervous about speaking up, which life cycle stage? So if you are using the APM language, so that’d be concept definition, deployment, and transition, those four phases, you’re traditionally, analytical really comes into its own in the definition phase.

So in concept, you’ll be probably using more top-down approaches like analogous and parametric, because if you think about when you start off a project, you’ll probably go, well, I need to find, if I can find someone else who’s done it before, or I’ll phone an expert who’s done it in loads of times, something like that. But if you phone an expert and say, I’d like to do my kitchen, and they say, what kind of kitchens do you want? How big is it?

You go, I don’t know, it’s a kitchen. They’re not going to give you a reliable estimate. So analytically, you tend to find, it might start doing it in concept.

You might have started gathering enough information by the end of the business case to start doing an analytical estimating, but typically, you tend to find it really kicks into gear when you start doing those breakdown structures, which is part of your, again, traditionally, doesn’t have to be part of your definition phase, where you’re breaking your project down into constituent parts and doing your project management plan, which is going to be based on your budget, your overall budgets, your overall resource profile, it will all be based on this stuff. So if you ever come on a PFQ or PMQ with us, we will talk about how that kind of fits into this whole creation of things like budgets and stuff. In terms of top down, bottom up estimating definition.

Cool. Any other questions before we move on? Again, again, you can pop questions in the chat anytime, by the way.

So you’re welcome to just stick stuff in the chat, even if we’re, even if I’m in the middle of my spiel or whatever. But as I said, if you want to jump in now, that’s fine. But what do we do?

Don’t move on for now. If you want to have a thing about any questions, there’s another opportunity at the end. As I said, though, you are welcome to pop questions in the chat between, you know, whilst I’m talking.

That’s absolutely fine. All right. I do have the chat open on screen, so I can see questions as they pop up.

Cool. Okay. Resource management then.

So resources are anything we need to use. So that can be anything from people to equipment, to materials, accommodation, whatever we need to deliver the project. And we have kind of two categories of them.

You’ve got consumable and reusable. So consumable resources being things like nails, fuel, bricks, something that’s once you’ve used it, it’s gone. Reusable being things like the car you put the fuel into, the hammer you nail the nail in.

People, depending on their contract can be either or, because if you have a contractor who’s on a temporary contract working in the team, they’ve got a six month contract, then they’re a consumable resource. You can’t use them indefinitely. Whilst if you have a full-time employee who’s working on the project with you, when the project finishes, they can be redeployed onto another project.

They are reusable asset, reusable resource of the organization. And you can reuse them as many times you want in doing, if they’re a permanent employee. So it does depend where people sit.

So we need a schedule in order to understand how we’re going to profile resources. We’ll have done a lot of this as part of our scoping stuff. So there’s a load of work in the scope.

So product breakdown structure, we work out all the products we need. We’ve got our responsibility assignment matrix which is working out which tasks everyone’s going to be doing in terms of the people. But effectively what we need to do is establish where we’re going to need these people on our timeline.

So all the resources on our timeline. So resource allocation is when you’ve got your Gantt charts, you’ll look at the tasks you’re doing. And then again, you should have a fair idea from your scoping stuff, how many people you need for each task, how much material you need for each task, what equipments you need for each task.

And then effectively you’re just assigning it to the schedule. So resource needs to be added to a schedule because you’ll kind of create this ebb and flow almost. You’ll have at the start of the project, might need lots of people to kind of on board and you need to kind of die down as people kind of move on and do something else or there’s not much work being done or there’s less materials needed, whatever.

You’ll tend to find that there’s these peaks and troughs as you go through your project. Based on your timeline, based on the number of tasks you’re doing in parallel, the types of tasks you’re doing, the complexity of the tasks you’re doing, will all indicate how many resources you need at any given time. Though a lot of that should already have been done, prior to your schedule, like to be as part of your scoping.

So we tend to allocate resources to a timeline in what’s called a histogram, the histogram being like a bar chart. So you can see these ebs, you can put them as numbers and everything else, but you tend to want to be, generally speaking, obviously not in every instance, but you generally find that visual communication with a lot of this stuff is very effective for your stakeholders, because it just shows again very quickly, if you’re using bars to show where the peaks and troughs are, it’s going to be very clear to any stakeholders looking at it. I can see that bar is higher than that bar, therefore we need more resources on that day, which probably means more money.

So this also, this resourcing will also feed into our budgeting as well, and this will indicate the ebb and flow when we’re going to need cash and when we’re not going to need as much cash. So allocating resources, you assign resources to your timeline based on what each task needs, so people-wise, material-wise, equipment-wise, qualification-wise, etc. You’ll assign those to the project, and you should have already done a lot of this as part of your scoping, which is not today’s discussion.

If you want to know that, if you’re curious about a webinar on scoping, you can give that feedback to us, we can look at scoping as well. Anyway, resource optimization then is a general term. If you think about what optimizing means, optimizing is making it as efficient as possible, as best as it can be.

There are two techniques I want to talk about that we use to optimize, and then we have smoothing and leveling. So smoothing, and I’m sure I’ve got a picture of it here, I usually doodle these, I always find it easy to draw, but smoothing is when we have our timeline, we’ll look at tasks where there’s total floats, where there’s wiggle room in them. And what we want to be careful of with a schedule is we will have peaks and troughs.

We’ll have a project that’s sort of, lots of people, hardly anyone, lots of people, hardly anyone, lots of people, hardly anyone, all the way through. Now, the problem with that is it’s not particularly efficient. Again, this is what we call optimization, we want it to be efficient.

It’s not particularly effective to bring a load of people on, release them, bring them back, release them, bring them back, because we’ll increase things like duration of tasks, because we now have to catch people up with what they’ve missed out on when they were away. Or it may be that we lose the resources to another project, which is another project that’s running, or a priority project or whatever. If we release them, then the organization will go, you’re not using them at the moment, we’ll shove them over there.

And if that project has a problem or takes longer than expected, we won’t get that resource back. Something, because I used to work in defense, something I saw a lot is I’d release resources from a project, I’d get the same qualification back, so the same skill qualification, same job title, but it wouldn’t be the same person. So all the team dynamic and all that kind of experience and the understanding of my project that we were working on, or our project, was gone.

We had to upskill and catch them up and reintegrate them into the team, so which affects things like dynamic and affects things like morale and progress and stuff. So what we want to do is smoothing, is about using the total float to smooth the peaks and troughs, to kind of make it so that the project is a nice smooth shape, rather than peaks and troughs jagged. It kind of, you bring people on, you keep them as long as we can, and then we release them from the project.

And we use total float to do that. So we move tasks in their total float, because as long as they’ve got floats on them, we can delay a task, as long as we keep it within that total float, and not affect the end date. So smoothing is at the top one.

I don’t need to bring up, close that one second. So you’re keeping your project within the deadline. You’re kind of making, you’re trying to make it so it’s a smooth curve, rather than a jagged, up and down peaks and troughs.

Obviously it’s not always possible to do that entirely, but you want to try and do it as best you can, because it will make the project more efficient. And it will keep the end date intact. It’s where your project is kind of time critical.

It has to be done in time. Let’s try and be as efficient as possible with the resources we have. Bring them on, keep them as long as possible, even if that means jiggling, jiggling some tasks around it, provided we keep the task jiggling within those tasks, total float.

If a task does not have total float, then you can’t move it, unless you want to affect the deadline. Leveling is kind of the opposite, I suppose, in that this one is where we have, the deadline is less of a focus for us. The deadline is obviously going to be important, but it’s less critical.

Instead, we’ll have a resource critical situation, where again, something I saw in MOD a lot, which is we, I wanted 20 people to do a task, and I was given two. There’s no point me scheduling a project where I need 20 people, but I’ve been given two, and then leaving it as it is. There’s just no point, because I cannot achieve the task as they are with two people in the duration I’ve been given.

So if I’ve only got two people to do a task that requires 20, then the task is going to have to take longer. Or I can’t do as many tasks in parallel with each other, as I’d like to. So leveling is, where there’s the horizontal dotted line on that bottom one there, is telling me that is the maximum number of resources our project can afford, is available in the business.

It may be we’ve imposed it on ourselves to try and reduce recruitment costs, or challenges in communication, or team spirit or whatever, there’ll be any number of reasons why there’s a limit on the number of resources available. If we impose that limit on the project, then we can’t have infinite numbers of people. We can’t go above that line, which means something’s going to have to give somewhere else, which means the end dates can be scrapped.

You extend, and this is all done in planning, by the way. This isn’t, you can use this and react to situations to project, but this is all planning. This is all done in the definition phase where you’re planning your project.

You’re trying to work out before it kicks off what the impact of having two people to do 20 people’s job will be on the timeline. And again, you’re setting expectations through that, saying, I found two people, or you’ve given me two people, or they’re the only two people qualified, or whatever. Therefore, it’s not going to take 16 days wherever the project was earlier on, it’s going to take 25.

So you’re setting expectations earlier on by saying if you have this limit on resources, this will be effect on the end date. And again, if you’ve done all the critical path stuff, your estimates are reliable, and you’ve not just made up the numbers, you’ve actually put some work into the estimates, and you’ve got evidence of where you’ve got them from. When your stakeholders come back to you and inevitably say, I want it in 16 days with two resources, not 20, then you can turn around and go, no, here’s why.

And if you’ve done this histogram properly, you can show your stakeholders why. Again, I’m not going to bring up histograms now because they start in the end up looking a bit complicated, but effectively in summary, smoothing is used to smooth out the peaks and troughs, using the total float to move tasks around a little bit, but keeping them within the confines of their float so they don’t extend the duration. So you’re maintaining the project deadline.

But if you’re reducing float, you’re increasing risk. With leveling, the deadline is less of a focus for us, and the resources are more of a key. Or maybe the deadline is important, but the limitation of resources is going to have to affect that.

So we can show our stakeholders, if we only have two people to do a job of 20, then this is how much longer it’s going to take. So you’re showing the impact on the deadline of that limited resource. Again, you’re planning around it.

You’re showing what the schedule would look like with those limited resources. And again, it pushes the decision into the stakeholders ballpark a little bit more. And you’re saying this is the impact of this, of having two people do the job of 20.

So I imagine some of you, maybe a lot of you, have seen Gantt charts. So there is a Gantt chart based on this one here. I’ll go along the bottom there.

We’ve got other resources. So that is the resource histogram. Again, I’m not going to go into loads of depth on that.

But it’s a bar chart showing those peaks and troughs. And they’re all across the top there, showing where the critical path is, showing the other tasks on there. The dotted lines, so the red lines are the critical path.

The dotted, the black lines with the blue letters are your other tasks, and the dotted lines of the total float that each of those tasks has. Along the bottom, we’ve got unsmooth resources, which shows there’s a peak there. So you’ve got GE and two resources required for B there.

That’s showing there’s a spike underneath there. That’s showing what it looks like if I was to smooth the tasks out by moving them along. I would have to move the tasks along.

But I’ve got to keep them within that total float. This is maintaining the end date there. So Gantt chart, obviously a bit neater than that, in reality, is that bar chart turned on its side with each bar representing duration.

And across the top, it’ll be a calendar as well, usually. And there’s level, leveling. Okay, so again, a bit of a visualization, just very loose in that we’ve had to extend the end date there as a result of leveled resources.

Easier to draw up, but just because it’s a webinar. Cool. So this is what I was looking for earlier on.

This is a node. This is the information that goes into these little boxes. The duration is duration of the total float are the main ones.

We need to know the duration for each task in order to create critical path. Total float comes out of the calculations. Again, there is some maths in this, and the math is very straightforward.

But nowadays, computers do it for you. So Microsoft Project does it for you. But if you’re curious, as I said, there is a button, you can find it in there.

So the math, I will quickly wisdom, we have got time, so we’ll quickly whiz through the maths, I think, because we do have 50 minutes left. So there should be time for questions as well. This is more of if you’re curious.

Again, you won’t really need to know this. It’s just a heads up. When I say you won’t need to know this, you won’t need to know it for the exams.

Okay, so if you’re looking at doing PFQ or PMQ, there is no questions in the exam that say calculate the critical path. You used to years ago, not anymore, and I don’t think they’ll go back to doing it because the software does it all for us nowadays. But I personally like to know it.

It’s an interesting little kind of curiosity, I suppose, and it has helped me in the past, where I’ve come across a Gantt chart when I was in MOD or whatever, that I thought was a bit iffy. And then going into the network diagram and seeing this, and then going through and looking at the dependencies and making sure there’s no tasks just floating around, they all connected up, and then looking for a couple of key pieces of information would indicate to me whether the Gantt chart was a bit iffy or not. So I’ll talk about what that information is in just a sec.

So because this is a mathematical look at your schedule, we start with zero. So mathematically, the earliest we can start anything is zero. There’s no calendar on here, there’s no dates on it, it’s purely maths.

So start on zero, and then you add the duration onto that to get the earliest finish to the top right. So we’re working across the tops first. And we’ll just reiterate, you do not need to know the maths for any exam, you’re going to do.

This is purely just, we have time and it’s curious, interesting to know, it can be useful to know I suppose. So what this is telling me is activity A is going to finish at some point on day five. It’s not telling me what time on day five, it’s just saying at some point on day five, task A will finish, which means at some point, if we’re assuming all those tasks in this sequence will start, could start immediately after the previous one.

At the moment activity A finishes, we can assume that that will allow us to start activity B. Again, so activity A finishes at some point on day five, therefore B and C, because they’re both dependent on A, could start at some point on day five. But we can run them concurrently, because they’re not dependent on each other, they’re only dependent on A finishing.

So you do the adding up again, so five plus two for activity B gives us seven, five plus three gives us eight for activity C. Activity D, if you look, there’s two arrows going into it, so activity B and C, both go into activity D there, so D cannot start until both B and C are finished. So activity B finishes on day seven, activity A, C, sorry, finishes on day eight, which means we have to take the highest number when we’re going forward.

So we carry the eight across. And activity E is only dependent on C, so we carry that eight down. So we add them up, there we go.

And again, same, we have two arrows going into activity F, we have choice between D and E, D finishes on day nine, E finishes on day 13, we take the highest number forward, 13, earlier start for activity F, plus the three, that’s where the 16 came from earlier on. All right, so that’s the map, that’s all the math, it’s just some simple addition as you go forward. And just make sure you take the highest number.

The backwards pass will work out where the critical path is for us, which we want to know. So backwards pass, we basically just reverse what we’ve just done. Rather than starting on the left-hand side and wiping to the right, we start on the right and work to the left, and we start on the bottoms rather than the tops.

So backwards pass, later start is the latest, sorry, later start is the latest finish divided by subtracting the duration. So the latest finish will be the same as the earlier start. We’ve said based on our estimates, the project is going to take 16 days.

We don’t want to artificially inflate that duration for no reason, we can do if you want to, but wouldn’t recommend it because there’s no point. You should already build in your, any additional timings or flex you wanted into your estimates, really. You don’t want to fudge it here.

So you carry the earliest finish from the top right of F, put it in the bottom right of F to be the latest finish as well, and then you subtract the duration. So 16 minus three gives you 13. And then you carry that back down the arrows.

So activity D, latest, it can finish is 13. Latest activity, E can finish is 13. So you’re literally carrying the latest start back down the arrows to be the latest finish.

And then you subtract one to activity D. So 13 subtract one is 12, activity E is 13, subtract five is eight. Do the same thing again.

So activity D, carrying that 12 back to activity B and C. But when there’s more than one choice, again, you’re reversing the addition. So you’re taking, you’re doing the opposite, what you did in the forward pass.

You take the lowest number when there’s a choice. So for example, here we’ve got C, has E and D going back into it. So we take the lowest number back into C.

So, and this is the, I want to try to draw your, if you don’t get the maths, this is kind of, that’s fine. You don’t need to worry about the maths. The key thing I think can be useful, if you ever go hunting for this in Microsoft Project, wherever, Primera 6 Monday or whatever, if you ever go looking for these, something that’s worth looking out for is, if they’ve started on zero in the top left, and the very last task has the same number in the top right, in the bottom right, yeah, so latest start and sorry, latest finish, the earliest finish.

If the bottom top rights and bottom right are the same number, so like this one is 16, then you should always have zero in the bottom left of the first task as well. If you don’t, someone’s for something. That’s something I genuinely used to do, when I was looking at Gantt charts, because I didn’t often write Gantt charts, I delegate that to a scheduler.

I would click on the network button in Microsoft Projects, that’s all I used to use, click on the network button, and the first thing I would look for is, if that first task in the sequence has two zeros in it, because if it doesn’t, there’s a problem. Something’s been fudged, something’s, the maths has gone wrong, or a task is out of whack or whatever, something’s not right. So it’s a really good way to check, whether your schedule has been generated correctly.

It could have been done automatically, but again, people do fudge Gantt charts a lot, it allows you to just quickly check that, by just seeing if those two numbers at the very start on the left are the same, two numbers on the right are the same, so zeros and then 16 and 16 in this case, it shows you that the maths should be okay throughout. The last bit then, is you’re comparing the top and the bottom, so the latest start and the earliest start, what’s the difference between them? That will tell you the total flow.

So in this instance, got latest start is zero in Activity A, earliest start is zero in Activity A, the difference between those two is zero, so we pop a zero in the bottom middle. Activity B, latest start is 10, earliest start is five, that’s the difference of five, so we put a five in there, Activity C, difference in five and five is zero. Activity D, difference in 12 and eight is four, Activity E, difference in eight and eight is zero, Activity F, difference in 13 and 13 is zero.

That’s it, that’s where the critical path comes from. I’m not going to go, I think I’ll be careful with this one, because I’m obviously not aware of time. So there is other types of floats, so total float is the amount of vigory we might have on a task before it affects the end date, so if I use up those five days in Activity B there, it will mean that Activity D starts later, so if you look there, Activity B has a latest finish of day 12, because if B finishes any later than day 12, Activity D will be affected, because the latest Activity D can start and still deliver the project on time is day 12.

Activity B has up to five days total floats before it will push back the start of Activity D, because it will finish later. Free float is the amount of wiggle room a task can have before it affects the start of the next task, so to look for that, you’re looking at the earliest finish and the earliest starts of tasks, so Activity D starts on day 8, because it’s taken the highest number for Activity C. Activity B finishes on day 7, so we actually have a day of total float there, sorry, day of free float, I’ve got day of free float, so you have one day of free float, which means that if B can be late by up to one day, and Activity D will still start on day 8, there will be no consequences whatsoever.

Whilst total float is the amount of float the project has as a whole, so if you use up total float in task B, if you use all of that five-day total float in B, it will use up all the total float in Activity D as well, because it’s total float. Whilst free float is, any wiggle room I have on a task before it affects the start of the next task, there’ll be no free, because there’s no consequences, there’s no impact to the schedule. You have to change anything around, you don’t have to adjust start dates or anything.

And there’s just a quick summary of this. So again, it is visual, you don’t tend to find people use these so much anymore to show the schedule, it’s all done on Gantt charts now, but again, they sit behind the schedule. I really like them still, I’m a big advocate for these things.

The questions in the, if you’re looking at doing PFQ and PMQ, the maths is kind of, if you know it, you know it, that’s brilliant. No worries, thank you very much. But for the exam, the test is a little bit different, but for the exam, the questions will be around what it is.

So what makes the critical path, so what components does it have, so that’s things like what’s the total float, what’s the duration, what are the dependencies, what do they mean, what is a dependency. So it’s kind of the questions around what it is and why we do it in the PMQ in particular. The PFQ will primarily be kind of, it’s a multiple choice, so it’ll be stuff like, which of the following best describes the critical path, which of the following best describes the dependency?

It’ll give you prompts with the PMQ, in particular, it’s asking what it comprises of and why we would do it. What it will never do though, and either of those exams is how you calculate it. All right, I thought it’s useful to kind of go through the calculation because people like to know that, again, people are curious about things like that, but generally speaking, it’s mostly about around what it is.

So we’ve talked about dependencies, we’ve talked about what the task comprises of, what’s the information is on a task, we’ve talked about total float, talked about what critical path is, those are the kind of things that they cut the questions in there, either of those exams will be gearing towards. All right. So I’m not going to go through these, I’m going to bring up the slide on them.

Okay, the main one to know is finished to start. That’s the main one to know, that’s where you’ve got to finish one task before we can start the next one. The other three certainly start to finish, I wouldn’t look at personally, start to start is one can’t start until the other has started.

So you can’t start doing this until, so for example, I always just think of my, when I used to work in a shop when I was younger, I can’t start doing the tills until my boss started opening up the shop. As long as my boss has started opening the shop, I can start doing the tills. I don’t have to wait for my boss to finish opening up the shop to start using the tills either, because we can run them at the same time.

Finish to finish would be the other way around. So I thought that my boss can’t close the shop until I’ve finished cashing up the tills would be a finish to finish. So you can’t finish a task until the previous one is finished.

But again, for PMQ in particular, they won’t expect you to know those. The one I’d say you make sure you do know if you are looking to do exams is finished to start. The others are kind of in your back pocket kind of thing.

You may have come across those, they are used these, finish to start and certainly finish to finish are used in scheduling, but you often find people will break tasks into smaller chunks to enable them to do finish to start rather than having start to start to finish to finish. That is just a generalization there. So that’s an awareness slide that one.

Obviously this will be all, this is all recorded. You will have access to this afterwards. So you want to have a read through these properly, you can do.

But going to move on from them because obviously we are finishing up now. Leads and lags, very straightforward. Lag is I’ve got to wait a little bit.

So first coat, two days for it to dry, do the second coat. It’s basically building in manual delay. Lead time is you can overlap a task.

So this one, I can start doing the second task before the first task is finished. And you have a minus number in there that says, in this instance, I can start doing the second coat of paint 30 days before the finish of the first coat. Again, lead times depends how people, again, I usually, I used to break those up a bit more personally to make it easier.

But lag times, I see all the times still. Because you’re artificially building in delay to your project. But that’s it.

Just a quick whiz through that. There’s also a lot more to it if you’re looking at doing PMQ in particular. But in terms of just introduction to, that’s it.

Okay, well, in which case, then I’ll hand back over to Jim to do the final bits then. Thank you very much, everybody. tremendous.

Thank you, Cullen. Thank you for your expertise over the last hour. And thank you everyone for your attendance this morning.

I think Noel Green has been a great session, lots of information. And if you haven’t got any questions that haven’t been answered, then please get back in touch with us after the webinar and just let us know. We’ll try and respond and answer those questions.

Should any of you be looking for the next step in your training journey, or you know someone that may benefit from a training course with ourselves? They’re a fantastic offer at the moment. So we have, by any online virtual classroom or blended course, and receive a second Foundation online course for free.

That offer includes the APM Project Fundamentals Qualification, and also the APM Project Management Qualification. So a little thing on that. So the offer is due to expire tomorrow, the third to first of January.

But for you guys who attend these to the webinar, we’re actually able to extend that offer until the 9th of February. So you’ve got until next Friday. Next Friday, I believe.

Yep, as you got until the 9th of February on that. If you want any more information on that or on anything else, please contact me. My details are on the screen.

So my number is 01270626330, or you can email me as well on jim at trainingbytesize.com. So once again, thank you very much for your attendance. There was a lot of effort put into this webinar.

So hopefully you all found it beneficial. Yeah, have a great day. Thank you very much, everybody.

So that’s it for this episode of ByteSize Project Management. We hope you’ll tune in again soon for another edition. Until then, you can find out more about the certifications and training packages we offer on our website, trainingbytesize.com.

Thanks very much for listening, and we’ll see you again soon.