Why Change Control Is Important

From the pmStudent Blog
Ranting and raving about project management and systems engineering.

About this Blog


Recent Posts

The Problem with Project Management

The Problem with Project Management

The Problem with Project Management

LinkedIn Recommendations Are Easy

The Catch-22 of Project Management Certification and Experience

Categories: Change Management

I received a question from someone dealing with a discrepancy between how EVM reporting has been presenting progress versus actual progress.

Essentially, the scope and cost of the project has increased, partially through estimation problems and scope changes over time.

However, it appears they are still reporting against the same Performance Measurement Baseline (PMB).

The sooner you can transparently communicate with key stakeholders, the better. 


It sounds to me like what should have happened is a re-baseline with all parties involved so everyone understood the reasons why and you could go get more funding now. If you are using EVM, the forcasts should have been showing a slipping SPI and CPI this whole time, in which case everyone would know there is a problem.

Does re baseline mean:
Drop in progress percent complete, say reporting 80% in revised scenario versus previously reported 90%??
If not, then what does this rebaseline actually mean?

A rebaseline only happens when everyone agrees there has been a significant change in scope, cost, or schedule.

Scope increases should only be accepted by the contractor via a contract modification and/or formal change management process. Do you have a Change Control Board (CCB) consisting of the sponsor, key stakeholders, and project leaders? Ideally, all of these changes in scope would have resulted in a Change Request (CR) to the CCB, and once approved the Performance Measurement Baseline (PMB) is updated. This way you are only working on approved scope and your EVMS has value. That said, baseline changes shouldn't happen for estimates that were just off. They must be from CRs which are tied to a clear change in scope outside of the project's control (new customer requirements, massive unexpected procurement cost differences, new regulatory requirements, etc.)
It's always more painful the later it occurs. At this point if I were in your shoes, I'd have a CR describing every individual reason for a baseline change, work it through the CCB and manage change formally via the CCB from here on out. It may be an "ask for forgiveness" moment right now where you have to be honest and open, admit mistakes humbly, and show the plan to improve going forward.
Posted on: January 30, 2012 03:48 PM | Permalink

Comments (0)

Please login or join to subscribe to this item

Please Login/Register to leave a comment.