There are two ways to handle changes to systems. The first method allows anyone to make a change at any time, once the change has been approved. This is an okay (but not great) method for small organizations with very little change to happening to their systems. However, larger organizations with multiple requests for changes to the same system cannot operate this way. Once multiple change requests to the same system become the norm, change requests must be consolidated and reviewed together in order to avoid confusion and prolonged downtime, as well as to allow a consolidated impact analysis.
Logging, analyzing, reviewing, approving, and scheduling changes isn't really as hard as it might seem. We've boiled the entire process down into a three page spreadsheet and associated calculations that we'll go over here in some detail. We only show the spreadsheet and our calculations here to make our point about the information that you need to track and some of the variables that you'll want to use when making your decisions. We highly suggest that larger organizations use change management tracking software.
Consolidating the RFCs
Once the change requester documents all of the information in the proposed RFC, the RFC is submitted to the change manager.
Note, at this point, some
authors who write about change management state that if the change requester
doesn't have the RFC filled out correctly, that it should go through a
screening process, and be returned for changes before it is accepted. That's
just a lot of bureaucratic hogwash. Seriously. If the change requester and the
change manager can't work together to ensure that the RFC process is
understood, the RFC is detailed enough, and it is completed properly, then the
two of them should be replaced with more competent staff. End of story.
As the change manager begins gathering the RFCs, they must be logged into an impact assessment worksheet. The sample that we provide was created in Excel, and we are sure that better ones exist. If they do, please contact us and let us know and we'll make them available to our readers. Our sample has six key fields that need to be included in the first page of the RFC impact worksheet.
Page 1 of the RFC impact worksheet
1. The first item that needs to be tracked is the change requester's name, and possibly contact information such as e-mail or phone number.
2. The second item to be tracked is the asset that is being changed. By asset, we mean the application, cards, drives, etc.
3. The third item to be tracked is a short description of the change being proposed. This doesn't have to be lengthy as the original RFC will have the full detail.
4. The fourth item is the change priority, which we've discussed previously. This should fall from low through high, with emergency changes only happening if the system in question failed, or the building failed.
5. Within each RFC, the change requester listed up to ten configurable items or staff that could be impacted by the proposed change to the system in question. If you'll notice on our example form there are only ten columns for assets. Theoretically, the first RFC could fill all ten of those asset columns. In that scenario a second RFC for the same system could request a change that impacts an eleventh asset. If that can be the case, why did we limit our form to ten columns? Simple. Our rule is this - once ten assets in a system are being impacted by a proposed change, that is a significant enough change to warrant holding off any further changes until that one has been completed. For us, our rule is that once ten assets are being affected - whether that is through a single change or multiple changes - no more RFCs can be added to the system for that change period.
6. A conversation between the change requester and the change manager should create a proposed failure rating for each asset between 1 (not noticeable) and 5 (rendering the system unavailable). This number represents a first attempt at classifying the risk of failing to properly make the change, and how that failure would impact the asset in question.
What happens if there are ten change requests before ten assets are impacted? What we've found is that the "rule of ten" as we call it seems to be working okay. All further changes to the system are frozen once either ten assets are affected or ten changes are being made. The complexity of troubleshooting the system once either of those numbers grows larger is too much to bear. There are very few change releases that are fault free, so keeping your changes to a manageable set will become very important to your success rate remaining high.
Reviewing the RFCs
Once the RFCs have been consolidated, they should be reviewed and the reviews consolidated as well. The change advisors shouldn't have to meet face to face, as that can be a time wasting effort. We've found that the best method is to keep the whole process simple and either route the RFCs as PDFs to each of the change advisors, or route them through a Sharepoint server as "tracked" Word documents so that all of the changes and annotations can be consolidated and reviewed in one place.
This doesn't mean that a quarterly or bi-annually meeting of the change advisors shouldn't be scheduled to review their progress and overall change management. Or that a wide spread or high classification change shouldn't call for a meeting to discuss the ramifications of the project. What we're saying is that for day-to-day routine business, change authorization should be kept at as low a level as possible.
When consolidating the change impact reviews, four points of information should be tracked and annotated in the logging system, within additional fields (the asset(s) to be changed and the affected assets) being carried over from the previous page.
Page 2 of the RFC impact worksheet
1. The change advisor(s) for each proposed RFC should be listed by name.
2. When the change advisors reviewed each RFC, they made notes regarding the impact of the changes. The highlights of these notes should be added here for clarity in the decision making process.
3. The RFC's change classification (from standard through major), as restated by the change advisors, should be listed here. It should be noted that if all of the changes are classified as standard, then the change review process should be halted and the changes automatically approved. There is no sense in wasting anyone's time if all of the proposed changes are ones that have been happening as a matter of course and business as usual.
4. The final bit of information that needs to get added to the change review impact worksheet is the reviewer's take on the failure impact rating. This is important, because it is used in a calculation for the final page. The math behind this bit of input basically states that if the change requester and the change reviewer agree on the impact, there is no issue. Or if the reviewer thinks that the impact is lower than the requester does, there is no issue. However, if the reviewer thinks that the impact is higher than what the requester thinks, there is an issue that needs to be addressed.
Approving the RFCs
Once the reviews have taken place, there should be two deciding factors - do the reviewers and change requester agree on the failure impact of the proposed changes, and is any special authorization needed based upon the change classification?
Page 3 of the RFC impact worksheet
The change classification decision making process is simple. If the change request is an emergency change, then the change advisors must authorize the change. If the change requests are all standard, unless the impact assessment is severe the changes should be automatically approved. All other changes can be authorized by the change manager.
Once the changes have been approved, any go forward instructions should be duly noted on the worksheet and the approval process ended by scheduling the change appropriately.
| This is a sample of what is available in the Change Management Kit, which includes a PDF guidebook, an Excel audit worksheet, and the professionally designed forms you'll need to get you started. |
 |