Please login or join to subscribe to this thread
Not enough information.
A) 1.5% cost increase is relatively small and 2 weeks on top of how long a project?
B) There is nothing to say how the QA program impacts the project and whether the $1M is only on this project.
C) Similar to A. What is the burdened labor rate?
D) What is the impact of the CAD system on the project?
A) Client's approval has affected cost and time of the project, so it is a acceptable cause for rebaselining.
B) No information about the spending will affect project's scope, time, and cost.
C) No information about the delay will affect project time's time and cost. It does not tell whether the delayed work is on the critical path or not.
D) It does not tell the affect of the new system on the project.
baselines are cost and schedule and these change with the approved change.
Changes where the schedule slide is less than the float don't require reconciling the Tier 0 schedule. Smaller changes can be collected for scheduled baseline blockpoints where they can be committed at the same time and the change management overhead can be shared rather than updating the baseline for each change. Otherwise you can get into a situation where by the time you have committed some minor change, some newer change has aldready superseded it so there is no firm baseline to align everyone's plans. You wind up in a constant state of churn.
Do the smaller changes need to be reflected in the next baseline update? Absolutely.
Does each change drive an update to the baseline? In many cases absolutely not.
I would want to understand first why the baseline was justified and what it was for. Where baselines are used it surely makes sense to discard them as quickly as possible because stale forecasts are almost by definition going to be a very poor measure of success.
true that relatively small changes in reality do not trigger rebaselining. Their consequences can be covered by corrective actions or contingencies.
In the given case of this question A is the only answer which somehow reflects on the question.
Besides, the client already approved the change, so now not to reflect this approval in the plan would be a unforced error.
And a delay of the project end date always should be shown in the schedule.
In my mind the Baseline is not a tracking tool. It should represent the initial objectives and constraints applied to the project, and agreed to."Re-baselining" should really be tied in to a revised Project Charter.
When comparing the actual performance to the 'baseline' a scope or constraint change would be used as a reason for a deviation. However, a "re-baseling" basically makes the baseline a tracking tool.
Another consideration here - when "re-baselining" does one apply only the authorized changes or do we include for performance to date? For example: if the schedule has slipped one month AND there is a two-week extension due to a scope change does the revised baseline show a six-week schedule extension? If so, when and if we recover some time, do we baseline again.
Save yourself the headache and only 're-baseline' with a Charter update! Preferably, don't do either.
I agree in principle but I think it's a poorly worded question. I'll elaborate a bit because it may help others with test taking strategies, and some fundamental PM terminology...
When taking the PMP, you must often determine which is the best answer so as a test taker, asking what the question is specifically testing is a good strategy. In this case, it appears to be testing the understanding of a "baseline".
A baseline is the few critical items that form the basis for all other planning, such as the major milestones, and how much money is in different budget categories. I would generally say that if you move the end date, that would usually drive a replan of all impacted events, but in this case both A and C include a cost increase and 2 week completion delay. When taking a test, I'd conclude that can't be the deciding factor or both answers would be correct.
The only information about the project is that it's $10M, so there is really no way to evaluate whether the changes would have to be reflected in the lower level schedules or budget somewhere, or whether they are big enough that they could impact multiple lower level working plans, and would justify resetting the major milestones and top level budget, i.e. "the baseline". If there is float in the schedule or reserve in the budget, they may not, but when I read the question itself, there is no way to determine.
Baselines indeed are used as tracking tools, quote PMBoK 184.108.40.206:
'.. approved changes should be incorporated into a revised baseline'. Tools like MSP provide functionality to set a series of baselines over time.
And, as to another threat here, in my view the charter never changes, but the project management plan carries forward the progressive elaboration as well as substantial changes. I never had a change to a charter in 40 years.
Please login or join to reply