Home » Change Management » Don’t Project Manage Change – Provide A Service!

Consider organizing your project management change effort as a “service” tool. This approach helps reduce resistance and it highlights how we are here to help. For us, it resulted in rapid improvements where previous efforts had little or no impact.

Every six months was a new meetings on how we would changeWe had spent many years trying to get to SEI CMM level 2 (a software management standard). Every six months we would have a new announcement and series of meetings followed by the formation of teams to “achieve CMM level 2.” After six months of trying, we would be stalled and then start the process all over again.

Getting to this new standard was a mandate of the organization and mandated by higher headquarters. The meetings on achieving the standard always talked about what you as a software manager were going to do differently.

The office formed to make this change was finally closed down, and the folks in it were dispersed to various other efforts. One of the small departments that was formed did not want to give up on getting to level two even though it was not strictly part of their charter. On one of those “eureka” days that sometimes happens to one trying to solve a difficult problem, a new approach was conceived.

We went to a friendly senior software development manager and pitched a new notion. We would come in for a few days and assess the project manager’s organization to see how well they met the criteria for the standard. The purpose would be to both do an assessment and also to educate the managers on what the standard looks like and what it means as we went through the standard’s checklist. We would then show the project manager what our assessment found and also make some recommendations on how they could further improve their assessment results. With the assessment we would also offer to come back in six months and do it again. Of course we would answer any questions in the meantime to help them implement the changes we recommended or any changes they planned to make.

The senior manager agreed. We did the assessment. We did the presentation of results and recommendations. The results were well received. We subsequently had other senior development managers asking for a date when we could come in and assist them.

Within 18 months the organization was officially assessed at SEI CMM level 2. It could have been nine months, except there was one real disconnect (the quality department!) that had to be significantly changed to meet the criteria of the standard.

By forming a “service” and delivering the service sincerely as “we are here to help,” it took a stalled effort and sling-shotted it forward. It empowered the folks who had to change to make the change. In other organizations where I did the same thing, the notion of using a service approach often chaffed those who saw their job as bringing about the change. Their notion was always to put together a detailed plan. Then they would execute that plan top down with close tracking and regular status meetings, driving each step. Instead, when using a service approach, the driving team’s job was to empower, educate, motivate and measure the current state of the implementation.

A second example is a bit simpler but captures the same notion.

My department was responsible for managing and tracking all computer equipment used by all the other departments. Because of the rapid introduction of new PCs and flush budgets for new equipment, we had a lot of old equipment piled up in closets and other spaces in these departments. Constant entreaties to “turn in your equipment” were met with stony silence as everyone was focused on doing their jobs and not doing paperwork and transportation of old obsolete equipment.

At first, departments hung on to their old equipment to be able to use them. With time it became a habit of “we’ll turn it in once we are done with it.” Finally it became a culture of “shove it in the closet with the others.” It had grown into a huge and ugly problem. One could open a random closet and find it literally packed to the ceiling with old equipment. No one would admit that they no longer knew where all their old equipment was.

Excess Equipment Remaining Per DepartmentI asked my equipment manager to build a slide that simply showed how much excess equipment was in each department. It was a simple count of the pieces of equipment that were on the obsolete/replaced list.

Each week we attended a senior staff meeting with all department heads. At the meeting I would simply pop up the slide showing each department and how much equipment they still had to turn in. I made few comments except to say “this is where we stand on the equipment turn-in.” Each department head could see where they stood in relation to each other and how much progress, if any, had been made. That was it. In about 2-3 months the problem was gone.

Before we implemented this approach several other approaches were tried. One was to call a weekly meeting with individuals who had excess equipment and “push” them to account for and turn in their old equipment. This approach, along with sending out pointed letters to individuals or their supervisors on the lack of progress, had been tried persistently in the past.

The second major approach suggested was for our department to take on the effort. We would find all the equipment and reconcile all these other department’s tracking of their equipment. Do it all ourselves. This got no support from within my department. It, according to my staff, would have been equivalent to purchasing ocean front property in Arizona sight unseen and then being responsible for selling it to Donald Trump at a profit.

The problem was solved once we gave the senior department managers something they could use to drive the effort within their own organizations. We helped them understand the problem. They individually took back that slide and passed it to their folks usually with the comment “I want to see this going down next week.” We then had people coming to us for help rather than us calling folks who would not return our calls.

The lesson learned was to find a way to help rather then try and use our “authority” to cause it to happen. For many people this approach is counter intuitive. The key insight was that everyone in both examples knew that something needed to be done. The trick was to find the extra insight that helped them get it done. There is a better chance that insight will come to us if we think of what service we can supply that will help people to do their job.

As a final thought, like the second example, one has to be wary of that service being “we do their job.” I’ve seen so many support organizations grow because a solution was to have someone do someone else’s job. I’ve observed that many Quality, Test and Process organizations — that were struggling — were the result of “we’ll do it for them” approach. If it needs doing and it is integral to what we do, then the right people should do it. We just may need to help them do it initially and helping in terms of a service can bring surprisingly rapid results.

What part of your project might benefit by a service approach?

Thank you for sharing!

11 thoughts on “Don’t Project Manage Change – Provide A Service!

  1. PeggySue Marquez-Kelly says:

    “Don’t Project Manage Change – Provide a Service” is great – and very timely!

    I especially appreciated the comment that PM’s should “empower, educate, motivate and measure the current state of the implementation”! When a project manager has the skill set required to accomplish this, project management itself becomes a leadership role – not an administrative one.

    Thank you for sharing!

    1. Bruce Benson says:


      I’ve seen both “types” of PMs, those that were essentially AAs and those that were leaders. I observed that the individual had as much an impact on what role they filled as did the organizational expectations. In many cases, I’ve seen PMs happy to be doing technical/administrative tasks and shy away from the tougher political and leadership roles. Other PMs were only interested in the power and leadership and spent their time getting others to produce the technical artifacts needed.

      Clearly, a nice balance between the two would seem more useful.

      Thanks for the comment.


  2. Bruce Benson says:

    I read your current post. It has a lot of good classic change management ideas.

    The idea in “Provide a Service!” was if a classic method is not working, consider another approach of providing a service.

    This is especially useful for individuals wanting to bring about a change, but who are not in a position of getting the support they need. It allows them to “press on” and make progress without needing agreements to move forward. It is also useful in an adversarial situation – where folks have a built in prejudgment about your initiative.

    A fairly complete case study can be found at:

    Starting out, one could use a technique such as what you outline. But if for some reason it didn’t work, then this is an alternative approach that has worked well for me.



Comments are closed.