Let us remind you briefly that the guiding principles are part of the SVS (Service Value System), which we wrote about in the previous article. These are universal recommendations that govern organizations at all times, regardless of size or structure. Don’t expect anything revolutionary. It is essentially just years of proven common sense that reflects current developments in management thinking. It features echoes of Agile and digital transformation. According to the ITIL 4 Foundation, it encodes ITIL’s main message because it supports “successful actions and good decisions of all types and at all levels.”
While guiding principles may seem trivial at first glance, experience shows that even simple ideas are not easy to apply consistently in everyday decision-making. That is why we will not only introduce you to the guiding principles, but also consider why it is sometimes difficult for us to follow them. But we’re getting ahead of ourselves. Today’s article will present the first four principles, in the next we will explain the remaining ones and discuss problems with applying the principles. To make the articles as practical as possible, we will illustrate all the principles on the example of one project: creating a new website for a B2B company.
Focus on value
The new site is supposed to bring value, that’s for sure. Therefore, first we identify who the users of the service are. For a new website, it will mainly be potential customers, for whom the website should answer all important questions in the purchasing process. The second group will be existing customers, looking for support. We must also remember other stakeholders (interested parties or groups). Marketing and sales need the site as one of their main tools to reach out to potential customers. At the same time, marketing people manage the content of the site and need a user-friendly environment. Human Resources will advertise vacancies on the site.
So now we know who’ll be using the site. Now we can ask about value, from the users’ point of view. Why do they visit the site? What are they interested in? How will the site help them achieve their desired results? What devices do they use to make their visit? It is important to always define value in relation to customers and any stakeholders. Avoid vague definitions and waffly terminology. You really need to understand users’ motivation.
But focusing on value doesn’t end with the design stage. It has to be part of everything we do. ‘Focusing on value is like a rear-view mirror I constantly check and see my customer in. Whatever stage I am at, they’re right there in the background,’ explains ITIL expert Rudolf Slaba.
Throughout the life of the website, you can track how visitors use it. That way, you’ll get a better understanding of what they’re looking for. You can also keep in touch with those responsible for managing the content and get their feedback about any system shortcomings. You can communicate with the sales department and understand how their priorities are changing. There are plenty of possibilities.
Start where you are
When we embark on new projects, there is always the temptation to get rid of existing systems and replace them with something completely new, better and modern. Resist the temptation. ‘Building on a green field is the most expensive way I can create something,’ says Slaba. ‘I always assess what I already have at my disposal, what elements of the existing solution work well.’
When it comes to web pages, you can look at the statistics for the existing site. You will find that some pages are well-visited, while others minimally so. On some pages the user spends a good ten minutes, and others they leave straight away. Similarly, you can consider the editorial system the site runs on. Will it really be necessary to switch to a new editorial system, or just to install new features in the existing one? We have to be careful not to be led astray by our assumptions. We may think we have a good sense of our current situation. But considerations must be based on hard data and direct observation.
‘Sometimes in a meeting the customer spends ages explaining the situation. In fact, it is often better to pause the meeting in such a case and go together to look at the operation itself, together. Once there, everything is suddenly clearer, because we see the problem in its natural setting,’ adds colleague Jirka Janků. Add the appropriate metrics and data to your observations. But metrics should play a subsidiary role, in truth. Never substitute for direct observation by reading reports.
Progress iteratively with feedback
This principle can be seen as ITIL’s response to Agile. Much has been written about the Agile approach. Let us bear in mind that Agile was created in response to the waterfall approach to project management. That one brought a lot of problems with it. A huge amount of energy went into planning and thinking through solutions, with yet more time spent implementing the project. When the finished work was then handed over, the client often did not recognize their original intent in it at all. On other occasions, the situation had changed meanwhile and the initial analyses were only fit to be thrown out. The proposed solution was outdated before it could see the light of day.
‘Waterfall projects are like a marathon runner in the desert. Without feedback, he can’t run straight, but starts to veer off gradually. With waterfall projects, people get put off by huge analyses, and sometimes it takes months for any work on the implementation of the project to begin,’ is how Rudolf Slaba describes the situation.
Conversely, the principle of Agile management is to divide work into sub-sections, which are better manageable. At the same time, each completed section can be immediately presented to the client. This gives you a live project with continuous feedback that you can respond to flexibly. It is often best to start the project head-on and implement a token sample output as quickly as possible. That can be enough to tell if the project is even viable.
How can a business be Agile in our new website example? Let’s design the basic structure of the site. We will immediately make it available to key stakeholders, for feedback. We make a mock-up of each page. The feedback wheel will turn again. After the basic designs and content of the pages are agreed, the web designer creates the first imperfect prototype of several pages. Once a customer sees them live, they notice aspects of the site that they haven’t thought through before. Every step on the way to the new site is met with feedback.
Collaborate and promote visibility
If the previous principle was a reaction to Agile, this one can be considered a reaction to DevOps. If you’ve ever solved a problem and felt like you’ve been in some kind of fable on a wild goose chase, where one team sends you to another and then another, then you’ve experienced an organization divided into ‘silos’ first-hand. These are the situations when instead of cooperating you see entrenched and isolated teams, whose processes, systems and documentation live a life of their own, like a company within a company. It’s a self-satisfied culture, one not inclined to share their ball for others to play with.
ITIL advises the opposite. Look for opportunities to collaborate, share all information openly. For example, for our web project, management can view the product documentation at any time, the first prototype of the site is shared with the sales and marketing departments and is available to anyone in the company. The programmer works closely with the people who will operate the editorial system, so as to discover any problems before going into live operation. We avoid situations where anyone works on their own (sub)project in isolation without allowing others to look at it.
‘We can always look for practical ways to facilitate cooperation. Sometimes choosing a suitable communication channel will help, at other times you might move the entire project team onto the same floor. In an established operational setting, you can move teams around from time to time. It disrupts entrenched routine and people get a chance to get to know their colleagues more personally,’ Rudolf Slaba advises.
Also, do remember that cooperation does not necessarily mean unanimity. It is possible to work together with a broad group of people without everyone being in consensus. Sometimes it is enough for work in the organization to be coordinated so that people do not harm or interfere with each other. And some people do achieve excellent results when they can work largely independently. Let us remember IBM’s motto ‘treasure wild ducks’, which we can very loosely interpret as ‘value those who push the boundaries’.
Dive deeper into ITIL principles with part two of this must-read article