Page 224 -

This is especially helpful in growing organizations, where you can talk about a need to write
down how things are done already, in order to help new people adjust to the environment.
It’s important to remember that people have a need for consistency—when your actions are
aligned with past projects, it’s much easier to persuade others in your organization.
This strategy can also be pitched as a training program. All organizations must train peo-
ple, so it’s possible to pitch your improvement effort as a way to bring them up to speed by
writing down how things are done.

Keep in mind that this approach is not completely honest—you’re trying to pretend that a
change is the same as the status quo, and may be taking advantage of the fact that few
people in your organization have sufficient understanding of how software is developed in
their own organization to see the difference. But this approach can often buy you enough
time to get people used to some of the changes that you want to make.

Be positive about the work that’s already being done

When people are in denial about the need for change, it is often because they need to see
themselves as successful and do not want to admit that their past projects have been less-
than-perfect. Use this feeling to help you implement your change by praising the work
that’s been done in the past, and positioning the change as a way to build on those past
successes. Keep your tone positive when talking to people about the need for change.

Find examples in past projects of things that went well that support your changes. For
example, you may have had a positive meeting at the outset of a project generally viewed
as a success in which the team dealt with scope issues. This can be the kernel of justifica-
tion for an effort to build a vision and scope document for a future project.
If anyone in your organization has ever discussed the sorts of things that you are propos-
ing, you’ll be in better shape. You can use these people to help you make your case by
showing them that you are building on their ideas. This can help you build consensus
among the project team and in the organization.

Take credit for the changes

It usually helps to show that the changes you are proposing have worked in other organi-
zations. But if your organization suffers from NIH syndrome, this approach could be dam-
aging. It’s counterintuitive, but it may make sense for you to act like you thought of the
changes yourself.

Don’t talk about the changes as a process improvement effort that standardizes the way
you build software. Instead, step away from the big picture and concentrate on solving
individual problems. Justify the changes as if they are solely in response to specific prob-
lems in your organization, and not as tools that are standard across the industry.
Some people are understandably uncomfortable taking credit for the ideas of others. But
while you may not have come up with the idea of a vision and scope document or a project
plan yourself, you did have the idea of applying it to a specific project in your organization.

216 CHAPTER NINE