Page 215 -

eventually completed, and the software they built is now being used. Sure, some projects
seem to always be eternally 90% done (with 90% left to go), but most of them seem to get
something onto the users’ desktops (although many patches and bug fixes needed to be
rolled out afterward). Isn’t that good enough?
The truth is that software development does not have to be painful. It is possible for sched-
ules to come in on time, for teams to work normal hours, and for project managers to feel
like they are actually in control of their projects.

The denial mindset should seem familiar to anyone who has tried to implement inspec-
tions, only to meet with enormous resistance from the project team. Just as people are not
used to seeing their documents criticized and corrected, they are not used to, or comfort-
able with, their projects being branded “failures.” Part of your job as a project manager is
to help people in your organization learn from their mistakes. This means that they first
need to learn to acknowledge those mistakes.
Sometimes project managers find that people want to know how projects in other organi-
zations have turned out. When people in your organization ask for this, what they are
really looking for is the bar that they are being measured against. They don’t necessarily
want to know what techniques are out there in order to help them build better software;
they are just looking for corroboration that they are doing enough already, and don’t need
to make any changes. But the truth is, projects usually go wrong because of specific prob-
lems. Many research groups (including the Software Engineering Institute and the
Standish Group) have found that when organizations implement process improvements
(like the tools and techniques in this book), those problems often get fixed, leading to soft-
ware development that costs less and results in better software. Many organizations
around the world have verified this in practice.
Also, people in your organization may be willing to acknowledge that there is a problem,
only to go back into denial when past performance is discussed. Getting people to talk
about their problems is a start, but it’s not enough. The same people who complain about
project delays and scope creep will often suddenly reverse their opinion when talking
about past projects. Most professional people need to see themselves as successful—it’s
part of each person’s identity. For many people, talking about the need for improvement

means digging up old, painful projects and examining problems that they would just as
soon leave buried. It’s easier to look back at a troubled project and see only the successes,
forgetting the delays, arguments, difficulties, dead ends, and failures along the way.

In an organization where people are in denial about their problems, it is common for peo-
ple to shoot down changes by saying that “we’ve never done it that way before.” That’s
obviously true—it’s different, so clearly it hasn’t been done that way before; the objection
sounds like nonsense. The reason this excuse makes sense to the people who say it is
because any change amounts to an implicit criticism of the status quo. If a change is
needed, then it means we’ve been doing things wrong; therefore, any change is bad. Mak-
ing changes to the status quo seems too risky because the organization has always devel-
oped software this way.

UNDERSTANDING CHANGE 207