How Changes Ripple Through a Project
From the pmStudent Blog
by Josh Nankivel
Ranting and raving about project management and systems engineering.
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
Agile,
Career Development,
Certification,
Change Management,
Communications Management,
Cost Management,
Documentation,
Earned Value Management,
Education,
Integration and Test,
Kanban,
Leadership,
Lean,
Lessons Learned,
Methodology,
Misc,
Multitasking,
New Project,
Operations,
Planning,
PMP,
Productivity,
Professional Development,
Project Estimation,
Project Leadership,
Quality,
Requirements Management,
Risk Management,
Schedule Management,
Scope Management,
Software,
Systems Thinking,
Tools,
Video,
Work Breakdown Structures (WBS)
Date

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
Posted on: August 21, 2010 10:54 PM |
Permalink
Comments (4)
Please login or join to subscribe to this item
Hi Josh. I'd be interested to hear what process you have come up with. This sounds like the whole programme needs an approach to change requests. In PRINCE2 changes are managed as issues, and they go through the issue management process, being assessed and action plans implemented as a result.
Josh Nankivel
Engineering Project Manager| Apple
Sioux Falls, Sd, United States
Thanks Elizabeth. Our project is very large with multiple levels and cross-contract/agency dependencies and there are several levels of formal change control....the one I discovered is actually a level deeper than our formal boards usually deal with. Usually problems aren't obvious but I think there are some systemic issues that get hidden. I'm hoping this CM process will bring some of these to light and foster early and often communication and understanding regarding change across our subsystems.
-Josh
pmStudent e-Learning
Alex Ho
Localization Program Manager| Autodesk
N.A., Singapore
Josh - you''re right. Change management is often neglected, and team members don''t understand how much it impacts in terms of time, cost and quality....
One of the problems, I often seen, is the authority of the changes... If you need to implement wide-scale changes that involve cross-functional team, you probably see a lot of resistance if you''re not empowered with the authority. That''s because changes can be seen differently in different perspectives, like for PM, this changes can save money/time while cross-functional team will see them as, more work, same output..
I feel that it is important to form a change management team where senior members of each team should participate. Using them to explain to their teams usually bring better results and lesser resistance to the changes. Or, breaking down the changes into stages, where the team can accept lesser work each effort.
Josh Nankivel
Engineering Project Manager| Apple
Sioux Falls, Sd, United States
Absolutely Alex, I have a current example going through one of our established CCBs now that illustrates your point perfectly. It's a change that seemed small at first, but will be impacting at least 7 different segments of our project. Because we have the formal process in place, all the right people are involved with analysis of the impacts.
When the decision is made to approve or reject the change, it will be an informed one.
Update: The lean CM approach for subsystem-level changes I wrote the original post about is progressing nicely. I think we've come up with an approach that works well for everyone without adding too much process overhead at this level. To be clear, this lower level of lean CM is not addressing requirements changes, etc. It is focused on some minute but important implementation details that fluctuate often right now due to external and cross-contract dependencies in our project.
-Josh
pmStudent e-Learning
Please Login/Register to leave a comment.
|
"If at first you don't succeed, try, try again. Then quit. There's no use being a damned fool about it."
- W. C. Fields
|