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.

We 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.

I 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?