Tell me more ×
Project Management Stack Exchange is a question and answer site for project managers. It's 100% free, no registration required.
up vote 3 down vote favorite

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?

share|improve this question

2 Answers

up vote 4 down vote

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.

share|improve this answer
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! – David Espina Aug 19 '12 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' – Stephan Aug 27 '12 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) – Stephan Aug 27 '12 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 – David Espina Aug 27 '12 at 19:41
up vote 3 down vote

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.

share|improve this answer
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). – Wolf5370 Aug 23 '12 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. – Stephan Aug 27 '12 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). – Wolf5370 Sep 3 '12 at 8:14

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.