change management

Change Control and Managing Expectations

by Josh

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.

{ 2 comments }

The Need for a New Knowledge Area

by Josh

Is the Sky the Limit?

So I’m doing some PMP sample test questions today and ran into one where at the end, additional things were added and the customer is very happy. According to the answer, this project was unsuccessful because the additional features were “gold plating” which wastes time and probably cost. Primarily, I got this wrong because I read “the project has added [this and that]” as the [this and that] = intended product of the project.

But there’s a deeper insight here.

Gold plating. What is it? To me, it’s when you add features or functionality without going through the change process. It’s unapproved scope creep….usually created by the project team themselves when it comes to the term “gold plating”.

Why does gold plating happen? Here is a theory.

A project team member comes up with an idea that will clearly add value
The thought of elevating it to the project manager, sponsor, or customer and going through the change management process is too painful to comprehend
This kind of thing is usually thought of as scope creep, and therefore it is bad
It usually never occurs to the team member that this is a “risk”
If it did occur to them, the word “risk” attached to it would give it a snowball’s chance – even more painful to bring with the project manager
so the team member finds a way to “squeeze it in”
This may mean that other tasks don’t get as much attention as they deserved

In the above scenario, there’s no checks and balances on what adds value or not. So what gets gold plated? Usually only things the team member finds “cool” and enjoys working on. To them, it adds value. Does it add value to the project? No one knows in this underground way of doing it. What if the team member decides to just forget about it? No scope creep, no gold plating. That’s good right?

Wrong! If the team member just forgets about it, the project just lost information about a potentially valuable opportunity.

We need Opportunity Management

In the PMBoK guide, opportunities on a project are dealt with as positive risks within the risk management knowledge area. I believe this is the wrong approach.

In practice, when people hear the word “risk” they immediately think negative
expertise and processes that need to come into play with opportunities versus risks can be very different, although there is definitely overlap with risk management also
A whole range of communication and practices dealing with the rest of the business come into play when you are looking for opportunities
Tools and techniques around quantifying the ROI of a potential opportunity and then seeking additional funding for it come into play
Lessons learned documentation specifically geared towards discovered opportunities
Increased focus and transparency in the process of discovering, evaluating, and executing on opportunities all stakeholders identify while planning, executing, and closing a project.

I mentioned this to Greg Balestrero, CEO of PMI when the New Media Council met with him recently in Denver, CO. He was discussing the need to make positive environmental and social impacts through project management, and I responded with this point. I’m not sure what he thought of the idea, or if that’s even a concern of his. I’m sticking to my guns so far in the call to add Opportunity Management as a new knowledge area in the PMBoK. Maybe it will make the 5th edition.

Think about your own project(s), current or in the past.

Did you or someone else come up with an idea that would have added a lot of value for the customer or business?
Did it get shut down or never communicated because it would have resulted in a change to the project scope?
Do people thus have a fear of speaking up about opportunities they think of while executing projects?

Leave a comment and let’s have a good discussion!

Opportunity Management

The Need for a New Knowledge Area
The Case for Opportunity Management
Effective Opportunity Management for Projects

Next in series

{ 51 comments }

Successful Projects: It’s Not Rocket Science

by Duncan Haughey October 30, 2008 Misc

There is often a misconception that managing an IT project is difficult. Avoiding the common pitfalls of IT project management is not rocket science, it is simply a case of taking some sensible measures. This article identifies 5 killer mistakes of project management and their solutions.

Click to continue…

Project Change Management

by Josh September 30, 2008 Lessons Learned

“My boss read in a magazine that developers using ‘___’ programming language are twice as productive, so he bought us a copy and cut our schedule in half.”

Project Change Management: Why developers need a project manager who can also manage change well, and get buy-in from the team before forcing a change on them.

Click to continue…