6. Keep it simple and practical – the sixth guiding principle of ITIL4
With the new and updated version of ITIL there is also an update on the 9 guiding principles first introduced with ITIL Practioner. These new set of 7 principles provides practical help with making decisions when adopting the ITIL4 framework:
- Focus on Value
- Start where you are
- Progress Iteratively with feedback
- Collaborate and promote visibility
- Think and work holistically
- Keep it simple and practical
- Optimize and automate
In a series of blogs I will look into each principle asking how these will provide guidance when adopting the ITIL4 framework and when improving the service management capabilities of the IT provider. To me these guiding principles should support the decision making when adopting or improving IT service management. It is also important to note that these principles will have to work together. The principles will not work in isolation, it is not a matter of pick-and-choose.
Keep it simple and practical
After the principle to think and work holistically you might feel like you are floating above your IT service organization to see the bigger picture. This principle will bring you back to earth: keep it simple. Do not overthink and get lost in the complexity. Like with principle 3, to progress iteratively with feedback, this principle is all about getting things done in a way that is manageable and helps making your organization move forward.
That is not that easy to do
Unfortunate, keeping it simple is not a simple principle at all. It can be actually hard work and it is easier said than done. What does it mean to keep it simple? It is a judgement call and it is bit subjective as well. It depends on your organization’s capabilities and potential. What is simple when you know what to do and you have the tools to do it, can be hard to do when you have no clue and are missing those tools. One consequence of this principle and in line with the principle start where you are it is important to understand the capabilities and skills of your people and your organization. It is hard to do simple stuff when you do not know what you are doing. And it also means that you start with what you know and go from there.
Occam’s Razor
When dealing with discussions on how to use the guidance from ITIL and turning these best practices into working processes and procedures it is a good idea to take Occam’s Razor into account: “Entities should not be multiplied without necessity.” Often Occam’s Razor is misunderstood to mean that the solution that appears to be obvious is going to be right. Occam’s Razor is actually about when dealing with different solutions that have the same outcome to go for the solution with the fewest assumptions. And there will always be assumptions on what people will do and how they will behave and what decision they will make. Occam’s Razor is about finding the solutions with the least amounts of ifs and buts involved.
Define the outcome
When working with the guidance provided by ITIL what should be first to is a discussion (with the business and other stakeholders) on the expected and desired result of any practice or processes in the service management implementation. Often this result can be described in two ways: output and outcome. Processes take input and turn them into output with a feedback loop as well to verify the output. This is to verify if the output resulted in the desired outcome. The outcome of the process is an aspect of the contribution to value that IT delivers. A stable IT platform will enable the business to sell more, deliver more, contribute more and to create more value. A stable IT platform is the desired outcome and the IT organization can take responsibility for this outcome (agency).
There are several challenges to the stability of an IT platform and one of these are changes to the platform that can lead to unscheduled outages and all kinds of other issues. The IT organization needs to manage these changes: change management. The outcome of change management is that changes to the IT platform do not end up disrupting the performance and availability of that platform. The output of change management are changes made to the IT platform under control of the IT organization. Changes that effected negatively the desired outcome are learning opportunities to improve how changes could be better executed next time.
Identify the steps necessary for the outcome to happen
What are the steps from a change request (input) to the change being implemented and all the consequences managed and dealt with (output) leading to a stable and trustworthy IT platform (outcome)? What ITIL provides is guidance on steps and process flows in general and it is up to your own organization to find the possible specific steps. These might not necessary be the same. You might already have some steps in place that overlap or are very similar to the ones ITIL has identified. It doesn’t make sense to duplicate steps because of ITIL guidance. That would make it already more complicated.
Now, identify the assumptions behind these steps
Both ITIL and your organization will have certain assumptions why steps are identified. One important assumption in ITIL is that most organizations are quite large and that there are many people working in the IT department. That assumption is useful to separate roles and responsibilities more clearly and you end up with all these process managers, coordinators, support lines, etc. In reality you might find that ITIL defines more roles than you have staff working in your IT department and that you need to combine some of these roles.
The assumptions behind the steps you have defined are most likely to do with assumptions on the skills needed to do work, on the authority needed to make decisions, on the motivation of your staff, on the complexity of the technology, on the IT-savviness of your business users, on the amount of work people can do in any given time, on the possibilities of technology and many more. The power of tools is one of these assumptions that often leads to lots of money spend and lots of disappointment in the results.
Does staff really needs to be told what to do?
Another powerful assumption that can lead to a lot of complications is to underestimate your people. Unless your staff has experienced some traumatic events or is in a toxic environment they are often motivated to do a good job. When ITIL consultants or trainers come along there is often this idea that the engineers and helpdesk staff needs to be told how to solve an incident or how to implement a change as if this is something new. These consultants will come with Visio diagrams, PowerPoint presentations, templates in tools and manuals describing all kinds of process flows in detail. And they will complain that your staff is not getting it and are not following the ‘right’ procedures. (disclaimer, not all ITIL consultants and trainers are like this). In reality your engineers already know how to solve an issue and how to work with new technology. They probably were doing this for some time now. The issue why working with ITIL is a good idea is to better organize and structure the work that IT does to better align with business needs and expectations.
It makes more sense to share the desired outcome and results with the engineers and developers involved and to discuss the best ways to accomplish these results. To start working the way they have suggested, monitor the results and have reflection and feedback sessions to see how they are doing. Make improvements where necessary and repeat. If you feel a bit anxious working in an experimental way in live production you might want to try using a business simulation as an alternative (like Gamingworks Marslander). Engaging your staff in a practical way to discuss steps to get to the desired outcome will give the best guarantees that they will try to work in the new way and are open for feedback if they don’t.
Do only what helps achieve the right outcome
Challenge assumptions whenever that is possible. The steps that are based on the smallest amount of assumptions are, according to Occam’s Razor, possibly the best steps to take to reach the desired outcome. Have assumptions articulated and have them put forward so they can be challenged. Many IT departments are risk averse for good reasons. If you do not state the particular risks that are involved than you cannot discuss measures to deal with the consequences or find ways to mitigate. If you cannot discuss risks in this matter than being risk averse is not a very helpful situation. It means only that the IT department is afraid of making decisions and doesn’t feel empowered to deal with consequences. In those situations the IT department cannot take responsibility for any outcome.
Keep it simple and practical
Challenging assumptions, articulating risks and reflecting on outcome and on potential improvements are not the easiest actions to take. It takes people out of their comfort zone and might heighten a sense of conflict and contradiction. It needs to be done with respect and in an environment that is supportive and safe. Keeping it simple is hard work.
As a guiding principles in ITIL4 this principle feels a bit unnecessary. Some of the other guiding principles already feel more like common sense and have an high Dûh factor. If you take the principle to focus on value then it follows that you need to define outcome for the different activities in the IT service organization. If you follow the principle progress iteratively with feedback then it follows that you define practical steps and reflect on the contribution to the defined outcome. It is not that I disagree with principle itself, it is more that my experience is when people hear “keep it simple” they tend to translate it in their heads with “keep it shallow”. And as I tried to argue in this article, I feel that in order to find simplicity you have to go deep. To find simplicity you’ll have to give up on a lot of ballast and that requires hard decision making.
Principle 5: Think and Work Holistically
Principle 7: Optimize and Automate