Managing Change At The Wrong Level (Part VI)

In previous posts in this series, I talked about how change management is rightly stratified throughout the organization and how each change management process shares certain, very specific structures.

In this post, I’d like to wrap that up by looking at the ramifications of this phenomenon.

To review, we identified that each change management organization at each tier of the organization shares the same functions:

  1. Problem Sensing
  2. Supply/Demand Modeling
  3. Decision Making

Then doesn’t it make sense to embrace that structure and actually create a framework around it?  To essentially catalog and develop a community of practice around problem sensing, and to make that knowledge available to each identified change management office within the organization?

Similarly, if each of the change management offices have to do some form of supply/demand modeling, doesn’t it make sense to catalog the different mechanisms and tools in use, and perhaps even to provide standardized resources and practices around how to model supply and demand?  For instance if one part of the organization has embraced Theory of Constraints, wouldn’t it make sense to educate the other parts of the organization in the same model?

What’s an organization to do?  Why implement a Meta PMO, of course.

Lavinsky_PMOSIG_PMO Fractals_v2.0

The Meta PMO would serve the role of process repository, advisor, and toolmaster for each of the identified structures common to all change management offices, whether they be authorized “PMOs” or change management structures in the ITIL definition of the word.

Tomorrow….back to the technical with a review of specific functionality in the Project Server 2010 portfolio analysis module.

Managing Change At The Wrong Level (Part VI)

3 thoughts on “Managing Change At The Wrong Level (Part VI)

  1. magnus holmlid says:

    Hi andrew! Likes your arrticles! Now. Have question: where does the good old matrix fits into your change management and meta pmo?

    1. Good to hear from you. Last time we chatted, I think I was choking on a fajita in Phoenix. 🙂 I don’t see that a matrix makes any difference. In a matrix organization, you’re still creating a subset of the organization, i.e. the project team. The project team then has to apply change management in terms of identifying shared goals/values, identifying variances, and then identifying how to correct for that. Where the matrix makes things challenging perhaps, is that each individual is bring their own values/goals/culture from their originating tribe (if I could use that term). Hence, until you have shared values, you don’t have consensus on what the common problems are or a consensus around how to prioritize what problems everyone actually agrees exist.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s