Change-about and Fair Play

By Cinda Voegtli

I'm writing my column looking out over the rooftops in the city of Boston. I'm actually taking time away from the office to attend a project management conference! (In this case, ProjectWorld.) In thinking about what to write about this time, I thought that the AHA!s I've had this week might be as valuable to you as they have been to me.

Where did my new insights come from? Well, one set came from a session yesterday. I accidentally ended up in a session on change management. (I have some official duties at this conference; I had about decided to attend the other concurrent session, but my presence was needed in the change management session, so there I was.) Serendipity at its best.

So how, you might ask, could the subject of change management inspire me so much? Certainly, until now every time I've heard that term, I think of BIG COMPANIES. "Change management" is some initiative run by the corporate headquarters office that is big and grandiose and maybe amorphous and nebulous, and at any rate is not part of what I do or worry about every day.


That's the Aha I got yesterday.

Sandra Mobley ( spoke about how to create individual and organizational "change-ability". The project managers in the room were all in the midst of some kind of change in their companies or projects. One person was leading the rollout of new billing and applications to a network of independent car dealers, and came to this conference because of this change session-- she just had a gut feeling that the most risky part of their initiative could be to get the dealers to accept a very new way of running their businesses. She had visions of millions spent on this initiative with no gains (and in fact probably some negative consequences) after rollout. Another person was interested in how to change to culture of his company to get better at project management.

The latter application of change management resonated most at first for me. I've been involved in a number of company efforts to create product development methodologies, introduce coaching of PMs to help them learn on the job etc. Those efforts definitely involved some change. For instance, many individual PMs had to change their perceptions of their roles, and they had to get to the point where they could accept that using more "process" didn't have to kill their technical creativity. Sandra talked about how you have to communicate with people differently as you move through their standard reactions to change:
  • During denial: repeat information, over-communicate
  • During resistance: Listen, acknowledge feelings
  • During exploration: provide training, set short-term goals
  • During commitment: recognize accomplishments, establish long-term goals.
What I realized was that I had actually been using this aspect of change management without realizing it-- and it did work very well. Here's one story:

I was involved with introducing a product development methodology into a company that had lots of technical folks as PMs-- people who were a bit process skeptical to say the least. Here's how the change process worked and how we communicated:

Denial: At first the engineers had about zero interest in the new process. They kept operating "business as usual" and basically did their best to ignore us. The VP of Engineering was excellent during this phase-- he reinforced in emails and monthly staff meetings that he was serious about this and thought it would deliver some great benefit. He further more required that project managers start reporting status to him in his monthly meeting according to the major phases of the new process. He "over-communicated to get the message across.

Resistance: Given the VPs obvious commitment to the program, the team members started dealing with the process- but they always had something to complain about. "this isn't working well for our kind of project." "I don't believe in doing this aspect that way". There was still an overall resistance to changing their way of working. On the software side particularly, the developers complained that the process was written more for the hardware side of the house. They resisted because they couldn't easily figure out how it applied to their projects. So our anwer was to convene a group to do an update to the process definition, with heavy software participation (managers, developers, PMs) to let them state the way they wanted it to work. Our attention to their concerns started to reduce their resistance. They felt listened to, saw their own deliverables in the mix, and worked more diligently to apply the process to their projects.

Exploration: Once the updated process was ready, the most important aspect of our work was to help them use it practically on their projects. With any process, no matter how well defined, individuals always have questions about how to apply it to their situation. We responded with two methods of assistance. We created a quick one-day training course that walked team members through the phases of the process, and required them to determine which deliverables were part of their work, who they depended on for information, who they owed information to, and what the value of those different steps was to their project experience. We also provided on-call coaching assistance to PMs, for document review, meeting facilitation etc. And the VP set goals that the next few projects would be pilots of sorts, to test out the new process on software projects and gauge the results. We provided training and set short term goals.

Commitment: Finally the idea of using this process became more entrenched in the culture. We started monthly meetings of the project managers to give them a discussion forum, and invited the VP to attend. Individual PMs presented successes at those meetings. The VP gave his kudos for the improvements the projects were experiencing, and communicated his the project completion and quality metrics he'd be watching over the long term to make sure the improvements continued. We recognized accomplishments and established long term goals.

So this communication paradigm worked well for us-- and now I realize that I can apply this consciously to a number of different change situations -- to have the best chance of moving people through the above stages to a new way of operating.

This was one part of yesterday's Aha on change management. In a future column I'll address the other one-- how change management is really a key aspect of our project work, how it applies to the outcomes our projects are producing. Until then, think about what you're trying to change, and how you're communicating during the inevitable struggles and transitions-- and hopefully put the above techniques to good use!

©Copyright 2000-2018 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy