PM Clinic: Week 12 Summary
Topic: Process change
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
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
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
- 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.
- 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
Jay Zipursky, Andrew Stellman, Scott Berkun (editor dude)