Why Change Control Is Important
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.
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.
Trust and When You've Moved Their Cheese
The teams must trust the project manager if they are to work together effectively. If new practices have been introduced recently, it's probably more of an organizational change issue than an issue specific to project management itself. You moved their cheese!
You must establish trust with your teams and stakeholders before pushing them through change. If they are not bought in to you and the change beforehand, you will fail. As I wrote about in "New Project Manager: How to screw up in the first 60 days", flying in, cape waving to 'rescue' your team is not the right approach. It's a good way to screw things up by sending the message that you think the way they have been doing things in the past is stupid.
Tracking At The Right Level
I've also seen this happen when the project manager tries to get too fine-grained in terms of schedule and status updates. My personal opinion is that using details when planning and estimating is good, but trying to have that same low level of detail (especially in a waterfall environment) is going to drive teams nuts.
And frankly, that drives me nuts too.
When you have an agile process like Scrum or Kanban in place, it makes it much easier to go down to these lower levels of detail. This is because you are only worried about being able to visualize the work and make sure everything is getting done....if you try to ask team members to split hours worked across individual tasks, it can become very taxing quickly. Every minute your teams have to spend each day trying to track their time is a minute lost - but more importantly it's frustrating to do!
That level of tracking implies a lack of trust from management, and people start cracking jokes about which charge code to use from the time they leave their desk to the time they get to the meeting.
For example, in our last release one of my teams probably worked a total of 100 or so individual tasks. Most team members had no more than 4 'buckets' to split their time up with.
There is a level of tracking that adds value, and once you go down too deep the value drops off, and the overhead cost increases. Furthermore, the more confusing it is for your teams, the less accurate your time tracking will be.
Change management is tough. On a large and complex project it is a difficult challenge, even with the best processes in place that everyone adheres to in a perfect scenario.
I saw a tweet recently that asked "Why are Change Requests an output of Plan Procurements process, but not of any other planning process?"
I answered with a question....Why doesn't the PMBOK have a dedicated knowledge area for change management?
This is an area that deserves much more attention than it receives. I manage two project teams that are developing 4 subsystems within a very large multi-level and complex project. There are several segments of the project, and when one (say a spacecraft vendor) makes a change it often impacts my teams who are developing pieces of the ground system which will receive, process, and store this information. Everything has to be in line, and when you start crossing contract boundaries it gets really difficult at times.
Even within my own teams, it can be difficult to properly assess the impact of a change. One team decided we should make a change because as far as they knew, this change was only local in scope. The next day I found out one of my other teams was a user of this data and so we couldn't make this change. The impact would have been very high.
Change Management FAIL
As a result of this lesson learned, my team and I are putting some new processes in place. The trick is to make them as lean as possible while still delivering the value of being able to fully understand the impact of change. We'll see how it goes.
As a project manager, you will find yourself coming across 'lessons learned' like this all the time. The question is, what are you going to do about it? Do you shrug your shoulders and say 'Yeah, I hate that. I guess we'll do the best we can to avoid it in the future.'
That's not good enough.
When you find issues like this, talk to people on the team and come up with a solution. Then implement it. Right away.
photo by Chill05 via Flickr