If you run your systems 24x7, and you want your weekends to yourself, emphasizing hardware and database high availability is wise. But consider this: Even the most reliable hardware is useless if software changes are implemented poorly. And your software's availability is most at risk when it's being changed. This is why, when you're facing any software change that directly affects your critical business operations, you need a solid change management system.

Just as an IT organization is more than a collection of individuals, a change management system is more than a collection of utilities. The better your people communicate, the more effectively and intelligently your organization will operate. The same is true for a well-designed change management system. There's a marked difference between a simple set of utilities and a comprehensive change management system that implements an effective workflow strategy.

Workflow is key. From the moment a request arrives at your door to the moment a change is deployed, there are dozens of critical communications points to assign a task, resolve a development conflict, request a code test, alert management to review a request or approve a change, and so on. Within an IT department, messages are like synapses firing in the brain — the more reliably they fire, the higher your IT IQ. Let's look at some examples of critical communication points in an efficient change management system.

Fielding Questions and Logging Requests

Whether you have a help desk or your programmers field questions themselves, you must have an efficient tracking system in place. This means you need three things: an effective way to record users' questions, a Q&A database to find and record answers quickly, and an efficient way to pass a question to the appropriate person when you don't know the answer.

When you receive a help desk call, it's critical that you record the problem so you can analyze its frequency. Doing so can help you determine which software to change. A database of previously reported problems and their solutions is an invaluable resource. But organizing prepared answers to technical questions is tricky. For example, suppose a customer tells you that he recompiled a logical file but his system can't find the corresponding physical file. Would you file this problem

under logical files, physical files, compiling files, or library list problems? Depending on how the user asks his question, you might look under any of these categories, so it's important to make solutions available in several places, without duplicating questions and answers throughout your database.

When you can't find a particular solution in your Q&A database, you need to be able to refer the problem to an appropriate staff member, obtain an answer, pass the answer to the user, and save the solution in the database for future reference. This process should be as automated as possible because timely communication between technical resources and users is critical. Figure 1 shows a change management workflow strategy that facilitates fluid, effective communication.

Suppose a staff member forgets to respond to a question or responds with insufficient information. To ensure the question isn't lost or ignored, you need an automated process that will remind you (based on a request's priority, status, and elapsed time in the system) to follow up if you don't receive a response by a certain time. The system can also automatically notify the programming manager if a response isn't received in a timely manner. You might also need to communicate directly with the staff member to identify a workaround solution to the problem.

The Request Backlog

Although most calls don't result in requests for programming tasks, some do. Such requests and problems can mount, especially if you don't have a logical way to evaluate and organize them. Once a user's question becomes a programming request, you must decide how to channel it. To do this, consider

• who should review the request
• who should assign the request
• who should work on the request
• who should test the fix
• how to notify staff members about the request
• how to track the request's progress
• whether to notify the user when the fix is ready to be tested or when it goes live

To manage a stream of requests efficiently, you must organize and prioritize them into small projects. You may need to collaborate with experts to determine how to handle requests that require detailed analysis and redesign work. In such cases, you must negotiate schedules and verify your plans with your users. This requires instant communication; thus, messaging is a natural by-product of effective change management. It lets you attach a document and link related requests to optimize programming resources, and it lets users check the status of their requests.

Changing Program Objects

All changes start with a request that flows from the help desk and request process. Figure 2 shows the request-to-deployment cycle. For simple changes, you check out a program, test it, and promote it back to production. But most changes are more complex, requiring you to analyze and modify several programs and related objects. If a programmer or tester hasn't done so already, you must identify the objects that need to be changed and analyze how they affect related objects.

In some cases, a programmer or tester may be making changes to certain objects that you also need to make other changes to. To resolve such conflicts, you must wait until the objects are available or merge your new changes with other changes at a later testing phase. For source editing conflicts, you must implement standard responses to inform other programmers or testers. It's critical that you communicate delays to everyone involved with each request.

Promotion and Testing

Once you've programmed a new change, you need to determine who's responsible for testing it. It doesn't take a high IT IQ to know that thorough testing is best left to a dedicated quality assurance (QA) staff or to your testers. Assigning testing to the QA staff frees your programmers to move on to the next task, which is a better use of their skills.

Effective communication is especially important during testing because you may need to consult users or other application specialists about test results. When a test is successful, automatic messaging prompts team members to begin the next step. When a test fails, automatic messaging describes the nature of the failure and alerts a programmer to correct errors.

Deploying Your Changes

Once you've coded and tested a new change, the next step is to promote it to your production environment. First, the change must be approved and scheduled. At this point, you also need to notify everyone who will be involved with or affected by the change. For example, if you can't obtain an object lock, your change promotion can't proceed. So you must ask users to temporarily stop using critical components.

At this stage, automatic messaging can be beneficial because it lets you

• notify users to exit the application
• alert the system administrator to force users to exit who haven't already done so
• communicate the next step to everyone involved when the promotion job is completed
• inform users when they can use the application again

A systematic and timely flow of communication about software change activity is crucial to a change management system. For instance, you need to know when someone outside the control of change management attempts to change code in your system. You might also encounter deployment errors, where you must decide whether to undo a change after its been deployed across your network. And you need to know when an "emergency change" occurs, which is the most common source of problems.

The Beauty of e-Mail Integration

The need for collaboration is evident when you're managing software change. A change management system must have built-in intelligence to effectively relay messages. When Lotus Notes, Microsoft Exchange, or another SMTP-compliant e-mail system is the messenger, messages are richer in content and travel further, even over the Internet or to wireless devices. For example, a Lotus Notes ( Figure 3) message includes the requester's message, the task ID, a description of the requester's problem, the requester's name, and call details.

Boost Your IT IQ

Software is your company's repository for policy, procedures, and business knowledge. Efficient systems are "experienced repositories" that help you respond intelligently, quickly, and consistently to users' request. Without a change management system, you magnify the potential for downtime and increase the time you spend extinguishing embarrassing fires — fires that don't happen when software change processes are engineered rather than improvised.

How well your change management system can recognize and act upon conditions that occur during the request-to-deployment cycle directly affects your company's IT IQ. The more intelligently you manage change, the less likely you are to spend thousands of dollars on high-availability solutions only to have a poorly implemented software change bring you to your knees. A sound workflow strategy and systematic stream of communication are the foundation for a solid change management system.

Paul Schlieben is president of SoftLanding Systems, Inc. You can reach him at pauls@softlanding.com.