Chapter 8
Let's explore how this process works:
1.
RFCs come from both sides of the relationship. The customer should still have the
opportunity to categorize and prioritize them, as it is the customer's business. Figure 8.8
doesn't show a logging responsibility, but it's likely that the consultant will be the one
logging the RFCs and maintaining all other information and data used within the process.
2.
The consultant gets to schedule the change's development cycle, keeping in mind the
customer's priorities.
3.
The consultant develops the change and technically reviews it.
4.
Once the change is technically ready, the customer has a review opportunity. This review
might be a high-level review that examines the change's potential impact, or it might be a
second technical review, depending on the customer's involvement and level of technical
expertise. The level of the customer's review should be an agreed-upon, stable
component of the business relationship between the two organizations; in other words,
the customer should always conduct the same type of review.
5.
Any objections to the change are addressed by the consultant and, if necessary, the
change is redeveloped to accommodate the customer's concerns. Another technical
review should always occur on redeveloped changes, and the customer should get another
look to ensure that the original concerns were properly addressed.
6.
Once the change is ready, the customer and consultant jointly schedule it for deployment.
7.
The consultant takes responsibility for backing up devices that will be affected and for
deploying the change.
8.
The consultant tests the deployed change, and the customer must confirm that the change
and the entire network are operating as desired. Once the change is approved by both
organizations, documentation is updated and the change is complete. However, if either
party is unsatisfied with the results of the change, the change should be rolled back and
redeveloped. Changes should not be "tweaked" in the live production environment to
address technical or business concerns!
This process provides the customer with less responsibility but enables the customer to maintain
oversight capacity to ensure that the network continues to meet the customer's business
requirements. The key elements of a good configuration and change management process are
present: peer review, disaster recovery plans, change prioritization, and testing.
Effective communications are just as important in this process. Whenever the process crosses the
vertical line separating customer and consultant responsibilities, communications must be clear,
and should be logged in a formal record keeping system, such as a ticket tracking database.
Change Management for Larger Organizations
Larger organizations, with their greater rate and scope of change, need a more complex,
comprehensive process to ensure that changes can be evaluated and controlled centrally.
Otherwise, the organization's changes will quickly get out of hand. The need for peer review and
testing of changes is also increased, as the impact of an improperly made change is much greater
than in small organizations that have, if nothing else, fewer users who will be affected. Figures
8.9 and 8.10 provide a split view of a process that addresses the needs of a larger organization.
This process is based on ITIL best practices.
172