Don’t let uncontrolled changes derail your project

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

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