Page 221 -

It’s Too Risky
The celebrated economist John Maynard Keynes once wrote, “Worldly wisdom teaches
that it is better for the reputation to fail conventionally than to succeed unconventionally.“
Legendary investor Warren Buffett put it this way: “Lemmings as a class may be derided
but never does an individual lemming get criticized.” In other words, any manager who
backs a change puts his reputation on the line; if that manager does nothing, he will not be
criticized for maintaining the status quo.
When you make a change in an organization, you aren’t just altering the activities that the
team performs. You’re also affecting how people relate to each other in the organization.
A change that goes wrong can ruin someone’s reputation (and, if it’s serious and public
enough, their career).

Nobody gets blamed if things stay the same. If a project fails, but many other projects failed
in the same way, the failure is usually seen as inevitable and the people in charge of the
project are not held accountable for the failure. And even the most flawed deliverable can be
painted as a success, even if the software that is finally produced barely does what it’s sup-
posed to and requires many patches and bug fixes. (In fact, for many software professionals,
this is a fact of life—every project they have ever worked on turned out that way!)
Many people equate questioning what has always been done with insulting the organiza-
tion as a whole. They consider it to be something a team player would never do. To some-
one with this attitude, the fact that you are pointing out problems and suggesting changes
sets you apart from the accepted culture. They feel that since you are making wide-ranging
criticisms of the organization, you do not buy into its culture and are simply being counter-
productive. Paradoxically, to these people, it is considered more productive to make bad
decisions and let projects fail than to question the way things are done.

This means that when people complain that making changes is risky, they are not incor-
rect. However, a manager shooting down a proposed change as “too risky” may be sensing
risk to his own reputation, rather than to the project.
When looked at from a pure cost-benefit perspective, most of the tools and techniques in
this book have a very limited risk to the project. Usually, it only takes a few hours to run a

Wideband Delphi session, set up a version control system, write a vision and scope docu-
ment or hold an inspection meeting. Even if these tools and techniques fail to produce any
results at all, the total cost to the project is minimal. Yet these same tools are routinely
shot down as “too risky,” and in a sense they are—but not with respect to the project.
When people talk about these tools and techniques being risky, often they are not trying
to say that the tools will somehow damage the project; rather, the risk is that if the project
still runs into problems, the manager who implemented the new tools can be held respon-
sible for those problems. In other words, there’s an implied rule in most organizations:
“you break it, you bought it.” If you make a change to an existing process, you’re now
responsible for any failures that result, even if those failures are only tangentially related
to the changes you made.

UNDERSTANDING CHANGE 213