Is there a difference between change management for scope, cost and schedule? Is the flow of the change management for all three areas the same?
2 Answers
Yes, the flow is the same, because you're not talking about a change to the scope, or the cost, or the schedule, you're talking about change to the project.
Change management (or control) deals with those three in that for every change, all three must be assessed for impact. "How does this change in scope affect my schedule? How does this this delay affect my cost?, etc."
So there's no separate flows or processes for each. Any and all changes need to weighed against the project as a whole for impact, and this includes three mentioned, but also for possible new risk, stakeholders interests, etc.
answered Aug 16, 2012 at 18:45
-
You nailed it. To the OP: it is very important that this is understood. None of those elements changes on its own; it's driven by and is a consequence of project change. If that is not understood, then it opens the door to arbitrary changes to cost and schedule to hide variances, e.g., your overrunning so you submit a change request and get more budget or time. That's taboo! Aug 19, 2012 at 13:05
-
Agreed. However, approval levels (and hence the approval flow) may vary depending upon the impact. While all proposed changes must pass through a change board of some sorts (the SteerCo most likely), changes which need additional funds might need to pass through an 'investment board'– StephanAug 27, 2012 at 18:58
-
@David: how do you handle possible overruns, administratively? Some may be justified. How do you handle the budgetary implications? (Maybe I should start a new question for this)– StephanAug 27, 2012 at 19:01
-
@Stephan: I keep performance management and financial management separate. So while I would not pursue a change to my PMB (performance management baseline) so as not to hide a variance, I would pursue a change to my financial CCV (contract cost value) to cover the overrun, assuming my contract was the type to allow this. After that occurred, I would have a PMB BAC that would differ from my financials CCV, and there is nothing wrong with that. Does that answer? If not, let's pursue a new question and seek others' input, too! David Aug 27, 2012 at 19:41
Your process for change management should be the same regardless of the type of impact. What will vary will be who is allowed to approve a change.
For each of scope, cost and schedule (and also risk, quality, benefits and resources) you should set tolerances up front for the production team leader, PM, project sponsor, steering committee, etc so that decision making devolves to the lowest appropriate level given the priorities, criticality and complexity of the project and corporate culture.
For example, a critical project in a cost-averse company may require steering committee approval for any increase in costs, but the same project may only need PM approval on schedule increases of less than 2 months and project sponsor approval for increases of 2 months or more.
You should still have a single gate-keeper (an individual or committee) through which all change goes through so that the changes can be communicated to stakeholders and the plan can be updated.
-
Whilst I agree in general, one should not forget that not all change is scheduled or dev initiated. There is often need (for all the will in the world against it) for emergency change and problem resolution - especially in business critical systems - this often circumvents stakeholders and gatekeepers (even the PM if support team mainatined).– Wolf5370Aug 23, 2012 at 17:38
-
@Wolf5370 A PROJECT change request is not the same as an application emergency change. Still, an emergency change should still follow a formal process, with an approval before being deployed to production and an after-the-fact review and approval by appropriate management layers.– StephanAug 27, 2012 at 19:07
-
Don't disagree Stephan - often (in callout situations) approval is made by the support analyst called, but (as you state) would have after-the-fact review - sometimes the fix is pulled and replaced and so on. I was merely pointing out that not all Change Management is Project Change Management (the Op and most answers do not clarify) - and although should still follow "a" process, that process may be wholey different from "the" normal Project Change Process. One often triggers the other (in both directions - formalising a fix or reacting to failed change).– Wolf5370Sep 3, 2012 at 8:14