.gif)
Change happens in projects, and most of it isn't handled correctly, as I discovered while studying for project or business analysis professional certification. When a project's scope expands, scope creep occurs only if there is no systematic change management in place to update the baseline. Impacts to scope, time, and cost must be updated in the project baseline as real modifications are accepted by a valid Configuration Control Board (CCB) and the procedure around those changes.
Here are two instances in which the project's scope will inevitably grow as it progresses:
Scenario 1 – No/poor formal change control
As the project advances, the customer realizes that there is more scope that they would like to include. The project manager accepts the extra scope and plans to "fit it in" someplace. Even if a log of this expanded scope is kept, the customer's expectation for a delivery date remains unchanged. The merchandise was supposed to arrive on October 15th. Now that the deadline is approaching, the project is running behind and will either
- miss the deadline or
- take corners in testing or other areas in order to meet it.
Scenario 2 – Good formal change control
As I learned when studying for project or business analysis professional certification, the customer learns new scope that they would like added to the project as the project continues. The project manager and team collaborate with the customer to thoroughly comprehend their needs. Additional scope WILL entail a higher price. The customer must decide whether the most essential issue is delivering on time (time-constrained project) or whether the delivery date can be pushed back to accommodate the additional scope. If the project is time-constrained, extra resources (or overtime costs) will be added to do more work in the same amount of time.
The project team and the customer collaborate to do an impact analysis to determine how much additional work is actually required, how long it will take, and how much more it will cost. Customer expectations have been adjusted to reflect the NEW baseline delivery date and cost, regardless of the outcome. The CCB has the option of rejecting the change request and continuing with business as usual or approving the change request and updating the baseline.
The same scope was added in both of the cases above. Scenario 1: The project will be delivered late or with a rash reduction in quality or functionality. This project is behind schedule because expectations were never updated. In Scenario 2, the project may be delivered later than the ORIGINAL baseline, but the TRUE baseline has been updated to reflect the customer's choice and the project's reality due to strong change control and management of customer expectations. This project is not behind schedule (at least not due to expectation problems).
When you work in aerospace, as I do, and you have a launch date to meet, you must be punctual. That is why it is critical to have good change management and customer expectations management in place on a time-constrained project.
Need more insights on the same? Enroll in a CBAP or PMP Certification Toronto training program today!