Just for a moment, let us live in a world where changes to IT infrastructure are mostly based on proactive approaches to ensuring IT Service availability is as close to one hundred percent as possible. Even in scenarios where an unplanned change is necessary, they are quickly reviewed, tested and implemented. They flow freely and easily. Without question, there is never any Request for Change (RFC) backup, and availability of IT services is always at 100%OK, in reality, that is probably far too much for any modern team to take on. What really happens in most IT departments is one of two scenarios. The first involves the discovery of a fault, or issue with a service, and engineers rush in saving the day. When this happens, IT is the hero, disaster is averted, and talented IT team is lauded by departments far and wide. Unfortunately, the second scenario is where someone inadvertently puts into place an unplanned change.
The first scenario, even though quite miraculous, rarely gets the praise and attention it truly deserves, and the second scenario tends to have a long lasting impact on the perceived value of the team within the IT Organization. This situation often forces IT teams to move to a more organized approach of handling change. Sadly, bureaucracy tends to follow closely behind, and even if you follow a set of recommendations like those found in the best practices of ITIL software, the ability to adapt to change, even the ability to react to simple RFCs can come to a standstill.
The trick is finding the right set of questions that can generally apply to any RFC. That means, even in an emergency situation, we must determine what questions absolutely must be answered to provide a base set of data to make a decision. At the same time, providing answers to those questions must still allow the team to remain agile and adapt to future changes.
Listed below, we have five of the most important questions that should be answered before any change is implemented. While there are certainly more questions that could be asked, these will provide a solid foundation. If you want to take this a step further, you should review the entire Change Management software, including the development of a Change Advisory Board (CAB). Our Practical Overview to Change Management tools provides the outline for this, as well as the entire change process.
- Is the service currently unavailable, and when can a proposed change be implemented?
- Which system(s), department(s), and/or user(s) are impacted by the proposed change?
- How long will the service be interrupted (downtime/uptime) by the proposed change?
- What testing associated with the proposed change needs to take place?
- Can the proposed change be easily reverted, and what are the required steps?