To set the context for my answers below, we do not use formal EV calculations to report on project performance. Instead, we report progress against scheduled activities and the project budget through a simplified process. We also extend the typical baselining process to include the scope document, the schedule, the budget and the risk response plan. We only change the baseline in response to an approved scope change. When our internal customer and sponsor have approved the change, we update the scope, schedule, budget and risk plans to reflect the approved change. The updated documents than become our new baseline.What magnitude of change results in the re-baselining of a project?
Our re-baselining is typically triggered by a scope change. Any scope change that adds activities to the schedule or increases the budget runs through our change management process. Once the change is approved, the baseline documents are updated and we continue working the project to the new baselines.
How might such a change impact the scope of the project?
As mentioned, at our company it is usually a scope change that impacts the baselines, not the other way around. We don’t typically run into situations where the schedule or the budget change—they are typically driven from the scope. However, in the event of a change in budget or schedule (for example, we are asked to cut 10% from the budget), we would process this just like any other change request. First we would evaluate the impact to the project. Next we would develop a list of the options available to support the request. Third, we would present the information to the change board, and finally we would implemented the approved change. In the example of a budget reduction, one of the options might be extending the duration of the project in order to push out some expenses to the next fiscal. Or we might recommend reducing scope to cut some cost out of the project. We will present the options and our recommendation and the change board either approves or sends us in a different direction. Once the decision is made we update the baselines for the four key documents and move on.
What can the project manager do if the customer does not accept the new baseline?
As described above, on occasion, none of the options presented by the team are acceptable to the change board/sponsor. As a result, we will brainstorm other options. However, no change is made without the approval of the change board. As a result, if the customer (to us it is our internal customer) does not accept the change, we don’t make one. We continue the project as currently approved. This process is probably much simpler for us internally than it would be for a company working with an external customer. For us the process is pretty black and white. If they internal customer wants to add scope to the project, we report back the impact on schedule, budget and risk. Yes, they have the ability to work with us to talk through options, but ultimately, they either accept the changes or they don’t get their new scope. Gotta like that!
What other individual expectations should the project manager manage when re-baselining a project?
When we re-baseline, we go back to each of the stakeholders and communicate the new baselines. They key is to ensure that everyone understands that a change was approved and also understands the impact of that change on the scope, schedule, budget and risks. The project manager is responsible for resetting the expectations of each of the stakeholders to align with the new project baselines.
No comments:
Post a Comment