Aurora-CCPM Critical Chain Video Timestamp
Table of Contents
00:08 Brief overview of Aurora GUI
00:23 High level orientation
1:08 Importing resources from file
1:12 Flat instead of hierarchical
1:16 Manually constructing resources
1:19 Tree Structure: Labor/space zones/equipment
1:29 Primary resources
1:33 Labor resources
1:36 Space zones
2:29 Resource sets
3:23 Activities Tab
3:27 Template type activities
4:05 Project composition
4:18 Precedence constraints (red)
4:24 Start constraints
4:33 Non concurrency constraints (green)
4:59 Start to start constraints
5:09 Concurrency constraints
5:24 Creating relationships between jobs
5:52 Primary labor type (97109 resource)
6:03 Space zones
6:13 Forward scheduling
6:38 Advantage of forward scheduling
7:10 Changing the backward schedule
7:14 Active/aggressive vs. safe duration
7:40 Computing aggressive/safe duration
7:59 Other attributes
8:13 Constructing a CCPM model
8:19 Step one: schedule in safe mode
8:27 Contingency time
8:40 Assessing schedule
9:01 Aggressive duration
9:50 Two primary uses of safe duration model
9:55 Long term planning
10:04 Notion of model length
10:14 Pinning project buffer to safe duration model
10:35 Additional analysis of safe duration model
10:57 Marking resource contentions (dark blue)
11:23 Explanation of factors influencing start date
12:31 Scheduled results displays
12:44 Spatial plot
13:05 Loading resource contentions view
13:16 Direct relationships
12:25 Resource contentions (green arrows)
13:56 Histogram plot
14:38 Creating CCPM schedule
14:57 Safe baseline
15:08 Caching schedule information
15:20 Rescheduling in aggressive mode
16:23 Running comparison with safe schedule
16:48 Schedule divergence
17:04 Aggressive/safe durations non-proportional
17:27 Finding critical chain
17:35 Critical chain indicates tenth pull
17:51 Resource contention-driven relationships
18:14 Opening second Gantt chart
19:14 Buffering scheme
19:48 Inserting buffers
20:15 Relationship between final feeder elements and feeder buffer
20:45 Impinging on feeder buffer
20:59 Impact to critical chain impacts project completion date
21:08 Setting a desired due date takes advantage of slack time
21:32 Loading in work version of file
22:10 Finished jobs (green)
22:22 High level view (fever chart)
22:36 No project buffer incursion
22:41 Using buffers
23:58 Resumption of control
24:01 Most recent update (red point)
24:06 Additional actuals
24:25 Progress analysis required
24:48 Buffer incursions
25:02 Progress assessment
25:25 Task priority list
25:43 Ideal job order
25:56 Configuring Gantt chart to show priority (right of element)
26:05 Marking Task Complete
26:50 Progress analysis (Critical chain element)
27:39 Updated Tent Pole
28:14 Assigning Tasks
29:54 Work in priority order
Hello, this is Annaka Kalton. I will be demonstrating the creation and utilization of a CCPM model within Aurora today.
Before I get started on the CCPM portion of the demonstration, I will give you a brief overview of the Aurora GUI so that you’re well oriented once we get to the CCPM portion of the demonstration.
First, a high level orientation. On the left, we have the various elements of the current type I have selected. So, in this particular tab, that would be project and the activities or jobs that make up the project. In the middle, I have the properties of my currently selected element and at the right, I have a visual display, in this particular case a PERT chart. We will actually cycle back to the project view because the project and the jobs that make it up depend on the number of the other elements within Aurora. For any resource level schedule, your resources are critical.
In this particular case, I imported my resources from a file,
which is why they are very flat instead of hierarchical in nature.
If I had manually constructed my resources,
it would be set up in a tree structure with my labor in one area, my space zones in another area and my equipment in the third area for example.
In this particular model, my primary resources
are my labor resources
and my space zones.
The space zones reflect the fact that only so many people can be in one area at one time.
Some of the resources may in addition have a calendar associated with them. This is especially common with labor resources and is a very easy way of indicating when work should take place. Aurora will automatically cross reference the calendars in use by the resources required for a given job to make sure that job only work when the requisite resources are available.
In addition, you may also assign a calendar to a specific job or to the project as a whole. Any calendars that are active for that job from whichever direction will be cross- referenced in the course of scheduling.
The resources are grouped into resource sets. The resource sets indicate what resources are interchangeable for one specific context. So, if for example, a given job requests the aft cargo resource set, either of these two space zones will satisfy that particular requirement.
This can be especially handy for modeling personnel because very often, different groups of personnel can do some of the same jobs but not all of the same jobs. So, you can group the different resources differently for different situations. And then you just associate the job with whichever resource set makes sense. Usually, the resource set reflects an attribute associated with the resource but they’re not necessarily attributes that you want to model within the system.
The activities tab would include
any template type activities and in this particular model, I’m not making use of those because again, my data was imported.
I touched on calendars briefly before. The calendars indicate when I can work on various things at certain times. The calendar I currently have selected is a standard three shift five day a week calendar and will be my dominant labor calendar.
In addition, I have various other calendars that I can use either for specific labor resources or for certain jobs that have… They need to be more restricted.
Coming back to my project’s tab, a project is generally made up of a number of activities with a variety of constraints indicating what the skeleton of the schedule should be.
Each of the red links that you see in the PERT chart reflects a single precedence constraint.
A standard finish to start constraint. For example, I would need to finish this job before I start this job.
I also have a couple other types of constraints in this particular model. My green constraints are non concurrency constraints. They indicate that this job cannot take place at the same time as this job but they’re not necessarily expected to be in a given order. So, this one might come first and then that one or vice versa as long as they’re not taking place at the same time.
Also, in this file, I have start to start constraints. So, this job can begin and as soon as it has begun, any of these jobs can also begin.
I have some other types of constraints available that are not shown in this particular model. Concurrency constraints would indicate that the shorter job needs to happen during the life span of the longer job.
I can also make any type of relationship between the start of one job and the start of another job, the finish of one job and the finish of the other job, et cetera in any combination. Now, the things that matter most in this type of model, again, are the constraints and the resource requirements.
Most of these jobs have at least one labor requirement so the 97109 resource is my primary type of labor within this particular model.
And then one or more space zones reflecting the fact that the people working on the job need room in which to work.
There are various other schedule attributes. I will not go into them in detail. I’ll just touch on the most critical of them. First, again, if a particular job needs a specific calendar beyond what would be implied by the resource requirements, you can define a given calendar. The dominant schedule method we’ll be using today is forward scheduling.
This is somewhat different from many CCPM systems, which assume that you will want to backwards schedule. The advantage of this is that as long as you update your CCPM model frequently, the Gantt chart can actually give you some notion of what you’re going to be working when, which can be very valuable if you need to stage certain parts or prepare for the activities in some way not directly reflected by the scheduling model.
I could however change to backward schedule if I wanted to.
The active duration is the one that we’ll be scheduling when we actually go to schedule. And as you can see, it’s currently the same as the safe duration. The safe duration is the duration where I can usually complete a job within that amount of time. The aggressive duration, I can only complete that job maybe 50% of the time within that duration.
In this particular case, the safe duration and aggressive duration have been very carefully computed based on various engineering data so there is not a constant and steady relationship between them as there are in some CCPM models.
The other attributes are primarily concerned with the way in which a job can potentially schedule. I’m not going to go into those attributes in great detail in this particular example.
Now, to go on to the stage of constructing a CCPM model,
the first step of creating a CCPM model is to actually schedule in safe mode.
Later on the whole point of a CCPM model is to take the contingency time, the difference between the safe duration and aggressive duration and pull it together into different buffers.
However, at this stage of things, I just want to get some feel for what my schedules should look like.
If I were to actually work this schedule instead of working to the CCPM task priority list, this is the result I would use.
The durations that we’ll be using later, the aggressive durations, I know I won’t be able to make it every time, whereas theoretically the safe durations, this should look roughly like what I will be working to. The reason I don’t want to do that in the long run of course is because if I genuinely worked to this, any improvement and time I would make would not be helpful in the long run because I wouldn’t be ready necessarily to work the next jobs in line.
And any slide would just propagate through whereas if I expect to work a task priority list, I’ll just work everything as fast as I can.
And my pulled buffers will help indicate what exactly I need to be working.
The safe duration model has two primary uses.
The first is in long term planning because again, it more precisely reflects the model that I would actually be expecting to work to.
And second, it gives me some notion of the length of the model in terms of how I want to stagger my projects out and so on.
In some cases I would actually pin my resulting project buffer to the end of the safe duration model with the expectation that that is in fact when I should finish. I won’t be doing that in this particular example, but that is another potential use for the safe duration model.
Now, I can also do some additional analysis of my safe duration model before I get very deep into the CCPM model. So, to do that, just to give a couple examples, I can load this conditional appearance that actually marks out any resource contentions.
And so now, anything that has to wait for another job to complete because they’re using some of the same resources is marked in this darker shade of blue. So, just to give an example of that, I can see that this is marked in the darker shade of blue. If I open it up and go to the scheduled results tab, I can look at the explanation to see what happened.
So, the start date was affected by forward schedule, restricted by availability of 97109, waiting for this other job, which set the start date to this. This explanation is actually built up in the course of scheduling, so in most cases, it will reflect any predecessors and when they scheduled and then any delay related to resource contention. So this can be very handy before I even get started on the CCPM model in terms of double checking the various resource quantities I have and potentially getting set up to have a more efficient work set‑up by potentially getting more labor, and so on and so forth. I can drill down based on some of this information and determine, for example, that maybe if I hire a couple more guys, I could get the project done faster. That, then, would influence the final CCPM model because it influences my critical chain.
A couple other things before we get to actually creating the CCPM model. I’m just going to go through a couple more of the scheduled results displays that we have to work with.
So the spatial plot is where I would go to actually look at, for example, my space zones or any other resources that do not have a very great quantity, and they’re very handy in that I can just look across and see what jobs are using that resource through time.
Once again, I’m going to load the view that will show my resource contentions, and you can see that I have quite a few contentions going on here.
I can open this diagram shows me the direct relationships with the job I have selected,
and these green arrows indicate resource contention, so I can see very clearly that there are resource contentions going on here. Because of the coloration I had already set up, this is somewhat redundant information, but again indicates that I should open it up and have a look at the explanation if I want more information, and in this particular case, it’s not my labor resource, but a space zone that is preventing things from happening earlier.
Finally, my histogram plot would be my normal plot for looking at pooled resources such as labor. And in this particular view, the black shows the time during which the resource is being used, the blue indicates calendric downtime, and the white indicates available time. I’m actually going to hide my downtime, it will still show up on the plot, but for things where a job starts work before a break and continues work after a break, it will show up across that time span, so it’s a little bit easier to read within this context.
Now that I have a safe schedule, and let’s say I have completed my analysis of the safe schedule and am pretty happy with the way things are looking, this is the point at which I would switch over and start creating my CCPM schedule.
Before I create my CCPM schedule, I’m going to make a snapshot that we can use to compare a little bit later on. So, this will be my safe baseline.
This will go through and actually cache all the information about where things are currently scheduled so that I can run comparisons later on my various plots.
Now, the first thing before I make my CCPM schedule is I need to reschedule in aggressive mode.
This would be somewhat optional if all of my safe durations and aggressive durations were strictly proportional because you would expect my aggressive schedule to be effectively the same as my safe schedule but shrunken down. However, in this particular case, that is not a good assumption so before I go through and find my critical chain and so on, I want to reschedule in aggressive mode.
Now, one quick thing to note, I have various gaps between shifts and also on weekends. As it happens, I have a gap in my summary bar because this weekend happened to occur when nothing had started. In most cases, something starts before the weekend and picks up afterwards. In this case though, this job has to wait for the weekend to finish before it could begin.
So, I have my aggressive schedule and just to get some notion of the impact the difference has, I’m going to run a comparison with my safe schedule.
This white kind of ghostly set of boxes on the right indicate my schedule with safe durations. The boxes on the left indicate the schedule with aggressive durations.
And if I scroll up, you can see that initially, it doesn’t make a terribly significant difference but if I scroll down, it diverges and diverges and diverges until it actually winds up making a very significant difference.
The other thing I want to point out is as I mentioned, because my safe durations and aggressive durations are not strictly proportional within this particular model, it did not simply scale down.
It actually changed the order in some cases. So, it does not make just a simple growing cascade.
- So, now that I have my aggressive schedule, I can go ahead and find my critical chain.
The critical chain indicates what you might consider the tent pole through my schedule. So, for the lifespan of the project, it’s the series of jobs that one after another prevent it from being shorter.
In addition to taking temporal constraints into account, they can also take resource contentions into account. So, although many of these relationships are temporally driven, some of them are in fact driven by resource contention.
Now, because it’s a little bit difficult to see my critical chain scattered through the project in this way, I’m going to open a second Gantt chart and load up a configuration that will let me clearly see my critical chain because it will be easier to follow what’s going on. The other thing I’m going to do is again, hide the downtime so that I don’t get distracted by weekends and things.
So, now, you can clearly see the cascading series of jobs that define the lifespan of my project. You can see that in a couple places, the critical chain is disrupted by the weekend. But aside from that, it is a solid chain through the whole life span of the project. I can’t get my project to schedule in a shorter fashion without shortening one of these jobs within my current schedule configuration.
Now, the critical chain is vital because that is what determines my buffering scheme.
In buffering, I’m basically taking that contingency time, the difference between my safe duration and my aggressive duration and pooling it together to reflect first the contingency time of the project as a whole, that will be my project buffer, and second, the contingency time for the jobs leading up to my various critical chain elements. And those will be my feeder buffers.
So, at this point, I have my critical chain, I can go ahead and insert my buffers.
So, I now have my buffer showing. You can see I have quite a lot of them. My project buffer is here at the end. So, this is the pooled contingency time for the whole project.
If I switch back to my other Gantt chart briefly, and I’m going to hide my snapshot again for the moment. You can see the relationship between the, each final feeder element, and then the feeder buffer. This buffer is protecting the critical chain element that comes after that feeder element, and making sure that it will have enough time to finish.
So, once I start impinging on that feeder buffer, the priority for the impinging job would go up, and I would realize that that needs to be worked, lest it slide all the way through the buffer and start impacting the critical chain.
Because by definition, anything that impacts your critical chain, will actually impact your project completion date.
The other thing worth mentioning, is because I did not enter a specific fence, my project buffer just picks up right at the end of my aggressive scheduled critical chain. If I had set a desired due date, or something along those lines, it would actually scoot out a little further, and allow me to take advantage of any slack time in the system.
Now, at this point, I’m actually going to switch over to an in work version of this file. So, a file that has been partially completed, and gives some indication of how the file would actually be used. So, to do that, I’m going to load this updated file.
So, this version of the file has been partially completed. Let’s see whether we can make that a little bigger.
All of the jobs that are shown in green have actually been finished, so you can see that I only have a little bit of work left in this particular model.
In terms of how I’m doing, the fever chart gives me a high level view of my project progress. So what this would indicate to me, is for a long time, I was actually doing too well.
I had no project buffer incursion, I was getting everything done on time.
The reason that’s not actually good, is the buffers are supposed to be used. In an ideal world, I would basically run up just about at the border between the green and the yellow. Because that reflects fairly steady buffer usage throughout the life span of the project, and I would expect to, then, finish just about with my full project buffer consumed.
If I don’t consume any project buffer, I probably am actually over resourced. I have too many labor resources. I’m not actually expected to meet my aggressive schedule.
So, you can see that things were going, actually, too well for awhile. Then they were more or less getting on track. If I had kept that up for a little bit, I would be in great shape.
But, things went a bit amiss. So, through here, not too bad, easily recoverable. But then something major happened. Perhaps a part was late, perhaps things had to be reworked. The fever chart does not actually tell me what went wrong, it just gives me a high level view of how the project is doing. And clearly, it was in a bit of trouble for awhile.
At this point, though, it’s coming back under control.
The red point indicates the most recent update.
Now, I’ve actually entered some additional actuals, since the file was last updated. That is, I have entered some more job completion information, since the last time I updated the fever chart.
The fever chart does not update automatically every time a job is completed, that would be too frequently to be very helpful, and would result in a great deal of churn and confusion in terms of what you should be working next. So instead, someone has to go in and actually analyze progress, in order for the view to update.
So, I analyze progress, I get a report of my buffer incursions. You can see that a lot of my feeder buffers are, in fact, completely consumed. But my project buffer is in fairly good shape.
And you can also see that the progress I made was pretty considerable. What this probably means is that I not only completed some critical chain activities but I did them a little bit faster even than I was hoping to. So, I was able to make up some of my lost ground.
Now, the fever chart is very nice in that it gives me a general notion of the health of the project but it’s not very helpful in terms of what I should be working on at a given time. The most useful thing for that is my task priority list.
Now, my task priority list shows the order in which I would ideally work the jobs. It is not always possible to work them at a specific time.
For example, I have configured my Gantt chart to show my priority just to the right of each element
and you can see that my number two priority element is actually the successor of my number one priority element. So, clearly, I could not be working those at the same time.
So, I’m going to go ahead. I’m going to use this little short cut to basically say I worked it as I was hoping to work it, using my aggressive duration. But then I’m going to go in, let’s see, the schedule attribute say that the safe duration is about a hundred minutes longer than the aggressive duration. So, just to keep it a little bit interesting, I’m going to say that it is an hour longer than the aggressive duration. So, that gives me something in between the safe and aggressive results.
So, at this point, I’m going to go ahead and analyze progress again. And looking at the fever chart, you can see that it’s both reflecting the bit of progress I made because that was a critical chain element and the fact that it actually slid a little bit and so caused more project buffer incursion. It actually did not do much worse than what I would need to sustain me in the yellow all the way through the end.
It did a little worse though. Probably half an hour would have been OK. Now, you’ll see that this next critical chain element is now my number one priority so that’s what I would normally work first and again, its successor is the one that is the number two priority.
This is fairly common because as you update your CCPM model, there is always a new tent pole and that tent pole is the series of jobs that you need to work in order to try to finish the project on time or hopefully, bring it in a little earlier.
Then there are all the other peripheral jobs. The tent pole will usually be the series with the highest priorities. However, that doesn’t mean you shouldn’t work the peripheral jobs.
So, if I were the task assigner, I would go ahead and assign my number one priority. And then I would basically look down the task list at the next one that I could potentially work that was not in some way dependent on these. Now, the problem with that of course is my number three priority is dependent on my number two priority, et cetera.
But based on the schedule update, I know that all of this stuff here is actually compatible so I could go ahead and work any of these jobs if I have sufficient manpower. They are lower priority but I am going to need to work them sooner or later. Now, in terms of why they are lower priority, they are lower priority because they can potentially slip before they cause me any problems.
So, just to give one example, you can see that this has a successor right here. However, this successor can’t schedule any earlier anyway and so because of that, all of this time which amounts to about a day actually is slack time. It is time in which this particular job can slip before it even potentially starts impacting the rest of my schedule.
So, in general, what happens is any jobs that have that slack time, that have that wiggle room are going to be lower priority because they’re not going to hurt anything if they’re delayed by a bit.
So, again, to use the CCPM information, I would go ahead and work things in priority order and then when I get to the point when none of my high priority jobs are workable because their predecessors are not done, I would then go through and work some of my lower priority jobs to go ahead and get them done before I get the final rush.
This completes this demonstration of CCPM functionality within Aurora. I hope you have found it useful. Thank you for your attention.