“An object that is at rest will stay at rest unless an external force acts upon it” (Wikipedia, 2015). This is Isaac Newton’s first law of motion. In the IT world, we can make the generalization that if you have a service that is working as designed, it will continue to provide that service unless it is changed in some way. This working configuration or baseline is very important because it provides a frame of reference from a known configuration that is operating as designed. According to the IT Process Institute, 80 percent of unplanned outages are due to poorly planned changes. Part of the main reason for these failures is poor or missing change management processes; however, there could also be missing an enterprise architecture process or linkages to both the EAF and ITIL.
IT organizations struggle with change management processes and usually the reason for its ineffectiveness escapes them. IT leaders must take a broader view of what the change process is really trying to accomplish and, more so, how does it link to other processes.
The change review board/meeting is not a time to reject a change because of questions around design, testing, dependencies, etc. That’s not to say that a change shouldn’t be stopped at that point if a red flag is raised. The point is that there are EA and governance processes that should precede the change process, and these processes should catch those items. We can summarize the change management process as more of a scheduling and control function and not a design review exercise. By the time a change request is created, an effort has moved to the implementation phase. The design has been completed, testing done, and implementation plan ready. So the change process becomes more of a scheduling exercise to ensure that all changes are coordinated, proper communications are being done, and the change requests are documented properly.
We’ll start with the early idea of the linkages between the change process with other processes. ITIL does a terrific job providing a framework for operational processes. What it does not do is cover the activities that should happen before an event or project hits the ITIL process. Organizations that are very mature and effective link an enterprise architecture framework with the ITIL processes. This provides the ability to standardize and govern strategies and designs, then move them to implementation using ITIL.
Where does governance fall into these processes then? The true activities should happen during the enterprise architecture processes and between the EA process and ITIL processes. And these different points of governance, POG, have different objectives. This is starting to sound complicated, and the answer is: it can be. The point here to be taken is that the bigger picture should always be in sight. As long as we understand what we are trying to accomplish and at what points they should occur, things get simpler and more effective. Let’s look at the bigger picture.
Think of the two ideas: create and operationalize. Most of what we do falls into this simple concept. We want to create something new then we want to make it available to our consumers. What should we use to create new solutions or services? An enterprise architecture framework. How do we safely implement what we have created? Our ITIL processes. So let’s go a few levels lower in this model.
The enterprise architecture framework provides us with a method of translating business goals and objectives into IT goals and objectives. And it helps build an IT strategy, which is important because this is one of the first objects that drives our governance process. As a new project is spawned, a governance body ensures that it is related to the IT strategy, and the current run-and-maintain objectives should review it. I mention run and maintain because most of the time when talking about IT strategies, people only address new capabilities and not how to maintain what is already in place. So this is the first point of governance, the first gate if you will: is the IT strategy fit and also financially fit?
From this point, all IT groups should be notified that there is a new effort that is being started. I say all because there are different and complicated ways of determining whom to involve but the easiest is to involve all groups at first. This is an important point in the process. Many efforts and changes fail because not all groups that should have been involved were actually engaged. Imagine if we put a new application or service in place but didn’t work with the storage group around backups or DR from the beginning. Or, what if the network group wasn’t consulted about the increase of traffic? When the change is ready to be implemented, it is already on the path to failure. This particular case happens quite often in IT organizations that do not have a good architectural process that links all IT groups together.
Once the design actually starts, there should be an initial design review. This is a good time to provide to all the other lines of service the requirements and potential solutions. The requirements are good for all groups to review since they are all viewing the problem from a different angle. It’s the perfect time to solidify the requirements and to start ruling in or out high-level solutions. Now starts to enter IT standards. IT standards play just as much of a role in the EA process as strategy and financial. So from now moving forward, the governance body must assess the project for fit of the IT strategy, financial, and IT standards.
As the design progresses, there can be more reviews until the final review. The final review should be a point where all IT organizations have a vote to move the solution to implementation or not. This is the final time that the design should be halted and either rejected or sent back for rework. Hopefully, if the IT groups are working together as they should, items that would halt the implementation should have been identified long before the final approval. Once the final approval has been given, it enters the ITIL processes.
The ITIL processes will ensure that all of the items are in place to create or change a service and to place it into operation. We could use the Service Strategy and Service Design parts of ITIL if needed. It can go right to Service creation and the change management process to implement depending on the type and magnitude of the change. If the processes have been followed as discussed earlier, the change management review activity becomes a coordination exercise. No one should be surprised by the change or have objections to the design by now. Governance activities here include adherence to the CM process rather than design reviews.
The above flow was just an example and can have endless variations. But the theme should be to make a list of what your processes are trying to accomplish, then whiteboard the entire IT process from beginning to end, link different processes together, and indicate at what points you want to accomplish the process objectives you identified.
