Gary, thanks for the thought. My problem is that I am the farthest thing from a technical genius and Rafael's kind advice was a bit beyond me.

I have the feeling that the problem may have been that the previous PNG image may have been a bit too big, so I am going to try again below and make it smaller.

BTW, I also posted this little quiz on the LinkedIn Discussion Group "Planning & Schedulers and Project Control Professionals", if you want to practice such calculations some more. I am going to post the answers early next week.

Now lets see if the smaller image stays or also disappears...

Nope, still seems to disappear.

Fraternally in project management,

Steve the Bajan

Stephen: Just so you know, I didn't get a chance to do your drag puzzle before the pic disapeared.

This has happened to me before now, too. -rafael's solution seems to work, but I'm going to start a tiopic on the improving PP forum to see if the basic insert image functionality can be made more robust, rather than having to use a workaround.

Cheers,

G

Hi, all. Can anyone tell me why the network diagram and questions I published below disappeared? Did I do something wrong? Is there something I can do to fix it?

Fraternally in project management,

Steve the Bajan

Hi, Gary.

First:

"I’m going to plug your network into P6, so I can compare time taken to answer all your questions using manual DRAG calcs, and also iterations of Primavera automatic scheduling. Probably be a Friday afternoon job."

I'm quite interested in this little test! Good idea. Please let me know how it turns out...

Of course, this exercise is very simple. By the end of one of my graduate classes, the better students would be able to compute the drag for all activities in less than 30 seconds and answer all the other questions in less than three minutes. It's when you have 100+ activities and lots of burst and merge points that it gets to be tough -- er -- interesting. And of course we could not be in more violent agreement that every software package should do the computation -- because when you spend two hours doing it on a large and complex schedule, and then you use that info to optimize the schedule, most of the drags will have changed and you'll have to do it all over again! And this is exactly the sort of operation that computers are designed to handle. so someone should tell Primavera and Asta this.

But drag, and especially its corollary drag cost, is important! And the fact that we don't compute it reflects the fact that project management and scheduling are still in their infancy as disciplines. There is a lot more wrong with the way that projects are managed than the lack of awareness of such a glaringly obvious metric as drag.

"I suspect where we will differ is how we define adequate…"

Yes, I think you've put your finger on it. Technologies change with time, and what would be regarded as a skilled craftsman in one era becomes incompetent in another. I am sure that a 19th century artillery officer might be classified as highly skilled -- but we'd be aghast if we put him in charge of a modern howitzer with no knowledge of computer-based range finding. An even better example might be structural engineers, who did all their analysis "manually", but now wouldn't dream of operating without a computer, which lends precision and accuracy as well as speed. Practitioners did the calculations because they knew that otherwise the bridge or the building would collapse and people would die. Sometimes they made mistakes and people did die (like in Kansas City in 1981).

But our discipline has become too dependent on the software crutch. In structural engineering, the mathematics developed and matured long before the software came along. In scheduling, we have not yet defined projects adequately and so don't understand that inadequate scheduling in hospital construction and pharma and medical devices and potable water well-digging and emergency response and national security, is killing people all over the world because life-saving projects are taking much longer than necessary. But until every project starts quantifying the value/cost of time in both acceleration and delay, scheduling and critical path analysis will remain an inadequately appreciated skill. Instead we will be subjected to pseudoscheduling techniques such as "agile project management" which can only survive because no one is quantifying the cost of time. Let's see a nuke or a refinery outage managed using agile, and we'll watch the company that does it go out of business! Neither agile theorists nor the practitioners could find a critical path with both hands and a mirror, so they invent a process that allows them to avoid all that darn planning and 'rithmetic!

"So before you invented DRAG, were there no competent schedulers in existence?"

A quick correction -- I didn't invent drag. (And by the way, I've stopped capitalizing it -- I just call it critical path drag now). Every project has always had a critical path and every delaying factor on that path has always had drag, and usually drag cost. So drag was a discovery, not an invention. I just discovered its significance and utility and how to compute it.

As far as the competence of schedulers is concerned, it's back to expectations. The best Union surgeon at Antietam lopping off arms and legs undoubtedly saved human lives. Some sawbones were undoubtedly better than others. But would we regard their skill levels as competence nowadays?

Back in the '60s (I'm told!), NASA shops would have networks drawn in pencil all along the corridors, with the computations all done by hand. I suspect those schedulers really knew what they were doing, and were computing drag even if they didn't have a name for it or fully comprehend all its rules of calculation. Twenty-five years ago, schedulers at nuclear power plants were prodigiously fast and efficient, and knew what to do manually because the mainframe software was clunky and user-hostile.

In PM and scheduling, the software came along before both the discipine and its mathematics had matured, and so it omits key concepts like drag, drag cost, true cost, and the cost of leveling with unresolved bottlenecks. Instead, it includes things like SPI, which Raphael pointed out below is seriously flawed. Yet today most practicioners don't know enough to understand these flaws. After all, it must be good --it came out of a computah! Garbage in, gospel out.

Believe me, I have the greatest repect for those who developed critical path analysis, WBS, earned value, resource leveling, etc. -- but our discipline is still in its infancy.  I am convinced that planners 50 years from now will have new techniques and will make fun of what we do today.

And I'm damn sure that they will recognize projects for what they are -- investments whose profits are impacted by the value/cost of scope, time and resource usage -- and they wouldn't dream of not monetizing the impact of time on that investment.

Fraternally in project management,

Steve the Bajan 

Hi Gary

I have just read your impressive check list in thread #10 but I think one essential heading has been missed.

Does the programme cover HSE requirements - particularly over head working.

Best regards

Mike Testro

BTW, Aaron, I see I must have misinterpreted your post. You are new to PP, but you obviously have a GREAT deal of scheduling experience, from your profile. Welcome to PP!

Fraternally in project management,

Steve the Bajan

Stop it Steve- you'll make me blush!

Yes all of the top of my head -I've reviewed so many schedules over the years, that it's almost second nature now. -I certainly find it easier to remember this stuff than my wife's birthday, as she would quickly attest to.

I'm not sure i'd agree with you when you say a planner that doesn't use DRAG calcs is of questionable knowledge / ability, though.

If it wasn't for this website, I would never have heard of them. And even now that i do, I don't use them simply because I don't get to choose the software I use.

Also i refer you to my previous comment about only testing schedules to a minimum acceptable standard. DRAG and it's associated bits and bobs are more of a gold standard to be aspired to, than a minimum standard to be adhered to.

Cheers,

G

Wow, Haytham! Looks like you hit the mother lode of great information and advice! A person could learn something from these guys, and I certainly have! Gary, did you just come up with that list off the top of your head? It’s great, and remarkably comprehensive.

A couple of comments:

Rafael, everything you wrote is accurate: the need for the separate working schedule to “protect” schedule reserve and also your comments about earned value metrics for scheduling are right on the money  – earned value scheduling metrics, as traditionally applied, are totally blind to critical path.

However, that really is more a function of how they are applied than how they could be applied. If a separate baseline for earned value scheduling metrics is used, and placed on the ALAP dates (i.e., the backward pass of the critical path schedule) where there is no float, then the scheduling metrics become critical path aware. It is then also necessary to deny recognition of earned value for schedule progress purposes until the progressing period when the earned value is scheduled to be achieved, except for work that is on the current critical path. (Completing work ahead of schedule on the current critical path shortens the project, so that makes sense. Completing work ahead of schedule on paths with float just gives them more float, and encourages out-of-sequence work just to goose up the SPI.)

This is now getting into some pretty advanced scheduling stuff, but here are some other very helpful techniques that I have used:

1. Has the person who prepared the schedule calculated the drag of the critical path activities? If they haven’t, it probably means they don’t know how to calculate critical path drag, don’t understand its importance, and/or don’t have a software package that will compute it. These should combine to make you suspicious of their scheduling knowledge and abilities.
2. Have they listed the top ten drags in descending order? Is there a situation where, say, the top three are more than 10 days and then there is a sudden drop off to the fourth at 2 days? If so, as Gary put it in his post, are those three long drags justified? And, in cases where two paths with long duration are parallel with other paths that have double-digit float, has the scheduler calculated the drag of those two combined paths? Again, is their combined drag justified?
3. What is the resource loading of activities with large amounts of drag? Do any of them have less than full-time resources? If so, would increasing those resources to full-time reduce the drag?
4. Okay, now here is one very infrequently used tool, but I have found it invaluable in combination with drag (and drag cost!) computation. It’s a metric for estimating an activity’s resource elasticity. It’s called the doubled resource estimated duration or DRED. It’s a secondary duration estimate that’s a bit like a crash duration estimate, except much more comprehensible and useful. Whereas crash duration asks what is the fastest possible time if you put the entire combined United States and Russian armies on the activity (and which you ain’t gonna get), the DRED simply asks the estimator what the duration of the activity would be if the resources on the activity were doubled. Sometimes the answer is that the activity would get longer, or stay the same. Sometimes it’s that its duration would only be decreased by 10%. Sometimes it’s that it would be decreased by 50%. And sometimes it’s that it would be decreased by 50% by adding just one of the activity’s resources, e.g., a second cement mixer. When you examine a schedule and see activities with lots of drag, and then check their DREDs, you will see which ones are resource elastic. You can then talk with the estimator about precisely which specific resources would offer the payoff (it’s sometimes but not always all of them) and see if the compression is both worthwhile and achievable. (Of course, knowing the true cost of the activity [TC = budget + drag cost] is extremely useful here – the true cost of an activity can often be decreased by decreasing the drag cost by more than the budget increases.)

I hope this helps, even if not as much as the posts by Mike, Gary, Aaron and Rafael.

Fraternally in project management,

Steve the Bajan

I like all the points above. Understanding the schedule contract requirements is the most important thing to focus on. I am currently on a job where I am reviewing a contractors scheduler on a monthly basis. One of the tools I use is Scheduler Analyzer. It is a lot like Claim Digger, but offers a little more insight. Some things to watch out for, especially for upcoming claims is:

1. Front loading activities costs in the schedule if the contract requires the schedule to be cost loaded
2. Not fully cost loading the baseline if the contract requires the schedule to be cost loaded
3. Checking for changes in duration types (example fixed duration & units to just fixed units)
4. Checking for changes in activities calendars
5. Logic changes that change crew flow without an explanation why
6. How real the longest path is? Is being created for claims purpose or is it the actual longest path for the project?
7. Changing original durations without a clear explanation why and that original durations are not greater than the contract says. 
8. Changing actual starts/finishes in retroactive periods without a clear explanation why
9. Crashing the schedule with logic ss/ff/leads/lag without a direction to accelerate/recover
10. Change order durations/cost/logic not being inserted correctly in the as built or performance baseline schedules. A big one is the contractor likes change orders to start from the RFI, but in most cases they should start from the change order. Otherwise the contractor can get around to producing RFIs when they feel like it and then later ask for more time. 
11. Checking if manpower on the project is ample enough to meet the project finish date. (Example is an activity on a 7 day calendar actually being performed on a 7 day calendar schedule by a crew?)
12. If a lot of RFIs are occurring early on in the project. That is sure sign the baseline schedule is failing and design needs to be revisited IMMEDIATELY.
13. If the schedule is used for cost, make sure that the method for earning cost is clearly defined and is less subjective. 
14. Activity codes used meet the contract requirements
15. The project management team understands as SOON AS POSSIBLE if the schedule is being manipulated to a high degree. If the contractor gets away with it, then enforcing it down the road becomes a huge issue. 

Ok I hope that helps you get started. I am always here to help if you have a question. 

Aaron Melton

First thing to do is check the contract carefully to see what is says. Different contracts have different rules about what is required of the schedule, and on what basis you can reject.

Second thing to do is draw up a list of tests you will perform on the schedule, in accordance with the contract. Most contracts do not go into any great detail about such tests, so you will likely have to decide for yourself what these tests should be, and what the pass/fail criteria are.

If you are able to do this early enough, you should give this list of tests to the contractor before he submits his schedule, so he knows in advance what you expect from him.

Some tests you might want to include are below.

1. Does the schedule cover the entire scope of the project?
2. Does the schedule reflect all contractual requirements / conditions? (e.g. minimum commissioning period, client approvals, etc.)
3. Does the schedule reflect all local legal requirements / conditions (e.g. environmental permits, town planning laws, etc.)
4. Does the schedule go into enough detail?
5. Are the durations reasonable?
6. If any elements of the structure of the schedule have been defined by the client (WBS, activity codes, etc.), have these been adhered to?
7. Is the sequence of work efficient and practicable?
8. Are all activities logically linked?
9. Is any use of non FS type relationships justified?
10. Is any use of relationship lags justified?
11. Is any use of constraints justified?
12. Have appropriate calendars been used?
13. Is the schedule resource loaded?
14. Is the schedule suitable for EVM?
15. Is the critical path sensible?
16. Is there any time risk allowance / buffer / terminal float? Should there be?
17. Have all client and other external deliverables been included?
18. Does the start / completion / other key dates align with the contract?
19. Are there any obvious resource constraints (e.g. 6 cranes required on same day, when only 3 are available)
20. Are there any obvious space constraints (e.g. civils work blocking access for mech install)

Once you have performed these tests, you should arrange a meeting with the contractor to discuss your findings and give them an opportunity to justify any concerns you have.

This is an important step which many do not follow. Remember it is not your job to tell the contractor how to plan the project. You are only there to endure the schedule submitted accurately reflects how the contractor plans to complete the project. Remember also that the contractor is not necessarily obliged to follow best practise when developing their schedule –you are testing vs. minimal acceptable standards.

Finally you are ready to approve / reject (or potentially approve with comments). If rejecting, ensure you provide a detailed justification with the rejection.

One last point to make is that you should try and be consistent and comprehensive when reviewing schedules. –If you reject a schedule, and the contractor resubmits having incorporated all of your comments then it is bad form to reject the new schedule for a new failing you did not highlight in your first review.