Advice on Scheduling for my Masters Degree

Alex,

activity critical path and resource critical path (critical chain) may be different.

Please clarify your question. I don’t understand it.

Activity Critical Path is defined by the network logic and time constraints, it does not take into consideration resource limitations at all.



Vladimir

Vladimir



I was thinking in the CPM, you may or may not have fully resource driven activity as a result the activity critical path may not necessary driven by the resource critical path.



Any thoght??



Alex

Alex,

Activity Critical Path is the particular case of Resource Critical Path when resources are unlimited (if their availability exceeds requirements).

Critical Chain takes into account resource constraints.

We call as Critical Path (Resource Critical Path) the longest path (activity sequence) in the schedule that takes into account all project limitations (project logic, calendars, time constraints, resource constraints, supply consraints, financial constraints).

Regards,

Vladimir

Vladimir



Your post kept me thinking whether a Activity Critical Path is always driven by the resource criticial path.



Anythough... Everyone



Alex

Hi Neil,



I think you should consider the topic "Management by Objective"



A lot of planning schedule were generated but the will to achieve what was planned seems none existence. The weekly objective not achieved, the monthly objective not achieve, the three months - six months objective not achieve.



So in your research, try to consider the HOW to achieve deterministic and probabilistic schedule. This may involve a closer look on the real/actual management set-up and philosphy, not the brochure or propaganda materials that construction companies attached in compayny profile to get invitation to bid or proposal.



Cheers,



Charlie

Which approach is better depends on the type of your project, environment, required detail, ....



If your project is in a close environment like in factory and task duration has a low variability (using machine), i suggest deterministic scheduling. I think this is maybe why your company uses deterministic scheduling besides the fact that it is very simple. However, you can read more about the pros and cons of the two methods on the following webpage.



http://www.chachris.com/probabilisticscheduling_files/detervbprobschedu…

good luck with your MSC.

Stephen,

look at http://www.spiderproject.ru/library/tt.doc

In this paper I briefly described our approaches to corporate project management. Risk simulation section is about buffer setting and management that we call Success Driven Project Management (SDPM).

Spider Project calculates Resource Critical Path since 1992.

In 1997 Goldratt called Resource Critical Path as Critical Chain. But it is not easy to calculate and Goldratt did not suggest any algorithms. His concept of drum resource may work in manufacturing but not in projects.

Vladimir,



Indeed, you are correct about both my specifying Resource Critical Path (I tend to assume everyone knows that’s what I mean when talking about a working schedule, but you are correct), and the point about multitasking sometimes being the best solution. Indeed, if the task is not on the Resource Critical Path, it may well be the best solution.



The trouble is, if (as is often/usually the case) the assigned resources are ALL routinely multitasked, it is impossible to know what the true Resource Critical Path would be if NONE were multitasked. So, in practice, the cost of delay due to resource insufficiencies on the critical path are hidden by the multitasking. First, the Resource Critical Path should be determined without multitasking, and then appropriate places for multitasking off the CP can be determined.



But I’m also keen to find out your further elaboration on estimating buffers.

Stephen,

I agree with most things that you wrote except suggested too simplistic approach to estimating necessary buffers. And Critical Path shall be replaced by Resource Critical Path. If you optimized resource constrained schedule and this schedule suggests some multitasking then it is the best solution. I would not state that multitasking is always bad.

Regards,

Vladimir

Hi, Neil.



The best place to apply the reserve/buffer is at the project level, i.e., at the end. Adding reserve to activities increases the likelihood that (through the aforementioned Parkinson’s Law) it will be used.



However, exceptions should be made to add buffers at specific points (which may very occasionally be an individual activity!) where (1) there is a significant risk of a delay, AND (2) a delay will have a significant negative impact on the project.



Examples include:



(1) An interim milestone/delivery/phase review where delayed work might lead to significant customer dissatisfaction.



(2) A merge point, where a delay on one of the input paths might significantly increase cost by such factors as forcing reserved equipment to lie idle or an important condition to deteriorate (e.g., poured concrete to set to a degree that precludes the follow-up work).



But please let me re-emphasize the point I tried to make in the previous post: if the buffer is on the critical path (as it will be if it’s the sink activity), it is crucial to compute its DRAG, to estimate its DRAG Cost, and to try to avoid that cost.



Paul, as to TOC, I think it’s important to recognize that Goldratt’s background was manufacturing operations. TOC has great application to manufacturing, as discussed in Goldratt’s book The Goal. However, his knowledge of project management and PM theory was somewhat limited, and simplistic. For example, good resource assignment and resource leveling practices, IMO, obviate much of the need for his resource buffers. His approach would derail attempts to identify bottlenecks and arrive at optimized staffing levels through the CLUB, as I discussed in the Projects@Work article "Paving the Critical Path" at:



http://www.projectsatwork.com/content/articles/234378.cfm



And the whole buffer/reserve idea, and working to a more aggressive, ASAP, schedule, which he basically claims credit for, had been around and practiced long before he began discussing them. In addition, since he was not aware of DRAG computation, he could not have recognized the importance of DRAG Cost estimates of buffers.



That said, he brought attention to many of these things, and asked some excellent questions. The section of Critical Chain that discusses the costs of multitasking should, IMO, be mandatory reading for every CEO.



However, Paul, since you work in the Power Generation/Nuclear Sector, I’d be very curious as to your thoughts on TOC. Since I have the highest respect for the PM knowledge and practices used in outage management, I’m a bit skeptical as to whether Goldratt would have very much to teach you.

Stephen,

It’s interesting that you mention TOC. This is a subject that I have never seen discussed in these forums.

I think most experienced planners include buffers almost intuitively, but rarely show them in the schedule.

This may be an interesting new thread and something I would be keen to learn more about.

Vladimir, you’re absolutely right -- it would!



I think it isn’t discussed because most people dealing with project contracts and control like to pretend that schedule reserve doesn’t exist! And so most contractors don’t "show" reserve in the contract and baseline because if they do, the customer will simply say: "Take that out!"



As we both recognize, this is extremely shortsighted and counter-productive, as not having reserve causes bad decisions, and invisible scope and quality pruning. So good project managers, faced with an impossible situation, build the extra time in anyway, by padding the baseline and adding long "Test & Integrate" activities. But such padding is invisible and uncontrollable, as opposed to specific line items called buffers and reserve. And with "project profit" and "acceleration premiums" rarely recognized and measured, Pakinson’s Law ("Work expands to fill time available.") practically guarantees that the padded time will be consumed.



From a BCWS viewpoint, I think the cost of a buffer would be the "marching army" cost: i.e., the LOE and support resources needed to keep the project going during the extra time, and the overhead-burdens of resources.



P.S. An additional thought: it doesn’t help either that the one approach to project management that DOES emphasize buffers, TOC, tends to disparage the worth of earned value tracking, as though buffer tracking and earned value tracking were mutually exclusive!

Stephen,

it would be interesting to discuss the problems of applying Earned Value Analysis technique to the schedules with the project buffers. In this case traditional baseline schedule does not exist. I wonder why it is not discussed.

Vladimir

Neil,



This subject is far too long to cover in a post, or even three. Some points:



1. Scheduling is not a separate issue within a project -- it should always be driven by tradeoffs with the other requirements: scope/time/cost of the Triple Constraint triangle. And the goal of scheduling (and the other sides)should be to produce the most "profitable" project in terms of value minus cost.



2. There is nothing wrong with probabilistic scheduling in theory, but in practice it’s often implemented with poor understanding of the theoretical base, and fraught with cover-your-posterior padding.



3. The purpose of deterministic scheduling is NOT to generate a detailed working schedule, but a baseline or contractual schedule. The probabilistic schedule reduces risk by adding sufficient schedule reserve so that a deadline that can be reached 50%, or 67%, or 84%, or 97.5%, or whatever percent, of the time can be set. But note: there is nothing magical about these numbers or amount of schedule reserve! If someone really believes that an 84% schedule is really 84%, and not 75% or 67% or 90%, they believe in voodoo. (In addition to which, these numbers vary greatly depending on the risk curve function being used. Sophisticated packages offer user-defined functions for each task, but 99.99% of projects using such software simply rely on a default function for all tasks: either triangular or beta [which can give hugely disparate project estimates].



4. No matter what the baseline schedule is, the working schedule should be more aggressive, with reserve built in (1) at the end; (2) before important milestones; and/or (3)before merge points where delays may be costly. The only reliable way to meet a deadline is to work to a more aggressive schedule. The working schedule is "deterministic", based on a single amount of time budgeted for each task.



5. Schedule reserve is almost always on the critical path, and therefore has both DRAG and DRAG Cost. Know what the DRAG Cost is for all schedule reserve, so you can decide if it’s worth it, and how much you’ll save by avoiding using it.



6. In general, a deterministic schedule is simpler to generate, and can be just as reliable as a probabilistic schedule if an appropriate amount of schedule reserve is added. 10% for a low-risk schedule, 20% for a medium-risk and 30% for a high-risk, and 40% for very-high-risk can give as reliable a schedule as the most sophisticated probabilistic program.



But in many organizations/programs, management is so unsophisticated that the only way to justify the reserve is by using fancy mathematics and names like Gauss and Abraham de Moivre! The voodoo impresses people.



P.S. Neil, although I don’t really deal with probabilistic scheduling, you may find something helpful in my articles at:

http://www.chiefprojectofficer.com/article/135

and

http://www.projectsatwork.com/departments/methods-means/



Good luck!

Neil,

look at http://www.spiderproject.ru/library/tt.ppt and http://www.spiderproject.ru/library/tt.doc

I hope that these publications may be helpful.

Vladimir