Abraham Maslow is credited with saying that “If the only tool you have is a hammer, you tend to see every problem as a nail.” In my opinion, effective process engineering requires that you use a complete toolbox of options or you risk becoming a one note player. One of the things I like about service management is the broad perspective it takes on viewing things. To be truly effective, you need to see the problems or constraints from more than one vantage point. A true IT service management consultant would recognize that one process does not fix all things. Nor dare I say is ITIL a perfect tool for every situation: there are many frameworks you can leverage to deliver value.
One of the risks I see in implementation work is a narrowing of perspective. Maslow also said: “He that is good with a hammer tends to think everything is a nail.” As individuals begin to implement process, there is a real concern aligned to this quote. The tendency is to focus inward and rely on what has worked before. Process not working correctly? Add more process! As people get good at what they do, my experience shows that they forget some of the basic fundamentals in process development and implementation. I do not advocate doing ITIL as written. I would suggest that people who profess to be experts should remember to read the books, and consider them as a point for guidance. My Service Support and Service Delivery books are well thumbed from years of practice. ( I must confess, my V3 copies being pdf’s are not so well perused.)
The challenge we face as implementers of process is that people have a tendency to focus inwardly on the task at hand. A recent experience with fixing a change management process is an example of this challenge. The client had trouble with categorizing and classifying changes. The process team reviewed what was being done, saw a gap in the classification of requests for change and immediately set out to fix the gap. The end result was a seven (seven!) page risk assessment form for individuals to use when completing a change request. I asked the process team about the goal of change management. Sure enough, they knew their ITIL: “The prompt and efficient handling of all changes, to minimize change related incidents”, was repeated back to me. So I asked, how is the seven page form working out in relation to your goal?
As it turned out, their colleagues were not using it, and were avoiding filing changes at all. A quick review, interviewing key stakeholders and they identified the problem. That is to say, “We told them the classification scheme was difficult, their fix was to add more complexity!” The process experts saw the fix as adding more check boxes to a difficult form. However, they made the changes without considering either the goal of their process, or the impact: more lost time filling in forms, more grumbling about bureaucratic process. The change manager had tried to fix a problem by adding in another process based nail. Getting the job done, focusing on what he knew, but losing sight of the fundamental goals of the process.
The frustrating part was that there was a quick solution available. The organization in question had a good project management office. The change manager and I went to visit the PMO. There we had a discussion about risk assessment. The PMO had a simple model ( 8 questions not 7 pages). We borrowed this for change management. The change requestors now had a simple risk form, which aligned to their project office. In many cases, they were already completing this form as part of their project requirements. Some minor tweaks to fit the change process and we had a win-win solution by using a form that was already in place.
|
Change risk impact form |
|
|
A. What is the service impact if this solution is not available? |
A. Critical – other service is lost or becomes unusable if this service is lost B. Important – usability and efficiency of the other service is severely impacted if this service is lost (e.g. data lookups are not possible C. Minimal – other services function well |
|
B. What is the risk for not implementing the change |
A. High - business will not be able to use system B. Medium - part of the functionality will not be available C. Low - no implications for the business |
|
C. Has this solution been developed before? |
A. Completely new technology and/or process B. New developments on existing technology and/or process C. Uses previously deployed tools and process |
|
D. Are test plans and acceptance criteria in place and documented? |
A. Test plans are not developed B. Test plans are under development C. Test plans have been created and are compete |
|
E. Are the resource requirements understood for preparing and deploying the change? |
A. Resources are not fully understood B. Resources are estimated but not ratified hours C. Resource requirements are available |
|
F. What is the impact on existing applications and infrastructure? |
A. Extent of affected/related applications, infrastructure and/or processes are not understood B. Extent of affected/related application, infrastructure and/or processes are estimated C. Extent of affected/related application, infrastructure and/or processes are well known |
|
G. Are there any scheduling/outage requirements? |
A. Change requires scheduling outside of normal Change windows B. Change may exceed change window C. Change can be completed inside of agreed change windows / No outage required |
|
H. Have support documentation and processes been completed? |
A. Documentation / updates are not available B. Documentation is being developed and / or service desk has been notified C. Change aligns with existing documentation, and /or support teams have been provided with relevant notices |
Linked to the change categorization schema, the form is used to assess the change category. This tool is linked to the online request for change form.
The change requestor and/or change coordinator respond to the questions. The following formula is used to establish the change category: A = 5 points, B = 3 points C = 1 point
Scoring of the change will result in a risk total. You will need to determine your own thresholds for major, medium and minor change categories. Align the reference examples and criteria with your own organization. For my example, we ended up with >30 = major, 15-29 = medium and <15 = minor. With one rule, namely that anyone on the CAB could request a more complete review.
One of the things I liked about this template was the inclusion of existing tests, processes, and support documentation. As we built a library of resources, we fed them into release management. It made changes and releases faster and more consistent, resulting in effective and efficient processes.
In summation, the power of being a service manager lies in knowing the processes and using the entire set of tools at our disposal. If you become a process only expert, every problem looks like you need to add more process to solve. However, when you stay focused on being a service manager, every tool in your framework tool box is available. Do yourself a favour and ask some trusted colleagues if they see your process as an added value or as a bottleneck. Take a good look at your process. Ask yourself if it fully supports the goal. Try to align it to existing elements wherever possible. That is how you make your process approach a valuable tool to your organization, instead of one more tick box or check point people need to complete.
Comments