Each organization must apply best practices in line with existing business and development processes. There is, however, a short list of factors that are common to nearly all successful change management solutions.

Success Factors
When faced with a complex challenge like managing software change, it's human nature to look for a silver bullet. A common mistake is to roll out a software configuration management (SCM) or defect tracking product, and call it a day. But even the best tools are only as good as the process behind them. Just installing Quicken, for instance, does not mean you have a sound financial plan. Each business should first examine how change takes place in its unique environment, and then apply the tools that best augment that process.

Take, for example, the management of software configurations. Here you must be concerned not only with storing files, but also with your overall integration strategy. If you place all your project code under version control, and 10 developers are making changes to that code base, how do you intend to build the next release of your product from the pool of versions that are being created? Control over checking files in and out is essential; but, in itself, that's not change management. You also need to implement an integration/build strategy. This could be as simple as building the latest code that has been checked in every Friday night, or organizing a multitier promotion model.

However your change management approach ultimately works, it must be flexible enough to strike an appropriate balance between efficient control and over-control. Many organizations attempt to address the problem of change by, in effect, resisting it with rigid controls. This usually hinders the individual's ability to efficiently make changes.

Change management tools and processes ought to be carefully tailored to the task at hand. If you've got three developers working on a prototype that's scheduled for delivery in six months, and they all sit next to one another, a fairly relaxed process is adequate. If you're an IT organization building a mission-critical application using distributed internal and outsourced development resources, you need to control change much more tightly.

These considerations lay the groundwork for the successful implementation of change management tools and processes. Some proven and practical ways to put change management into action include:

Let's look at each of these in more detail.

Store Artifacts in a Central Repository
The most fundamental element in any change-management strategy is basic file management. You need to store software and related project artifacts in a central repository, such as a version control or SCM system. To ensure that valuable work is protected from loss or corruption, you also need to control access to the repository via a simple and reliable check-in/checkout process.

Think about what happens when teams don't have this basic level of file management in place. Critical project code and documents reside on various servers and on individuals' laptops. Even with centralized file storage, developers can accidentally copy over each other's changes, wasting time, reintroducing bugs, and causing testing nightmares. Versions needed later, such as to rebuild a previous release, may be unrecoverable.

Beyond basic version control, two additional SCM capabilities are extremely useful. The first is workspaces, which greatly simplify keeping even the smallest development teams in sync. A workspace is basically either a copy or (preferably) a "virtual view" of some part of the central code repository, stored on individual developers' desktop systems. Periodically, the version control system can automatically update each workspace with the latest versions of everyone's files. This saves developers time by providing the most up-to-date versions.

In addition to workspaces, the availability of an audit history is also important. Most SCM tools provide some level of auditing. Audit histories let team members quickly see who made what change to what artifact, and when they made it. This simplifies both traceability and reproducibility.

Implement Version Control
In line with managing a central repository, a related necessity is some form of version control. This ability to manage concurrent changes to files is the foundation for parallel development, as well as baseline management. Without it, technical managers cannot shorten the "critical path" by breaking the serial task of developing complex software into multiple, parallel tasks.

Version control must be addressed on two levels:

Figure 1 illustrates a common example of the cost and risk associated with a lack of adequate version control. Two teams are working in parallel: one on Release 2.0, the other on bug fixes to Release 1.0. Unfortunately, some of the defects fixed in Release 1.0 were not properly merged into Release 2.0. As a result, customers uncover problems in Release 2.0 that they reported and found to be fixed in point Release 1.1.

 

To develop code in parallel, version control tools must be flexible enough to allow fine-tuning of those policies that balance individual isolation against the pace of integration. If each engineer saw every change that someone else made when they clicked "Save," the changes would pile up so quickly that a stable release could never be built. Likewise, working in isolation for long periods can make integration unacceptably difficult: issues like misunderstandings about interface design need to be rectified early and often. The deeper you get into the development life cycle, the more important it is to integrate changes frequently. When everyone is working on skeleton code, the ability to view or work with others' changes is less important than when you are fixing a defect two days before "code freeze."

Group Files Logically
Another factor in effective SCM is the logical grouping of files in support of component-based development, software reuse, and baseline control. A logical file organization simplifies the process of integrating a complete change "activity," as opposed to working with random versions of individual files. The organization of artifacts around versioned components also enables a team to manage its code baseline relatively naturally after each testing/integration step, provided sufficient energy is devoted up-front to aligning the file organization with the system architecture.

In general, the more intuitively a code base is organized, the less process that is needed to ensure that whatever code changes comprise a fix or enhancement, they are baselined together and included (or not) in a build together. Good file organization also simplifies the tracking of defects and enhancements by making it much easier to tie the delivery of new functionality to changes in the code base. I once worked with a customer who had organized their code base alphabetically, by file name. You can imagine the uselessness of statements like, "We're going to baseline files F through H on Friday."

Track Defects and Enhancements
Most development organizations realize that defects and enhancements "should" be tracked. For some, it suffices to do this somewhat informally, such as through spreadsheets. But whatever it takes to do it - do it.

Note that the process implemented to track defects is likely to differ from the process for tracking enhancements. Enhancements often involve more up-front evaluation because of the amount of work they can require. Bug fixes become increasingly important in the end game. But in either case, the decision-making process is at least as important as the tools involved. What is critical to the customer? What is possible in the time allotted? What must the next release look like relative to the competition?

The relationship between traceability and product planning also revolves around change management information. What data do you need to determine when a product is ready to ship? What do you need to know to assess risk? Is a defect related to complex, breakable code; or to a more robust or isolated component?

What is the acceptable quality level you're striving for? This is where defect and enhancement tracking meets requirements management, because quality is ultimately measured by the relationship between the system's functionality and what the customer wanted in the first place.

The Balance Point
Software systems only grow in complexity. A successful change management solution helps deal with that complexity, while mitigating project risk. Remember: the question is not whether to manage change, but how to do it in a way that balances rapid response with adequate control. The challenge is to maintain that balance across systems both simple and complex, and across the entire development life cycle.