Page 217 -

A project manager attempting to change an organization with a bad case of NIH syndrome
faces unique challenges. In most organizations, once people recognize that there is a prob-
lem, it’s often sufficiently convincing to show them that people in other organizations
solved the same problem with a solution that already exists. But people in an organization
that has NIH syndrome will reject the idea that anyone else in any other organization
could possibly have had the same problems. There is simply a pervasive idea that “we’re
different,” which leads to immediate resistance to any ideas that come from outside.

There is an especially virulent strain of NIH syndrome that is commonly found in small
entrepreneurial companies. It goes beyond simply believing “we’re different”; instead, the
people at afflicted organizations believe “we’re better.” They consider larger companies to
be inflexible and laden with bureaucracy. They feel that their small size is an advantage.
People in companies like this will often refer to things like their “flat organizational struc-
ture” (which, oddly, still features four or five layers of hierarchy, similar to most medium-
sized companies), and will talk about how they can respond much more quickly to clients’
needs than their larger competitors. Such a mindset often leads to outright rejection of
any change based on a tool or technique that works for large companies. Anything that a
large company does is dismissed as “too bureaucratic” (see below), and would “clearly”
slow down a small, nimble company. In truth, however, every single tool and technique
in this book has successfully been used on small projects employing as few as two people.
When it comes to NIH syndrome, size really doesn’t matter.

It’s “Too Theoretical”
When an idea does not make intuitive sense, many people will dismiss it as a result of
“academic research,” which could not possibly apply to the world they live in. For exam-
ple, to someone without a project management or software engineering background, it
may not be immediately obvious that reviews reduce defects, or that it’s important to
write a specification before building software. To him, these procedures are time-consum-
ing, with no obvious benefit. They sound good in a book, but would never work in the
organization. In other words, they are “too theoretical.”
Some managers—especially ones who consider themselves “hands-on” and who value
technical knowledge above management skill—will say that many of the tools and tech-

niques in this book are “too theoretical,” and therefore somehow do not apply to their
particular organizations. This attitude is common among managers who worked their way
up from programming or other IT positions and who have only served as a manager in
one organization. It is also common among people who have never experienced a success-
ful project that was on time, on budget, and with few delivered defects.

Declaring a particular tool or technique “too theoretical” may seem like an odd response.
These practices arose from software engineering practices that were developed, imple-
mented, and refined over the course of countless projects in thousands of organizations.
Most people would consider any solution that is well accepted and has been implemented
across the industry to be anything but theoretical. But for many managers, a technique
described in a book is of less value than one that was learned or discovered in the field. If

UNDERSTANDING CHANGE 209