Critical path drag coming soon to Asta Powerproject

Valdimir,

I am not sure, nor does anyone explain, how to manage a project using 'time is money.'  Day to day decisions, management and control is not done with the end value in mind,  nor should it be.  As I stated, the end value cannot be accutatly calculated.  In some minor cases thinking of a project in terms of profit might be useful and accpeted.  In most cases not.

Steve writes his books like it is a foregone conclusion that ever PM has missed since the begining of PM when he addresses no real case studies and even cannot disprove my assertion that Drag cost cannot be calculated in the manner he prescribes.  

Therefore, I cannot buy into his concept.  Yes, no one, excpet a few apps,  calculates DRAG.  While I do think it is a useful number to know, I do believe that it is not useful by its self when looking to shorten the duration of a project.  I see this as more of an addition the CPM practice and a than a whole new concept.

I have communicated this to Steve a number of times and it has fallen on deaf ears.  He canot be shown the holes in his theory.

Chris

Chris,

I agree that DRAG is one more useful indicator like different kind of floats. Floats show what happens with the project schedule if an activity is delayed, Drag shows what happens if an activity is shortened. When considering project crashing DRAGs show where to look first.

There is another useful indicator that we call Flex but only Spider Project calculates it, so if you are interested we can discuss it in Spider Project forum on this site.

In our practice the end value is automatically calculated by Spider Project with each project update and when risk simulation is used probability to meet target values is calculated too. Project management decisions are justified by their impact on end value and probability to meet project targets. And top management requires regular reports on expected end values and trends of probability to meet project targets, so project managers cannot miss this. This is not just a theory, this is everyday practice in many companies.

The problem that I meet most frequently is that people manage project cost but do not manage actual expenses. Project schedules include the cost (what will be paid for the job) but not expenses that reflect the real costs of project resources, indirect costs, etc. Actually most people manage their contracts but not expenses, future profits, etc. Good and educated top managers would require this but there is a shortage of wise top managers. If some top managers will read Steve's books maybe they will start to require taking current decisions basing on their impact on overall project and company goals.

If you are interested how "time is money" is modeled in Spider Project start this topic in Spider Project forum.

This is Asta discussion and maybe Ben will tell us how Asta does it.

Best Regards,

Vladimir

Stephen,

I have now read, mostly read, both of your books.  I admit that there were sections I skipped over because I felt I knew the material well enough to focus on the main topics of the books. 

Let me see if I can recap some of the main points.

1.       Every project has a value,

2.       The PM should manage the value of the project,

3.       Delivering the project fast will increase the value of the project,

4.       Activities with the largest DRAG should be looked at first,

5.       There is a DRAG Cost associated with each of the critical path activities,

6.       DIPP should be used to determine if a project should be continued.

7.       You don’t believe in Monte Carlo simulation.

These are the main topics with some sub topics.

So, the reason why I am addressing this with you is two-fold.  Firstly I am about to embark on a doctorate program in Portfolio and Project Management and secondly I wanted to answer your question on the original post, “Why is DRAG not in the PMBOK?”

So, based on my readings of your books I have formulated a reply to your original question looking at the entirety of your work; books and articles.

I will address each topic I listed above in roughly sequential order.

1.       Every project has value.  I would say yes with a ‘but’.  But some are done, as you point out, because we have to.  They still have value, but it is not measurable only the negative consequences of not doing a thing is relevant.  Also, the long term value of a project may be incalculable.  Like you say, the schedule is just an estimate.  The long term value is also just an estimate and therefore the value of delivering a project a day or two or event weeks or months early, or late, is just an estimate.   I worked for Shell Oil early in my career building deep-water oil platforms.  The platforms had a 30 year life.  With discoveries of addition reservoirs and new technologies in oil recovery in addition to large fluctuations in oil prices, there would be no way to calculate the value of the project

2.       Should the PM manage the ‘Value’ of a project?

Should the PM manage to a project value that is incalculable or irrelevant?  Everything we do in life has some value even if just perceived by the person doing the thing.  There is value in me driving to work each day.  Is there more or less value in arriving a minute early or a minute late?  Maybe, but probably not, and it is almost impossible to measure. 

Also managing the any difference in delivery date from the planned date is in the realm of Risk Management.  Late is the cause of risks becoming issues and early is risks becoming opportunities.  So at a project level the PM should manage risks, i.e. conduct good Risk Management.

So, I would say the PM should not manage to the value of the project because 1. That should be the just of the portfolio management team, 2. It is nebulous, 3. If it could be done, how much time should a PM spend on it?

3.       Delivering the project fast will increase the value of the project.

In some instances yes.  In some no.  In some a few days here or there won’t matter to the long-term goals of the project.  It just matters what the project is going to deliver.  The examples you have given in your books are more operational than project and because they are more frequent the risk is low and faster means getting the service back producing cash as fast as possible.  The military and disaster relief examples are where faster means better but even those are operational. 

But in a true project where you are producing new and different products and services, faster means a lack of control and increased risk due to poorly planned deliverables, bad decisions and stressed workforce.  True engineering and design projects are like digging a trench or building a brick wall where extra resources don’t make it go faster. 

4.       Activities with the largest DRAG should be looked at first.

I feel that DRAG is a good number to know.  Should it be looked at first when trying to compress a schedule?  I say no.  If I am trying to compress a schedule, I look at the tasks on the critical path or near critical path that are the longest.  Why, because those are the tasks that were planned the worst.  You mention in your books that a task should be around 80 hours in effort.  If one task is much more than that in effort or the duration is more than say about 3 weeks, the task should be analyzed to determine if it was correctly decomposed from the WBS and can be decomposed more or if the skill set required or the person assigned needs to be revised. 

Once that work is done, the DRAG duration should be small in comparison to the total durations of the tasks.  But, it is a useful number and when used in conjunction with other schedule metrics, can prove to be useful.

5.       There is a DRAG Cost associated with each of the critical path activities.

DRAG cost is a fictitious number. As I explained in posts, the units don’t cancel.  Therefore DRAG Cost in dollars, cannot exist.  If the project is late and there is a penalty, then the penalty is in units of dollars per day late.  If the project is early then the benefit is in dollars per day early.  The units of DRAG are, in your own words, amount to time (days) and activity is adding to the duration of the project.    So, DRAG has nothing to do with late or early.  It is the incremental duration added to the schedule as compared to its parallel tasks.    It goes into determining the total duration and the planned delivery date of the project, but is not related to delivering earlier or later than the planned date.  So, the units cannot be canceled and DRAG cost cannot be calculated, and therefore it cannot detract from the project’s value. 

In calculating the benefit of shorting a task to the project, the calculation you provided, example in Figure 5.10 of Managing Projects as Investments, you calculate the “Improved True Cost.”  In the first line of the table you calculate ITC as $10,000 by subtracting DTC from ITC.  This calculation uses an addition of the ‘DRAG COST’ to get ITC and DTC.  By adding DRAG Cost you are artificiality inflating numbers.  More simply put, I have to spend $20,000 to save $30,000 therefore I have a $10,000 improvement.  No need to add the artificial number to get to the same conclusion.

6.       DIPP should be used to determine if a project should be continued.

This is an easy one.  DIPP is a ratio.  Ratios are good for looks back, not looks forward.  A simple NPV cash flow analysis done in excel or even MS Project we provide a better picture of current state and ‘what-ifs’ of changes in the cost, time or future cash flow of the project.  And, if you want to do a ratio, you can always ration current NPV over baseline NPV. 

7.       You don’t believe in Monte Carlo simulation.

This one puzzles me. An estimate is an estimate, period.  There is a ZERO percent chance of getting an estimate correct if it is a point estimate.  A range of estimate covers unforeseen issues which delay and efficiency issues of individuals doing the work.  I always ask for a three point estimate to cover point estimation errors.

You dispelled the use of Monte Carlo simulation by just calling it voodoo and saying it is not scientific, yet you can include risk and changing critical paths to get a better estimate of schedule and cost and a much better idea of both management and risk reserve needs.  It makes management aware of the probability of completing on time and on budget so that better portfolio decisions can be made.  It seems like you dismissed it as being inconsequential to the field of scheduling.  For someone trying to have new concepts come to the forefront of project management, dismissing this out of hand is disingenuous.

Overall, you have some minor areas of improvement to the field, but overall, it seems like you are attempting to create something out of nothing. 

Chris