Software development teams need to have a change management system that integrates seamlessly into the development environment. Software developers want to be able to do their task in the development environment they are familiar with and do not want to learn a new tool to do their jobs. The software development life cycle tends to be longer than content development life cycles and the effort required to effect changes in the software is usually orders of magnitude larger than that required to effect content changes.

In a typical software development process, issues are assigned to team leads who investigate the possible solutions. They allocate tasks to individual developers, possibly assigning different parts of the resolution to different people. Each developer does his or her part. All collaborating developers then integrate the components and, once they are satisfied that the issue is resolved, they submit their changes to the build. In the build process, the changes to source code required to effect the different fixes that have been assigned to the build are applied to the code base and a built artifact is produced. At this point independent verification may occur prior to deeming the built artifacts suitable for submission to production. In addition to the steps of transforming source files into deployable artifacts, this process is characterized by a level of collaboration and verification that is not usually found in the content development process.

By contrast, the content developer and the line-of-business experts tend to have a simpler process flow, characterized by smaller teams and submission without extensive intermediate steps of aggregation and transformation. Content developers typically fall into two categories: casual contributors or high usage contributors. In both cases, participating in the change process needs to be sufficiently unobtrusive so that it does not discourage them from participating.

There needs to be a simple way to access requested changes to ensure that they meet the business goals set out for the Web site. Therefore, inherent in the review and approval stage are the following notions: Notifications, In Context Review, Staging, and Promotion.

Notifications must be available for any specified event in the workflow. These events include being assigned a task, having a fix submitted where a user’s approval is required, having a submission rejected, and so forth. Knowing that one’s input is required as part of the change management process is the catalyst to participation. Most change management tools allow the user to select to be notified by email, pager, or any other device supported by the corporate messaging system.

In Context Review means that content is reviewed by different people for different purposes. One reviewer may need to approve the look of the Web page, while another may be concerned only with the marketing described in the submitted package. The change management solution used, must allow each reviewer to see the changes as they will appear in the final site once deployed.

Staging is a technique used in many business environments to segregate content of different phases of maturity. One of the requirements of the staging system in a change management solution is that in the event that a change is rejected, the appropriate versions of all the files that were affected by the change, need to be rolled back to the previous version.

The number and types of approvals required in any stage to allow a change to move from one stage to the next is defined by the business requirements and implemented in the staging and approval system. Once all of the approvals required in one stage have been received, the change is promoted to the next stage. It is important to make sure that a change management solution provides you with the flexibility to define staging levels and rules around promotion that fit with your own business environment.

The implementation of a change management solution that embodies all these notions provides an environment where change can be reviewed and approved with minimal delays, allowing the required changes to propagate through to the production site in the required time, while providing a high degree of confidence that the changes made to the site are correct.

By elevating change management from managing files to managing issues directly, management can regain control over the full range of change complexity. Instead of the typical cycle where non-urgent requests become urgent and cause a crisis, important but non-urgent requests are less likely to fall through the cracks when management is able to constantly review the progress of change through the organization, spot bottlenecks, and remedy process problems before they get out of hand.