Changes are dangerous. It’s often very easy to loosely describe a change in just a few sentences which, if implemented, would require an enormous effort (and a lot more detailed description). The sales people and product managers still need to figure out what the client needs, but in order to make an informed decision about a change they have to do a real cost-benefit analysis — and that’s where change control comes in. Change control is a process that the project team puts in place to force each change to be evaluated on its actual costs and benefits before the team begins implementing it. A good project manager should watch out for a particularly insidious problem: nobody making decisions about what goes into the project. The buck should stop somewhere — either one person or a team (like a steering committee) should have final say over what goes into the project. It’s easy for people in an organization who should be making decisions to simply look at the project manager and think, “She’s an expert, she knows about the project, so why can’t she decide what goes into the product?” What’s especially problematic about this situation is that, with nobody paying attention to what goes into the software, the team will simply end up gold-plating and the scope will creep.

Luckily, we have tools for handling both problematic changes and scope vacuums. Change control is method for implementing only changes that are worth pursuing, and for preventing unnecessary or overly costly changes from derailing the project. Change control is essentially an agreement between the project team and the managers that are responsible for decision-making on the project to evaluate the impact of a change before implementing it. Many changes that initially sound like good ideas will get thrown out once the true cost of the change is known.

One thing to keep in mind is that each change should be recognized by the team as an explicit change in direction. Someone authorized the project, and the money to pay for it is coming out of a budget somewhere. The person or people who made the decision to fund the project should also be making the decision to extend it. It’s really not within the project team’s rights to take on changes that the stakeholders have already agreed to.

“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.)