Finishing projects on time is very important; but holding yourself accountable to a baseline is only as valid as the change management process you have in place. The definition of “on time” changes based on context and how expectations are managed.

Change happens on projects, and in my experience most of that change is not handled well. When scope increases on the project it only results in scope creep if there is no formal change management in place to update the baseline. As real changes are approved by a valid Configuration Control Board (CCB) and the process around those changes, impacts to scope, schedule, and cost need to be updated in the project baseline.

Here are two scenarios with the inevitable increase in scope as the project progresses:

Scenario 1 – No/poor formal change control

As the project progresses, the customer discovers additional scope that they would like added to the project. The project manager accepts the new scope with the intention of “fitting it in” somewhere. Even if a log is kept that records this additional scope, the customer expectation for delivery date has not changed. They expected the product to be delivered on October 15th. Now when the due date starts getting near, the project is falling behind and either 1) misses the delivery date or 2) cuts corners in testing or other areas to make it on time.

Scenario 2 – Good formal change control

As the project progresses, the customer discovers additional scope that they would like added to the project. The project manager and team work with the customer to fully understand what they are asking for. Additional scope WILL cost more. The customer should decide whether delivering on time is the most important factor (time-constrained project) or if the delivery date can be pushed out to accommodate the additional scope. If the project is time constrained, additional resources (or overtime cost) will be added to the project to finish more work in the same duration.

Working together, the project team and customer do an impact analysis to identify how much additional work is really required, how much longer it will take, and how much more it will cost. Whatever the outcome, the customer expectations have been updated to reflect the NEW baseline delivery date and cost. The CCB can choose to reject the change request and continue as planned, or approve the change request and update the baseline.

————————–
In both of the scenarios above, the same scope was added. In Scenario 1, the project will be delivered late or with an unthoughtful decrease in quality or functionality. Because expectations were never updated, this project is late. In Scenario 2, the project may be delivered later than the ORIGINAL baseline, but because good change control and management of customer expectations is in place, the TRUE baseline has been updated to reflect customer choice and the reality of the project. This project is not late (at least not due to expectation problems).

When you work in aerospace as I do and are working towards a launch date, you must be on time. That is why on a time constrained project it is so important to have effective change management and customer expectations management in place.