The Seven Guiding Principles | The ITIL 4 Big Picture

How to use the Guiding Principles? Explained along an example

All of the Guiding principles explained above represent value on their own, however, they are most effective when combined properly. Probably, you have already noticed it while reading through them, that they have links to one another. Some more than others, but we can generally say, that for best results those links should be leveraged.

For example, thinking and working holistically will help you gain a better focus on value. Or after you have started where you are, you should progress iteratively with feedback. How about keeping it simple and practical before optimizing and automating things? Makes sense, right?

So let’s see a specific example that will help us understand.

The Situation

You are the Head of IT Operations in this medium-sized, international company, and you have been tasked by the CIO to implement a new ITSM Ticketing tool replacing the current one. This tool has been around for about 10 years and it was state-of-the-art at that time. People were generally happy with it, but time has made it clear that it cannot compete with more modern tools anymore. Neither in terms of functionality nor in terms of performance.

A vendor / tool selection tender has been run and the new tool has been selected and approved by the senior management. Now the time has cometh, where you need to coordinate the implementation of this new tools. So let’s see the Guiding principles and their possible application (don’t forget…this is my interpretation and there might be other ways as well)[/vc_column_text][/vc_column][/vc_row]

itil 4 seven guiding principles itsm tool value insights training switzerland

Applying the Guiding Principles

Focus On Value

Try to understand who your stakeholders might be and talk to them. This might include business people, end users, Service Desk personnel, IT infrastructure people, server admins and many more. Learn about their pain points, what they hated about the old tool and what they liked about it, what they would not want to miss. Understand, which ITSM Practices were covered by the old tool and decide if everything of that is needed in the new tool as well (e.g. Incident, Service Request, Problem, Asset Management, Change Enablement, etc.). However, you need to keep in mind that you cannot always satisfy everyone. You should have a more holistic view on the matter and aim for the greater good, but more about that later.

Start Where You Are

Think about how resources that are used by the old system can be utilized for the new one. What about servers that will be freed up when you start decommissioning the old tool? Maybe you can reuse them. Or how about licenses? Maybe you don’t need to buy a completely new set. How about personnel? Do you need to hire new people or external consultants or can you somehow utilize the knowledge already available in your organization? As stated in the situation above, many practices were covered in the old tool. It might make sense not to include all of them in the first release. Perhaps starting with the most important ones makes more sense. Which leads us directly to the next Guiding Principle.

Progress Iteratively With Feedback

Once the most important features and functionalities have been identified, it would be safe to say, that we have gotten ourselves an MVP (Minimum Viable Product). This could act as the first deliverable in an Agile delivery approach such as Scrum. As a result, we could formulate the requirements as Features / Epics and User Stories to utilize the short delivery cycles typical for the Agile world. Which, in return, would lead to more feedback from stakeholders. Which, ultimately allows us co-create value more accurately and to increase stakeholder satisfaction.

Collaborate And Promote Visibility

Working together with your stakeholders is essential for value co-creation, and without transparency you will have a difficult time. Therefore, you should ensure that you have involved the right people in the right manner. You could create a stakeholder matrix, visualizing the different stakeholders, their interest in the project and their decision making power. Having a Kanban or Scrum board certainly helps to visualize the progress and possible bottlenecks. Applying a Scrum based approach generally improves the transparency, as the Scrum Masters would take up every impediment that hinders your teams. And last but not least, you should aim to build psychological safety and allow people to fail, so they actually highlight issues instead of hiding them.

Think and Work Holistically

And again a Guiding Principle that has its roots in the Agile world. It suggests to break down the silos in our organizations and extend our fields of view beyond our own little “kingdom”. The “us vs. them” mentality can kill any improvement effort in the blink of an eye. Therefore, we should always try to understand the bigger picture, at least on a high level. I mean, it is not possible to know every detail of every team / system / service of an organization, but we should at least understand how the cogwheels of the corporate machinery come together, enabling value. More and more companies realize the need for this and have adopted the teachings of DevOps or even DevSecOps. The Scaled Agile Framework, alias SAFe, brings it quite precisely to the point with the “Organize Around Value” Principle. Understand what is valuable to your stakeholders and build your organization around that instead of building your teams by function.

Keep It Simple And Practical

Easier said than done. Often we want to deliver the golden egg, the pinnacle of solutions, the perfect project. But that is not the ideal approach. Instead, we should keep the Pareto Principle in mind, saying that 80% of results can be delivered with 20% of the effort, while the remaining 20% of results need the other 80% of effort. In our current example, it would be advisable to concentrate on the MVP first, which would already cover the most important features. After that, our iterative approach would allow us to continually align our deliverables to the needs of our stakeholders. However, we should always apply a holistic view to identify those features, which are relevant to most of the stakeholders. It does not make sense to start delivering the very specific features used by only a small group of customers. One great way to identify the order and priority of deliverables is called WSJF (Weighted Short Job First). This approach promotes the delivery of the low hanging fruits first (short and valuable tasks), followed by valuable but bigger tasks, followed by not so valuable smaller tasks, followed by not so valuable bigger tasks. Do this exercise with your stakeholders regularly and you cannot go in the wrong direction.

Optimize and Automate

In our project to implement this new ticketing solution, we probably have a good knowledge on how things were done in the old system. And while some of that can be reused, as seen in the “Start Where You Are” principle, some might be suboptimal. So, why not give it a thought or two, and identify opportunities for improvement? For example, we could have a look at new technical features of the new tool to see if some of our old workflows could be optimized. Perhaps, some parts of the solution allow for automation where previously we had manual processes. Furthermore, we could also think about how to automate the delivery of the new solution. I mean, we probably have a DEV, TEST and PROD environment. So we could apply DevOps principles again to automate the releases and the testing. Many modern ticketing tools allow us to automate the categorization, assignment and maybe even the fulfilment of tickets.

Imagine this: You have a self-service portal where users can order the installation of standard software applications on their PCs. The user places the order -> the line manager approves it -> the ticket triggers a workflow -> which assigns a specific AD group to the user -> which triggers the installation via the software distribution tool utilized in the company. What a dream 🙂 but it can become reality with a bit of automation.

Conclusion

Too long, didn’t read? Here is a summary.

The Seven ITIL 4 Guiding Principles are simple statements that set our mind into a more value-focused, collaborative and agile direction. Besides that, they are universally applicable in virtually any situation and project. Furthermore, they are best applied in combination but can be valuable as stand-alones as well.

Should you struggle to select the right ones to start with, I would suggest to go for “Focus on Value”, “Start Where You Are” and “Progress Iteratively With Feedback”. These will give your organization the right focus and will allow you to produce some quick wins, which will spark the excitement in people increasing their hunger for more.

If you would like to hear a short summary about the ITIL 4 Guiding Principles, you can have a look at this short video from our free ITIL 4 Foundation exam preparation video series on YouTube.