Sorry, Patrick.  As you have 92 posts here at PP, I figured you would have run across a discussion of critical path drag and drag cost or seen it in the Wiki. But a lot of them have been in the Spider Project forum (as Spider is one of only two packages currently that computes it), so if you don't read that forum, and missed discussions in other forums, you might have missed it altogether.

Here is an article from a 2012 issue of Defense AT&L Magazine that describes critical path drag (and drag cost) and how to compute it in a simple (all FS) network.  The concept of critical path drag, its implications, and how to compute it have been around since my book Total Project Control was published by John Wiley & Sons in 1999. It is the amount of time that an activity or a constraint on the critical path is adding to the project's duration. In the sense that it is a metric of the critical path, it is more important than float (which is, with certain caveats, never on the critical path). The concepts of float and drag are of course related -- but float is (almost) never costing you time (and rarely money), while drag always is.

Here is a quiz on drag computation in a simple network that I posted here at PP a couple of years ago. And here is an article that Bill Duncan, author of the first edition of the PMBOK Guide, published in ProjectsAtWork.com back in 2009.  (He wrote all of it, but was kind enough to include me as co-author because I introduced him to the concept and did the diagrams!)

Critical path drag is important when first planning a project -- but when it's absolutely golden is when the project has slipped, the CP has changed, and you are trying desperately to figure out how to recover the schedule. The metric points you to which items are delaying you most so that you don't go snapping at a 30D CP task which you reduce to 15D by doubling its cost, but only pull in the schedule by one day (because it had only 1D of drag). Much better to attack a 10D activity which has eight days of drag. And the drag cost concept shows you where by increasing resources by $10,000, you can decrease the True Cost of the activity by $50,000 (True Cost = Drag Cost + Resource Cost).

You suggest that it may be an old concept, that I am "simply rebadging old ideas with a sexy new name". Perhaps. That certainly is what I thought when, 20 years ago, I was trying to compress a schedule for a Texas Instruments project and discovered that I was doing something systematic that the software didn't seem to be helping with. After a few months, when I had figured out the "rules" for computing drag (it's actually quite tricky once you get into SS, FF, SF and lags!), I started checking other software packages. None (of Primavera, PROJECT/2, Qwiknet Professional, Artemis 9000, 5000, or Views, Timeline, Project Workbench, Superproject Expert, Scitor, and several others) computed or mentioned anything like it. And that was when I realized that this project management discipline of ours is still in its infancy, and there are many valuable ideas out there waiting to be discovered.

"Monte Carlouses a range distribution and calculates probability but again there is no possibility of a ‘drag’. Depending on durations selections in each run though the critical path may well change."

Actually, Monte Carlos could produce what we might call "probable drag", which would be the mean drag of an activity after the 20,000 or however many simulations. Fifteen years ago, Joel Koppelman, President of Primavera Systems , thought that using Monte Carlo in that way would be a great idea. I was more skeptical -- the "garbage in, Gospel out" phenomenon of Monte Carlo makes me suspicious. But I am not as doctrinaire as most people and there may be value to it.

"All of the above based on standard texts plus a number of new initiatives such as Schedule Density are in the course and the PTMC examination."

I have discovered that it takes a long time for new ideas to disseminate, especially in an arena where people often have a vested (financial) interest in maintaining that they know all there is to know about a subject, and that the software does all there is to do.  I have delivered many seminars, webinars and Symposium white papers for PMI, published many articles, and even spoken at the PMI College of Scheduling Symposium (where Vladimir Liberzon will tell you that no one but him in the audience had ever thought of or heard about critical path drag).  But when the article I linked above was published in Defense AT&L last year, it got quite a lot of attention. It has since been re-published as a chapter in a new book titled Project Management in the Oil and Gas Industry by Osisanya and Badiru (the latter being Chair of the Department of Systems Engineering at the Air Force Institute of Technology in Ohio). And a new article by me titled "Time is a Murderer", on how to use several PM techniques, including WBS, CPM, drag and drag cost in planning interrelated projects in life-saving programs, is being published (again by people from AFIT) as a chapter in a book titled Handbook of Emergency Response due out in August.

"in as far as ‘critical path drag’ goes – if you have invented something new it would be useful to provide an explanation ." 

Two things:

1. No one has invented anything -- every project has a critical path, consisting of work and constraints, that determines its length, and it thus exists whether we choose to plan and manage it or to ignore it. Similarly, every project's critical path has work and constraints that delay completion and that I named drag -- we can compute it and use it or ignore it, but it is there nonetheless. The pharoahs had critical paths and drag on their pyramid schedules. I simply discovered it as an important metric, recognized (some of!) its potential implications and value, and figured out how to compute it in simple networks (very straightforward) and complex networks (much more complicated!).
2. Can you sympathize with the fact that I have been "provid(ing) an explanation" for this for over 20 years? That I have spent thousands of hours writing a book and many, many articles on the subject, and that a simple search on the term "critical path drag" in the "Search" function above would have turned up dozens of discussions on the subject right here in Planning Planet? A search in Google would have turned up even more. If there are courses dealing with critical path drag in Saudi and German and Japanese universities, surely it was reasonable to think that you might know what it is and have included it?

"just say what you really mean and there’s a fair change it is already in the course."

I did say exactly what I meant. I hope it is in the course, and if so, that's great. If it isn't and you want it to be, I'd be happy to help. Lord knows, I have lots of exercises, with answers, that I've developed over the years for my graduate students. And there is at least one Aussie PM consultant, Trevor Rabey of Perfect Project Planning in Western Australia (and a frequent PP contributor), who has been teaching TPC methods including drag for years.

Fraternally in project management,

Steve the Bajan

Patrick, will these courses be teaching how to compute critical path drag, and how to use it to optimize or recover a schedule?

Fraternally in project management,

Steve the Bajan