Critical Path Quiz

Raphael, wow!   What great discussion!  Let me try to respond to each of your key points:

"As you can see I do not believe in crashing a network with a single click of the mouse"

We are in violent agreement! That is one of the key things that drag (and drag cost!) computation adds: a metric that guides the scheduler to the right decision for crashing, rather than some "expert system algorithm" that's as likely to be the wrong decision much of the time!

"Then in another field you can toggle on and off the activities for which time/cost can be applied. In this way by looking at my critical path I can toggle off those activities I do not want to crash,"

Yes! Crashing some activities, even if the payoff is substantially reduced project duration, might result in unacceptably increased risk!

"I believe in the absence of a defined cost curve the software as default can compute the slope as:

etc.

where each pair of values is grouped by a comma and within each pair the slash will separate the two values, similar to the data entry I use on a software called Pizer Earth for earthwork calculations..."  I am sure you can improve on this initial idea if you believe it makes sense, won't be surprised if you already have."

I'm not sure I can improve on it, as it all sounds very interesting, and a good approach in many cases. But I also agree with your statement: "I believe this simplified procedure or algorithm will not always yield optimum results, perhaps only if all curves are staight lines with a negative slope." Each situation can be very different. One technique that I have used, and describe in my Total Project Control  book, is the development of a second duration estimate for each task: the Doubled Resource Estimate of Duration, or DRED. This is an estimate of the resource elasticity of an activity's duration: how long would the activity take if it had twice the resources? If an activity's normal estimate is 20D, possi ble DREDs would be:

a. 10D (perfectly resource elastic, a rather rare situation especially poutside the construction projects).

b. 12D (somewhat more common, in my experience).

c. 17D (some duration benefit, but often must be purchased at great cost. Often worth it on big drag tasks, though).

d. 20D (not at all resource elastic).

e. 30D (increasing resources causes inefficiencies, such as working on the avionics in the cockpit of an F16).

Again, the DRED is not a perfect tool and is only designed as an aid to the scheduler, but it can help.

"Whether to crash a network or not shall be an option of the resource leveling and performed after the schedule is leveled"

This is a case where I'm not completely in agreement.  My reason is, optimizing a schedule (whether by crashing or fasttracking) BEFORE leveling can have two very beneficial impacts:

1. By pulling the schedule earlier, many resource bottlenecks that delay the schedule when leveling actually disappear! For example, I don't have a hobbit available when I need him on a task in June.  This will be a bottleneck that will force that task out to July when I level.  But if I first optimize, so that the task is pulled in to May, now there is no bottlenecked hobbit and my schedule is accelerated by up to two months!

2. Resource leveling, when compared to the "pure" CPM schedule, has the ability to isolate the delay cost of specific resource shortages. By showing that a delay is being caused exclusively by a lack of a specific resource on a specific task at a specific time, and then measuring the cost of that delay, we justify the additional cost through what the TPC method refers to as the Cost of Leveling with Unresolved Bottlenecks, or the CLUB. I have used that many times on consulting engagements to show the customer that the cost of an additional hobbit will be paid back many times over by avoiding the delay such an insufficiency would cause.

"I believe crashing is of last resort but you will need it when the logic and resources cannot be changed anymore, then at the worst moment you need it, better having some computer assistance than none."

Again, a slightly difference in philosophy. I believe that the value/cost of project time is the great externality of project management.  It is almost always worth a huge amount to have a shorter duration -- to not just avoid finishing "late", but to finish early! Most customers would love this, yet contracts are rarely being written to provide the contractor (or subcontractor on the CP!) with adequate incentive for early delivery. This causes the much-written-of principal-agent problem, which in turn leads to moral hazard and all the law suits, instead of the win-win situation where both customer and contractor are driven by shared incentives.  This, to me, is one of the great failings in the practice of project management.

"Those who have never run the basic CPM computations such as early and late dates, total float and finish float shall at least do it for a couple of times. I learned to do it using the diagrams as you show but with the values empty. This shall be also done with lag values as well as with SS, SF and FF relationships as the rules vary for continuous versus non-continuous PDM. It is good for practice exercise to have the answer but in order for others calculate DRAG some of your advice shall be welcomed"

Yes, I absolutely feel that this is something that a professional scheduler MUST be able to do.  And if their software doesn't do it (and I guess we agree that it should!), then they must be able to do it "manually".

"I am considering the modeling of these costs using separate hammocks that must be defined in a way they are always on a Critical Path. In Spider Project we can cost load linear variable costs with hammocks, yes it got to be proved with a model that works and my desire to have these metrics embedded into the software is to make it easier to get into such a discussion to see how far we can get."

This also sounds very interesting.

"If a day savings by crashing costs more than a day of LDs go for the LDs, this all contractors know. What not everyone knows is that not necessarily payment for LDs limits the Owner to claim for damages for the delay. Better finish on time if you know the delay is going to cost much more than the LDs, better start crashing your schedule."

Even better , finish early!  Optimize the project schedule, bid a shorter schedule with nice incentives for early delivery, and you' can retire when you're still young!  (Unlike me!)

Fraternally in project management,

Steve the Bajan

Hi, Rafael.  Maybe you should have put "spoiler" on your reply, so anyone else who wanted to could have done it manually? :-)

Earlier, you said you'd find it a lot easier to do it in the software than manually.  Actually, with a simple network like this,I suspect it's quicker to figure it out manually than to go to the trouble of entering all the activities and relationships into the software.  (I'll post the answers, along with how to do the computations manually, in a few days.)

However, if one has the whole project network already entered, or if it's a large/complex network, then it's undoubtedly MUCH easier to use the software -- provided you have either Spider Project or the Sumatra MS Project add-on.  So that leads to the question: why doesn't all the other software -- Primavera, Asta, etc. -- do this calculation?  Does someone think that it's not important for a scheduler to know how much time each critical path activity is adding to the project?  Isn't that crucial (critical?) information to know:

1. Up front during planning?
2. During implementation, when trying to do schedule recovery?
3. During post mortem/forensic analysis, to know which changes (technical problems, resource limitations, scope changes, etc.) from the planned critical path schedule to the ABCP resulted in how much delay?

Two weeks ago, I was teaching a class in Chicago to a group of very experienced PMs with a large engineering firm.  When I showed them how the drag analysis highlighted and called their attention to the stuff that was costing them the most time, they immediately saw how it would help them optimize their schedules.

You also wrote: "By the way maybe activity cost slope shall be a predefined field, better than using formulas. It is a useful metrics and in combination with DRAG even more."

I'd actually be very interested to hear more about this.  The corollary concept, drag cost, is the amount of money by which a CP activity is reducing "expected project profit" through its drag.  I have identified about four contributors to this, but am eager to hear about more:

1. The value of the project's product is not available until the project is finished. Thus a mall finishing after the holiday season costs the developer a lot of money.
2. Delay penalties, which cost the contractor.
3. Even before the contract is awarded, a contractor could bid more and be more likely to be awarded the contract if he could finish the project faster.
4. Indirect ("Marching Army") costs of overhead, level-of-effort, supervisory, and opportunity costs (which with many of my clients are often estimated to be about 10% -15% of the weekly burn rate).

Its sounds as though your thought about the activity cost slope is related to this latter.  Again, I'd love to hear more about this.  Have you thought of publishing an article on it?  (You also write very well.)

Fraternally in project management,

Steve the Bajan