Aurora-CCPM Critical Chain Video Timestamp


Table of Contents

00:00    Introduction

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

1:43    Calendars

2:29    Resource sets

3:23    Activities Tab

3:27    Template type activities

3:35    Calendars

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:42    Buffers

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

15:55    Gaps

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

22:33    Problem

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

30:21    Conclusion



00:00             Introduction

Hello, this is Annaka Kalton. I will be demonstrating the creation and utilization of a CCPM model within Aurora today.

00:08             Brief overview of Aurora GUI

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.

00:23             High level orientation

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.

1:08                Importing resources from file

In this particular case, I imported my resources from a file,

1:12                Flat instead of hierarchical

which is why they are very flat instead of hierarchical in nature.

1:16                Manually constructing resources

If I had manually constructed my resources,

1:19                Tree Structure: Labor/space zones/equipment

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.

1:29                Primary resources

In this particular model, my primary resources

1:33                Labor resources

are my labor resources

1:36                Space zones

and my space zones.

The space zones reflect the fact that only so many people can be in one area at one time.

1:43                Calendars

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.

2:29                Resource sets

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.

3:23                Activities Tab

The activities tab would include

3:27                Template type activities

any template type activities and in this particular model, I’m not making use of those because again, my data was imported.

3:35                Calendars

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.

4:05                Project composition

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.

4:18                Precedence constraints (red)

Each of the red links that you see in the PERT chart reflects a single precedence constraint.

4:24                Start constraints

A standard finish to start constraint. For example, I would need to finish this job before I start this job.

4:33                Non concurrency constraints (green)

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.

4:59                Start to start constraints

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.

5:09                Concurrency constraints

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.

5:24                Creating relationships between jobs

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.

5:52                Primary labor type (97109 resource)

Most of these jobs have at least one labor requirement so the 97109 resource is my primary type of labor within this particular model.

6:03                Space zones

And then one or more space zones reflecting the fact that the people working on the job need room in which to work.

6:13                Forward scheduling

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.

6:38                Advantage of 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.

7:10                Changing the backward schedule

I could however change to backward schedule if I wanted to.

7:14                Active/aggressive vs. safe duration

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.

7:40                Computing aggressive/safe 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.

7:59                Other attributes

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.

8:13                Constructing a CCPM model

Now, to go on to the stage of constructing a CCPM model,

8:19                Step one: schedule in safe mode

the first step of creating a CCPM model is to actually schedule in safe mode.

8:27                Contingency time

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.

8:40                Assessing schedule

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.

9:01                Aggressive duration

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.

9:42                Buffers

And my pulled buffers will help indicate what exactly I need to be working.

9:50                Two primary uses of safe duration model

The safe duration model has two primary uses.

9:55                Long term planning

The first is in long term planning because again, it more precisely reflects the model that I would actually be expecting to work to.

10:04             Notion of model length

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.

10:14             Pinning project buffer to safe duration model

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.

10:35             Additional analysis of 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.

10:57             Marking resource contentions (dark blue)

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.

11:23             Explanation of factors influencing start date

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.

12:31             Scheduled results displays

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.

12:44             Spatial plot

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.

13:05             Loading resource contentions view

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.

13:16             Direct relationships

I can open this diagram shows me the direct relationships with the job I have selected,

12:25             Resource contentions (green arrows)

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.

13:56             Histogram plot

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.

14:38             Creating CCPM schedule

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.

14:57             Safe baseline

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.

15:08             Caching schedule information

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.

15:20             Rescheduling in aggressive mode

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.

15:55             Gaps

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.

16:23             Running comparison with safe schedule

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.

16:48             Schedule divergence

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.

17:04             Aggressive/safe durations non-proportional

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.

17:27             Finding critical chain

  1. So, now that I have my aggressive schedule, I can go ahead and find my critical chain.

17:35             Critical chain indicates tenth pull

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.

17:51             Resource contention-driven relationships

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.

18:14             Opening second Gantt chart

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.

19:14             Buffering scheme

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.

19:48             Inserting 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.

20:15             Relationship between final feeder elements and feeder buffer

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.

20:45             Impinging on feeder buffer

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.

20:59             Impact to critical chain impacts project completion date

Because by definition, anything that impacts your critical chain, will actually impact your project completion date.

21:08             Setting a desired due date takes advantage of slack time

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.

21:32             Loading in work version of file

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.

22:10             Finished jobs (green)

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.

22:22             High level view (fever chart)

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.

22:36             No project buffer incursion

I had no project buffer incursion, I was getting everything done on time.

22:41             Using buffers

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.

22:33             Problem

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.

23:58             Resumption of control

At this point, though, it’s coming back under control.

24:01             Most recent update (red point)

The red point indicates the most recent update.

24:06             Additional actuals

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.

24:25             Progress analysis required

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.

24:48             Buffer incursions

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.

25:02             Progress assessment

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.

25:25             Task priority list

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.

25:43             Ideal job order

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.

25:56             Configuring Gantt chart to show priority (right of element)

For example, I have configured my Gantt chart to show my priority just to the right of each element

26:05             Marking Task Complete

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.

26:50             Progress analysis (Critical chain element)

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.

27:39             Updated Tent Pole

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.

28:14             Assigning Tasks

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.

29:54             Work in priority order

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.

30:21             Conclusion

This completes this demonstration of CCPM functionality within Aurora. I hope you have found it useful. Thank you for your attention.