PM Clinic: Week 12 Summary

Topic: Process change

Compiled: 1/22/2005

The Situation:

If you're trying to change a process (say how code, test plans or specs are written) or you're pushing to use a new process for a new project (new process vs.. what the company normally does), how do you successfully sell it to the team / organization? Is there any way to distinguish constructive vs. "change bad" criticism?

I've led a few process changes, and have had some success, but I'm looking for a larger sample size of war stories and anecdotes to draw on. I'd love to hear what others have experienced, and what opinions people with different backgrounds have, and what techniques and strategies seem to work well or badly for people.

- Processing process in Pittsburgh (PPIP), PA

Advice

Most people loathe change - they avoid it. To make process change happen you have to figure out: a) who has enough power to pull it off b) who benefits from the change. Invest time cultivating and convincing a & b of the value of the change, and building momentum for it. If you can't get a to sign on, you can try a grass roots effort with b - but that takes longer (you have to start small, show success, and then grow). If both a & b aren't interested, then it's kind of lost cause. Inflicting change on people that really don't want it usually backfires.

Change takes time and requires follow through - Jay pointed out that simply getting people to buy in, and making the changes isn't enough. Someone has to follow up and continue to monitor progress, checking in on how things are going and making adjustments. It's not enough to simply
change the process - someone has to be steering the ship until things are really normal for everyone again. Jay also pointed out that on healthy teams, process change is probably continuous - things are always being
adjusted and modified to fit what people have learned and the changing needs of the project. So it's only when the team has become stuck, stale or scared that the specter of "process change" becomes a big deal.

- Scott pointed out that going door to door and listening to people is the best way to understand what the hell you're really doing. It's easy to think of process as an abstract thing, and design all kinds of procedures that will either drive everyone nuts or make them hate life, without realizing it. Going door to door to programmers, testers and documentation people you know and getting their feedback on the current process, and on your ideas for process change, will radically improve the quality of your proposals, and give you insight into how to implement change. If you do it right, you're also paving the way for rolling the changes out, as some of the team will know you've already been thinking about them, and gotten them involved
early.

- Andrew strongly recommended piloting. It allows people to hold back on their fears, and actually try something new, since there is much less risk involved. Make careful choices about what you pilot and who you pilot it with - pick people that are motivated to try the new thing (avoid forcing
people), and that have the experience or skill to adopt the new thing.

- Avoid arbitrary reasons for change - Lots of organizations get fixated on some kind of certification or external validation - CMM being a very common one. There's rarely good reason to force an org to jump through hoops just to get some kind of software engineering ribbon - Make change happen to make specific improvements in how the team functions, based on specific issues the team feels it needs to improve on (Andrew called this a toolbox approach).

- Make sure you're managing your CEO or VP appropriately. Their go-ahead is not the same as their understanding or their investment. Some executives give easy sign-off, but if they don't truly understand the process, will pull the plug at the first sign of trouble. Consider having a conversation about some of the possible initial problems the process change might cause, and get agreement on how you are planning to respond to it. Then when a problem happens, you'll already have buy-in on how it should be managed.

- Hire an expert - The voice of an outsider can open doors that staff cannot. They can say things people in the organization are afraid to say, and speak without political or self-interested bias (at least in terms of the organization). They also bring the context of other project experience and can reflect back to the project teams a view of the world from an objective, or more objective point of view.

References

- Process change is a common organizational challenge. There are some good books on the subject - Leading change, by Kotter is one of the better ones, but there are several.

Contributors

Jay Zipursky, Andrew Stellman, Scott Berkun (editor dude)