6.1 Employ common methods for project tracking - Video Tutorials & Practice Problems

<v ->When I first started in projects,</v> my least favorite day of the week was the Friday status report meetings. This is where those of us who were involved in projects or starting to run some, would have to walk in and give an update on the latest status of our projects and how they were doing. And the reason I hated these meetings is because, in my heart, I really didn't know. I hadn't learned enough about how to detect the status of the project, what was happening, how was it proceeding. Was no news really good news? I thought so because if I would ask people how things were going, and they would say, "Fine," I didn't know enough to question beyond that or even to understand what fine really meant. So you see, the problem is that, so far, if we go back to our original project lifecycle, we spend a lot of time talking about the conceptualization phase, when we start developing scope management. We've now spent a lot of time talking about the planning phase, where how do we create those plans and schedules to make sure that the project is gonna proceed as we need it to proceed. Now, when we get to the execution phase, the problem isn't so much those initial plans because the plans are done, at least in their workable forms. The problem now is how do we go to the next phase? How do we sequence ourselves from a planning mindset to one of tracking and control? How do we know how the project is doing? What kind of accurate information do we need to collect in order to do this? Well, a very simple project control cycle, and by simple, I mean very simple, only four stages, looks, remarkably, along the following lines, that what we do is we establish some goal. Now the goal may be an overall goal. More often than not, it's some goal for those particular activities, the tasks that are part of our project plan. We measure progress. We find some means to determine how far we've done or what we've done to date, how it's going. We compare that progress to the plan with the actual progress that they've created and then we take action. So if we need to correct a deviation, we step in and correct the deviation. If, Lord willing, we're actually ahead of progress here, or ahead of plan, then don't mess with anything and keep the process going. And so you see what happens is in the simplest form possible, project control really consists of this ongoing, sequential cycle of setting a goal, measuring progress, comparing actual with planned, and taking action when needed. And so think in those terms as we move forward because setting a goal has kind of been what we've done to this point, but you see, point number two there is really the tricky one, isn't it? Because measuring progress isn't always cut and dry. It isn't necessarily a straight forward process. And so we're gonna talk now about some means by which we can accurately measure progress. There's a lot of different ways that we can evaluate the current status of a project, some of them more accurate and more useful than others, and I want us to get a fuller glimpse of these different means by which we can measure progress as a precursor to doing something about it. One of the most common methods for assessing project status at any point in time is what is often called the Project S-Curve. Now I have to explain, briefly, where the s-curve idea comes from. And what I'd like you to do in your own head, if you would, or you could even cycle back to the very first lesson, is go back and take a look at that project lifecycle that I've been talking about so frequently. The project lifecycle was based on a series of spend values across a series of dates. In other words, time ran across the bottom of the screen and then there was some measurement of activity or magnitude of cost along the Y axis. So that was on a period-by-period basis, which gave us that really interesting curved hump that then came back down at the end into determination phase. Suppose, though, instead of looking at it on a period-by-period basis, suppose I looked at it the way you see it on the screen right now, where now I'm looking at cumulative expenditures or cumulative budgets for the project based on my plan that I've created. And what you see there is that that original project lifecycle that starts there at time zero and slowly ramps up through week five, 10, 15, and 20, before taking off, should look very similar to the original project's lifecycle that we looked at before, but when it hits that point of inflection, instead of now getting up high and then starting to ramp back the other way, because it's a cumulative curve, it just continues up before eventually, kind of petering out at the very top. That's where the term the s-curve comes from because you can see it sort of forms as a lazy S, and that s-curve mindset is intended to illustrate for us the idea of the budgetary, cumulative values that the project has spent or has intended to spend over it's life. So, if we have that in place, if we have this cumulative, budgeted costs that we expect and anticipate the project to run for us, the question becomes, how do I actually track using that s-curve? And what you see there with the red line is me actually calculating the cumulative, total cost that we've incurred to that point in time. So you notice with that dotted red line down there, that after week five, we were expected to spend approximately $5,000, perhaps, on that screen and it looks like maybe we've spent $2,000. After week 10, it looks like we were supposed to have spent about $10,000 and we spent, perhaps, $4,000, and so on and so forth. And you can see, what we're doing now is tracking a series of actual costs against the planned costs. And one way, then, we can look at this and say how we're doing at any point in time, is by determining the nature of the variants between the planned and the actual. So we see, after week 25, that we now have a $10,000 negative variance. We've spent $10,000 less than we had originally planned for. Now the interesting thing is, for some of us, when we see that and we see we're $10,000 below the anticipated cost, we might look at that and say, "Well that's good news, isn't it?, we're saving money." Not in a project, not in this situation because a negative variance here implies that we simply haven't gotten up to the point in the project progress where all those activities that we have to pay for have actually taken place. And so a negative variance here isn't the result of us saving money, quite the opposite, in fact, a negative variance is predicated on the idea that we simply haven't progressed far enough in the project to get to the point where we should have spent this amount of money. So if we take that idea and we look at it, we can see that the point approximately there, where we're at the $10,000 variance, if we go back there to the left a little bit and match that red line with the cumulative budgeted cost, the expected value, we are probably, it looks like two or three weeks behind schedule. You see, we should've spent this amount to this point, but we haven't. Now, here's the problem, on the surface, everything I've just said should make sense, should seem logical and rather straight forward, but like anything else, it's not that straight forward because when we start looking at this a little more clearly, we have to ask the question, why are we $10,000 behind? What's the cause of that negative variance? Is it really the case that we are at a negative variance situation because we are behind schedule? We haven't spent that money because we haven't done the activities? Or might there be some other explanation here that's equally valid and, in fact, more accurate? For example, suppose that we were developing a brand new automotive system for the automotive after-market, we're one of the main suppliers for the automotives companies at Ford, so we're developing a new system that we wanna sell to our customers, and we have budgeted, you can see in this situation, $60,000 to complete this over 50 weeks of time, but one of our engineers, very cleverly, went and did some digging and he came up with an alternative means by which we can get a lot of the work done, whether it's stamping work or whether it's CAD work, so we're doing computerated design or some other means by which we have to get the work done, but because of his initiatives, he found a cheaper way to do it, a better software package, an outsourced supplier who can do it for us, something like that. So he's found a means to save us money. Well think about that then, that negative variance you see there may have nothing to do with the actual status of the project. It may be that the project activities are all on track. All we've done is gotten to this point in time and saved $10,000 doing it. That would be good news. But you see, as I'm pointing this out, the s-curve by itself has too many holes in it. It doesn't necessarily interpret for us whether this is good news or bad news. Initially most of us who have been involved in projects see a negative variance and we interpret it as bad news. We're behind schedule. But in fact, that may not be the case. We may actually just be doing things more efficiently and we're right on track. But with the s-curve, we don't know. Another problem with the s-curve is that this is a reactive form of control. Now reactive means, this is the equivalent of what we used to call closing the barn door after the hose has already bolted. So the horse has left the barn and at this point in time, we close the barn door, it doesn't do us a lot of good. Reactive control systems say I have to know what has happened and then I look at and say, "Uh oh, we're behind," or, "Uh oh, we're over-spent, we're in a bad situation. "Uh oh, our quality is failing." I don't have any means to know this in realtime and so it has to happen first for me to look at it and then make some determinations about whether this is good news or bad news. So it's a reactive form of control. S-curves are nice in the sense that they allow us to plot budgetary expectations, how much we expect to spend based on all of our resource costs and material costs and everything else to get those activities done. So it follows the project lifecycle. In that sense, it's a very interesting, very valuable means by which we can track a project. But when you drill down and look at it more closely, you start discovering it's not necessarily conveying the kind of information that's truly going to be useful for us. There's another option for us, instead of looking at project s-curves, which are tracking dollar expenditures over time, and by that, we have to surmise what that means, we can look at milestone analysis. Now milestone analysis says that when the project plan is laid out, we deliberately insert some check points or gated reviews or milestones into that plan, some points where we're going to sort of take a step back and say, all right, as of now, we have completed these stages of the project. So we stamp, sort of, a milestone over the completion of that stage and say, let's take a step and review. So milestones, you can see, are these events or stages that represent some significant accomplishment. So perhaps in the building a bridge, when we get all of the made columns poured and all the rebar completed, all of the concrete done, so they're all finished, all the main columns are in place, that's a point to hold a milestone. The milestone then says the accomplishment is done, let's evaluate, let's make sure all of our stresses are correct, let's make sure there's no cracking from the concrete curing, let's make sure that this was done correctly before proceeding to the next stage in the project. So significant milestone, let's pause for a moment. Milestones can include signals to the team and suppliers. So for example, when we've completed our second milestone, one of the nice things about the milestone is maybe we have suppliers that know that we need the next deliveries for our next phase of the project. So we give them the word, we say, "We've just finished milestone two, "we're gonna need your deliveries on the site "within the next three days, or exactly in three days." That's a milestone and it's a signal. Another thing milestones do and they're very useful for this is motivating the team itself. When I've been involved in projects, particularly lengthy projects, one of the constant complaints I had and one of the complaints I heard in managing projects from people involved in them, my workers, was they very much have a blinker view, they only saw a very small view of the overall project. I would give them a task and I would give them very little context. This is in order to do this, or I need you to do such and such, but they never got the big picture. Consequently, it becomes very hard for project team members to really commit to your project, to really get behind it to get motivated to get excited about it because they don't really see the overall picture. They see their little value added component, but maybe not how it fits into the overall scheme. Folks, that's a mistake and it's a mistake many of us are guilty of making, of just assuming that the workers here are just gonna do their thing and don't take a bigger interest in anything else. Why would we assume that? Think about our own situation, I wanted to know the big picture, I wanted to see how my piece fit into the overall puzzle because it gave me a sense of accomplishment. Likewise, our workers want the same thing and so one nice thing about a milestone is signaling a stage completion. We have got now past the opening point or we've now gotten into this, we've now gotten into this stage, these are points in which we can step back and we can also give signals to our team, this is what we've accomplished. Those signals can be very motivating. So they allow us to sort of get excited again. Another thing that milestones do for us is they offer these reevaluations points. What I mean by this is sometimes, particularly with a lengthy project, we start off with the best of intentions, but think about this, suppose you're working in the electronics industry and you're working on a project and at this point in time, there are no competitors for this project. It's a great idea, it's something that can really set us ahead. And so you start moving down the road with it and low and behold, 20 weeks into your project, your major competitor has just introduced almost exactly an identical project from their own organization. So everything you worked on for this 20 week period is now in danger because of the competitors getting to the marketplace first. What do we do? Well, if we have milestones along the way, places where we can reevaluate what's going on, this would be a perfect opportunity to take a hard look at the project. Number one, is it still viable in light of what our competitor has done? Number two, if it is still viable, why is it viable? What features do we have that they don't have? What are things that we can emphasize that build on or improve or just basically set us apart from what our competitors are doing? Maybe we should kill the project. They beat us to it. Everything we were gonna do, they've done, they've done it better, they've done it first, let's cut our losses and get out of this right now. Any one of those options, let's reorient, let's say, okay, we were going this route, but they beat us there, but we have a lot of time and money invested in this and with a few tweaks, we can kind of aim in a different direction and still capture market share with a slightly different product. Any one of those is viable, any one is a legitimate decision on the basis of that information. So milestones stopping at different way points along the way also allow us a point to reevaluate the status of our project, the status of competition, or the market needs in general. Do we still need to keep doing this? In one of the earlier lessons, I was talking about Dubai and how they've invested billions of dollars in projects and then when the economy went bad, in 2009, 2010, many of those projects were put on hold or canceled outright because they were reevaluated in light of current economic conditions and thought, "This no longer makes sense." We have to understand that milestones offer us a means to continually keep an eye on the prize. Milestones help coordinate schedules. So when I'm trying to schedule workers from different parts of the organization I may not need that marketing person involved across the entire 40 weeks of my project. I may need the marketing person involved early on and then at the back end of the project, but the marketing person needs to have a better idea of where and when their services are best use to me and to the project. Milestones allow me to say, I need you from this point to this point, then I need you from this point to this point, so you're gonna be kept in the loop, as we hit that milestone, you need to be prepared to come back in. As we said, milestones allow us to identify key review gates. What are some key points along the way, before we have to decide on doing it or not doing it? For example, many organizations, one of their key review gates is, first they do a feasibility study, do we have the technology that makes it feasible for us to actually do this? I'm a communications company and the Department of Defense for the United States just comes out with a brand new request for proposals for a new field communications radio for their troops on the ground. Some of the specifications include, it has to have a certain range, it has to be able to pick up certain bandwidth, it has to be rugged so that if I drop this from 20 feet, it can still work. It has to be waterproof. It has to do this, all these different features that are part of the request for proposal. My people bring this back to my company and we look at the RFP and we may say, "Yes, we can do this," or we may say, "We really don't have the capability." So one key review gate there is a feasibility analysis. Let's look at this and see if it's even feasible for us. Let's, then another key review gate might be, we've gone past feasibility, we've built a business case, does this project promise the kind of return on investment we require in our company in order to proceed with it? Maybe the answer is no, and at that point, again, we may say, not viable, don't go any further. So you see, these are just some examples. What are, in your own organizations, what are key review gates along the pathway? Many occur early, but many occur later on because it's a mistake to assume that just because we've given a project the initial go, that we're now content to allow the project continue and continue and continue without stepping in at different points in time downstream to see how we're doing. We'll talk about that more in detail in a few minutes, but the idea here that a project, once it's been initiated, is good to go, is a mistake. Projects have to be maintained, they have to be controlled and evaluated throughout the entire development process. Milestones also help us delineate what we call delineate work packages. Milestones allow us to determine what are the different tasks that have to be done within the bounds of each of the milestones? So maybe one milestone is that feasibility analysis. The next milestone might be getting it to return on investment assessment. So our first set of work packages are all technical, they're all engineering related to do we have the ability, the feasibility to do it? The next set might be all financial and commercial and marketing. We may now have to look at it and say, okay, it's feasible, is it worthwhile? You see, so we use these milestones as a means to decide what are the tasks that have to be done within each stage? Another method for assessing projects and how we're doing with projects is this Tracking Gantt Chart idea. In lesson five, I alluded to this when I was talking about the use of our wonderful Gantt Charts for determining the overall project networks and looking at them from a, what's the critical path, what are the slack activities, what are the ones that are on the critical path, those sorts of things, how long is the project gonna take? Now you see in front of you is an example of a Tracking Gantt Chart from MS project, and this Tracking Gantt Chart is very simple, it's only got five activities here and what I've done is I've said, okay, where do we stand on December 6th? Okay, as of December 6th, you can see, obviously, this is 10 years old. That doesn't matter because the intent is the same, but on December 6th of that date, you can see, I was tracking the activities and on December 6th, activity A, the license agreement, by then, had been 100% completed. Also, you can see that I had determined that B, specification design, was on target, in other words, 61% of it was done to that point in time. Site identification, 82% of that activity had been completed to that point in time. So the nice thing about a Tracking Gantt Chart is it does two things for me, number one, it identifies the critical activities. Remember in our last lesson, lesson five, I said that when you click Tracking Gantt Chart, all of the critical activities will show up in red. Well low and behold, there they are and you can see, of the activities that are still ongoing, activities B, D, and E are considered on the critical path, whereas there's a little bit of slack time in activity C. So one thing a Tracking Gantt Chart does for me is it identifies critical activities. A second thing the Tracking Gantt Chart does for me is it allows me to update the status, the completion status of any one of those activities at any particular point in time. So if I'm a manager and I like to go into my project and assess it's current status every Friday afternoon, right before our status review meetings, this is an opportunity. So I spend Friday morning going around and talking to members of my project team and getting their best update on where they stand with that project. Are your activities being done on time? Are they delayed a day? Are they on target, are they ahead? And I can update my Tracking Gantt Chart to get it right to the current status as we go. So the project status here is we're updating it by linking these task completions to the overall schedule baseline, that calendar. And that allows us track and follow through with the status of the projects. Now, these are useful ideas. When we use either the s-curves or we use the milestone analysis or we use Tracking Gantt Charts, they offer bits of information, but each one of them, in it's own way is a little bit flawed. And so what I wanna do here is to talk about, as I mentioned, some of the flaws ongoing in these sorts of status charts versus an alternative method. If we think about projects, what the big three here, being cost, quality, I call it performance here, and schedule adherence, we see that the original project s-curve that I talked about, the flaw was that all it did was it related how much money we've spent to a particular point in time. So its linkage there was between the cost and the schedule sides of that triangle. Didn't really talk about performance. Tracking Gantt Charts, alternatively, well, they are looking at performance, but they're linking performance to the schedule itself. Nowhere in a Tracking Gantt Chart do we have a sense of how much money has spent to this point in time. The other feature that the milestone analysis, Tracking Gantt Charts, and s-curves all share in common is that problem of reactivity. These are all reactive control methods. So I only find out the status after events have occurred. I only know how things are doing at that point in time when either we're doing okay or, God forbid, there are problems, but I discover the problems after the fact when I actually run one of these assessments. So they're not giving me realtime data and they're not giving me complete data. That leads to our 4th and our final tracking mechanism, the one we're gonna spend the balance of the rest of this lesson talking about, and that's the idea of a concept known as earned value management. Earned value management does several things for us and so we're gonna spend a lot of time talking about earned value, how does it work, what does it do for us, what are the metrics that we need to employ how we can make use of this in our own projects, but one thing out of the shoot to recognize with earned value is a couple things. First, earned value gives us realtime data, unlike Tracking Gantts, unlike s-curves, not only do we have data for where we are currently, but we can use that to run projections forward. So when the boss says to me, not only, "Pinto, what's the status of your project today?" I can tell him, but when Pinto says, "How do you stand then to completion "from this point in time?" I don't stand there staring at him with my mouth open. I actually can generate that data and I can give some realistic assessments moving forward of exactly what's likely to happen from now to the finish line. So one thing is, it gives realtime data, but it allows me to project forward. Another advantage of earned value is this notion that it is the only mechanism that is linking, deliberately, performance, cost, budget money spent, and schedule performance. So quality, how much is being done, where we are in the schedule, and how much the project is costing so far. So it's my first link of all of these items and it's done in a way that allows me to project forward.