Page 222 -

People are justifiably reluctant to go against the conventional wisdom in their organization.
No matter how misguided, the popular opinion is very powerful and difficult to change.
People who are willing to point out a series of singular, unrelated mistakes may be unwilling
to admit that there is a more general problem with their organization—especially if admit-
ting the problem calls into question their knowledge of software development. People do
not like to feel like they don’t have all the answers. And if you point this out in your effort to
change your organization for the better, you might inadvertently cause people to feel that
you are publicizing their mistakes and calling them out as incompetent.
Incidentally, this is one reason many people are turned off by the idea of process improve-
ment. They have only seen attempts at change partway through a project that has gone
awry. Managers start making out-of-context changes in desperation, usually based on
something they have read but don’t fully understand. Even worse, the changes are fre-
quently used as a means of forcing a stakeholder or client into compliance with an already
delayed schedule. This is not so much a way to save the project as it is a way for some
manager to protect his reputation. Not all improvements will help in every situation.

For example, one of the most common places where changes should not be introduced—
but often are—is when a project is starting to fail and the stakeholder is starting to get
angry. This mistake is especially common in consulting companies that gave unrealistically
low estimates for their projects and now find themselves in trouble. They see a client who
rightly points out that the software has many defects, and that it does not fulfill his needs.
A common (and unfortunate) response from the project manager is to try to change the
organization, instead of admitting that the client was given an unrealistic plan and work-
ing to better fill the client’s needs. A change control process is implemented to clamp
down on any new feature requests, and a hard-and-fast schedule is put in place that forces
the client to accept the work that the team has already done, whether or not it fulfills the
client’s needs. This results in a frustrated client and increased friction between the client
and the project team.
Forcing a stakeholder to accept poor software is a terrible reason to make changes to the
software process. Organizations are right to resist changes that are made for any reason
other than building better software more quickly. If there are client or stakeholder rela-

tions problems, they need to be dealt with directly, instead of trying to solve those prob-
lems by changing the way the group builds software.

How to Make Change Succeed

Progress comes not just from making changes, but from making smart changes. However,
it is often difficult to tell the difference—and no organization should be entirely comfort-
able with change. It’s often difficult to tell the difference between a real, substantive
change for the better and a management fad that will cost time and effort, but yield little
or no reward. Using the techniques in this section can help you demonstrate to the people
in your organization that the practices you want to implement are appropriate, and help
you to get your proposed changes accepted by the project team and the organization’s
managers.

214 CHAPTER NINE