“Not Invented Here” syndrome (NIH syndrome) is a name given to a common type of organizational culture where people intentionally avoid research or innovations that were not developed within the organization. When faced with a problem, the people in the organization will typically reject a solution that is known to have worked elsewhere in the industry, solely on the grounds that it did not originate from inside the organization. They opt instead to build their own solution, often at far greater cost.

This may seem ridiculous or silly to people who have not directly experienced it, but NIH syndrome is a serious problem. Some teams will waste many hours defining procedures, creating tools, and building their own solutions to problems that have already been solved elsewhere, rather than adopting or adapting an existing solution that can be purchased off the shelf or learned from a book, training course, or outside expert. One motivator behind NIH syndrome is that people are often rewarded for building new software when they would not be rewarded for buying something that does the same work. For example, a programmer who would get a lot of recognition for spending months building a component might not get any recognition for buying an equivalent one, even though it would cost a tiny fraction to buy rather than build.

If you think about it, you may recognize at least a small example of this behavior in your own organization. For example, many programmers will “reinvent the wheel,” building functions or components that could be purchased or downloaded. If your organization commonly develops proprietary technology instead of using an alternative that’s available from a third party, it may suffer from at least a mild case of NIH syndrome.

There’s sometimes a feeling among software engineers that good project management is only “appropriate” for large projects. I disagree. I don’t think there’s such a thing as a team that’s too small for good project management. I’ve taken on projects with small teams — even as small as two people — and I’ve kept them on track using good software engineering and project management practices. In my experience, project management scales down very well.

That said, it’s not necessarily easy for a lead developer used to working under pressure in a fast-paced, startup-style company to walk in one day and say, “Okay, let’s start doing project management!” Software project management is a technical engineering skill that takes time, experience and more than a little discipline.

As luck would have it, Jennifer Greene and I tackle this very subject in an article called Quick Kill Project Management, which will be published in an upcoming issue of Dr. Dobb’s Journal. We pulled out three essential practices — vision and scope, estimation, and code reviews — which a lead developer under pressure could adopt quickly, and which would make an immediate difference in the way they work. (Our aim was to strip them down so that they are quick and easy to adopt without sacrificing effectiveness.)

I think these practices make a great stepping-stone to more advanced project management practices. But even if they’re all lead developer does, he’ll see a marked difference in his ability to control changes and keep his team from working insane hours to meet unrealistic goals — and he’ll deliver better code. These practices take very little time to implement, so there’s low risk and it’s not hard to get the team on-board. (And you definitely need the team on board for them to work!) And I think there’s no time like the present to do it.

(I adapted this from my recent post on Scott Berkun’s pmclinic forum.)

Many people confuse “project management” with “schedule maintenance,” and treat project managers as if they were just bean counters. I suspect that one reason for this is the emphasis that many project managers on tracking projects. The project manager needs to control the project, but a big part of that is keeping track of every single aspect of the project… right?

Well, not exactly. The two most important reasons we track our projects are to see where we are with respect to the project plan and to have historical data so that we can estimate when building future project plans. The tracking itself has its uses — making each individual team member more aware of his or her contribution, for example — but these are subordinate to the impact of tracking on current and future project plans.

When looked at from that perspective, the question of how to track progress and exactly what to track becomes easier to answer: take whatever system we used to create the project plan and make that the baseline. Then have a periodic (weekly, biweekly, monthly, etc.) meeting to compare the progress done so far against the plan and update it to reflect the actual work done. By the end of the project, the PM should have a series of deltas: the baseline project plan, then how that plan changed over time.

At the end of each project phase, hold a phase-end review to look at how accurate the plan was. Which estimates were accurate? For ones that were not accurate, what happened? Write these reasons down. At the end of the project, hold a post-mortem meeting (or, ideally, have your QA manager hold it, since that really ought to be a QA function!) to analyze the data and come up with a final report that summarizes all of that. Then next time the team gets together to build a project plan, make sure everyone goes back and reads the post-mortem reports from previous projects.

When project managers think about tracking information as a way to gain insight into how well the project was carried out, they can turn tracking from a dull bean-counting Lose Weight Exercise into a useful and important project activity.