I wonder if anybody could set me straight on my query below?
I got a question wrong on Rita Mulcahy's mock exam related to scheduling. According to the answer all schedules should be compressed before they are finalized.
However if you compress the schedule before finalizing as a matter of course then where does they leave you to go if any schedule issues arise while the project is being executed?
I get that you might have to compress a schedule up front in order to meet a client or sponsor imposed deadline but if there is no requirement to do that why compress the schedule? Especially when you considered it has cost and risk implications.
Fast tracking allows for overlapping activities when possible, crashing may compress schedule by crashing activities on the critical path but you are correct it will increase costs and both possibilities add risk. Keep in mind that as the PM, we are expected to manage the cost and risk to bring the project in on a true schedule with no padding. I hope that helps and good luck on the exam! Saving Changes...
PMBoK describes schedule compression techniques in the Develop Schedule section, and states that "crashing is a technique used to shorten the schedule duration for the least incremental cost by adding resources".
The only way I could understand Rita's comment, to crash BEFORE finalizing the schedule, is if there is a time constraint (i.e. final deadline) that forces the PM to assign more resources to different tasks in the original schedule Saving Changes...
unless we didn't know the exact question and the exact answering options this is more like a guessing game ...
Sometimes only one word in the question could impact the correct answer, so please provide the complete and exact question and answering options, that would help guiding you.
Markus Saving Changes...
As a practical rule of thumb - from the real world - what you said is right. A mature organization should never compress a schedule in the earlier phases - or planning processes- because we want to leave this practice to help us deal with contingencies.
The above is based on two conditions:
1. The schedule is done professionally and without hidden buffers
2. The project objectives - if critical and schedule driven - then that could be a choice; assuming management understand by doing so they are increasing the schedule threats Saving Changes...
Sorry for the delay updating my post. Please find the question and answers word for word below
Question: A new product development project has four levels in the work breakdown structure and has been sequenced using the precedence diagramming method. The activity duration estimates have been received. What should be done next?
a) Finalize the schedule
B) Begin the work breakdown structure
C) Compress the schedule
D) Create an activity list
My choice: option(A)
Correct answer: (C)
Explanation: The question is really asking. "What is done after Estimate Activity Durations process?" The work breakdown structure and activity list are done before Estimates Activity Durations. The schedule is not finalized until after schedule compression. Therefore, compressing the schedule is done next.
Thanks for your time giving feedback on this.
Simon Saving Changes...
Definitely no D or B
That leave us with A or C
Based on the question (in the real world) - what is next is to perform the critical path analysis, then we can do compression, levelling, and risk analysis before we can finalize the schedule.
In the PMP exam (not real world); IF ---- IF compression is required, then we do this before finalizing the schedule. However, there is no info here that require OR suggest the need for compression.
However, if this is from Rita's book - the logic she follows is that before you finalize the schedule there are steps and you should not skip them.
Bottom line - this is one of the reason - I am hating PMP questions because in real life - it is not like this. Saving Changes...
in the REAL world I have never seen a bottom-up estimated schedule that would NOT need compression before finalizing it.
Bottom-up estimates tend to be overly padded, most of them being 1 point estimates and not critical chain.
Even if there is no explicit schedule constraint, doing a analogous estimate in parallel almost always tell you the aggregated schedule is too long.
Interestingly, this is not the case with bottom up cost estimates. Saving Changes...
I come from Oil & Gas / Petrochemical and I was in an organization with high maturity of PM practices. We did optimize schedule but not compress unless the project was schedule driven (like shutdown or emergency projects).
Even when we go out to bid - we give the contractors our target date and we ask them to propose based on that + an option with an optimize cost-time schedule; which could mean longer schedule with lower cost.
However, I have worked with organizations where management believe that the schedule is padded so they push for compression. Similarly, project team often inflate the schedule because they know management will squeeze. These are not healthy or mature practices.