Think about guiding principles as a set of boundaries that are drawn. You can play within these boundaries and, at no cost, cross them. Well, to rephrase it, these are more like recommendations and not rules or policies that you are bound by. The nonprescriptive nature of ITIL is perhaps one of its strongest suits, and it continues the legacy with the guiding principles.
The concept of guiding principles is in fact new to ITIL. It started much later in 2016 with the ITIL Practitioner certification. To start with it had nine guiding principles, and in ITIL 4 there are seven. This does not imply that the list has been trimmed down. The principles have been revamped from the outset, expanded, and some of the principles are combined to make the list comprehensive and still not cumbersome.
- 1.
Focus on Value
- 2.
Start Where You Are
- 3.
Progress Iteratively with Feedback
- 4.
Collaborate and Promote Visibility
- 5.
Think and Work Holistically
- 6.
Keep it Simple and Practical
- 7.
Optimize and Automate
Guiding principles
The guiding principles are the most important topic on the ITIL foundation exam from the number of marks that it can carry. You can expect to get five questions on your ITIL foundation exam—that is 12.5 percent of the total questions. The questions will test your understanding, and you will be required to apply your understanding for answering the questions. Therefore, I have delved deep into this topic to ensure your maximum probability of success.
ITIL Definition of Guiding Principle
A recommendation that guides an organization in all circumstances.
In my opinion, these guiding principles are not restricted to ITIL and service management alone. You can apply them to any industry and it would be true. In other words, they are universal and more importantly, practical. Every one of them is common sense and yet needs to be reminded at every step of the way.
In several ways, ITIL’s guiding principles follow the Agile manifesto. For example, working software over comprehensive documentation is a classic example of where we lay emphasis on things that embellish but not the core value. Guiding principles Focus on Value and Keep it Simple and Practical gel well with it. Likewise, responding to change over following a plan is embodied with Progress Iteratively with Feedback.
Agile manifesto states (not in scope for ITIL Foundation exam):
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Every organization implements service management in its own way. There are several other frameworks and methodologies in use. Organizations will choose to combine and mix different methodologies and frameworks to come up with a customized framework that works for them. The guiding principles ensure that they allow enough room for these frameworks to combine and synergize. It is important to note that the guiding principles work toward creating value for the customer and help improve products and services on a continual basis.
Agile methodology provides guidance for how projects are to be run in an Agile manner, which promotes flexibility and dynamism. Value is generated through meeting changing customers’ needs. DevOps goes one step further by acting as a superset for development and operations. While development processes are managed through Agile, operations are done through ITIL. Merging the two frameworks/methodologies is not seamless. When you have a common team working on both, you are bound to have conflicts, like how you prioritize one over the other. It is in such situations that overarching guiding principles would come into play in providing direction. For the example of prioritization, keep creating value as true north. Then, you weigh the various development and operation items against the value they create, work on an item that generates the most value, then move down the list. Of course, I have diluted the scenario quite a bit. You will have other factors in play, and the product owner will act as the value determiner. Similarly, for other frameworks such as Prince, Lean, COBIT, and others, you could apply the same set of principles to bring them under a common north star.
An organization should not pick and choose the guiding principles that are applicable to them, because all of them come as a box set and it makes practical sense to practice them. However, not all guiding principles are applicable in all circumstances and scenarios. An organization should identify the guiding principles relevant for the scenario and use it (them) judiciously.
Identifying the seven guiding principles is important. However, what is more important is the context in which each guiding principle is brought into action.
Focus on Value
ITIL Definition of Focus on Value Guiding Principle
All activities conducted by the organization should link back, directly or indirectly, to value for itself, its customers, and other stakeholders.
A service provider exists not to provide services to customers but to provide value through services. How does a service provider achieve this? As per the ITIL definition, the service that is offered must be dissected in terms of its deliverables. Each of these deliverables must be mapped to the service consumption and the business processes at the customer’s end. Through this exercise, a service provider will be in an ideal situation to measure if the services offered are generating value, and if more value can be generated by tweaking services and in the process can create value for themselves along with other stakeholders involved through the value generation lifecycle.
Picking the Netflix example, the video streaming service provides ample value to customers who like to be entertained and who want to pass boredom by doing this. They gather data from their customers on the genre, the language, and the age ratings that are streamed by their customers. This information is used to recommend other available shows to customers and to fund new shows that are on similar lines as the demand indicates. This exercise of Netflix gathering data and using it wisely is an example of generating more value for the customer. In the process, Netflix too creates value through the content it produces, which could lead to additional customers signing up. Other stakeholders like the production companies, story writers, and actors also become part of the value generation and create value for themselves through video production.
- 1.
Understanding the service consumer
- 2.
Understanding the service consumer’s perspective
- 3.
Obtaining feedback from the customer
- 4.
Applying the learnings
Understanding the Service Consumer
Value generation 101 dictates that you know the person who is going to enjoy your service. Unless you understand the consumer’s desires, tastes, needs, and necessities, you cannot aim to deliver a service that makes them happy. A service consumer is generally happy if the service generates value and can deliver its intended purposes.
A Mexican restaurant that wants to open in a neighborhood studies the surroundings before setting up their enterprise. Depending on the class of people and the ethnicities, they decide on whether to open shop. This restaurant is likely to run well in a neighborhood that has ethnicities that prefer spicy food, such as Indians. A typical Chinese neighborhood would prefer something closer to Asian than western, for example.
Apart from the service consumers themselves, a service provider must look toward understanding the other stakeholders in play, like sponsors who will be funding the service, the customers, and others, as necessary.
Understanding the Service Consumer’s Perspectives
Knowing the consumer is information. Getting to know consumers and their needs in depth is knowledge. The service provider must aspire to go in depth—not just getting objective answers to questions but to truly understand them by going into the perspectives. This would typically be answering the 6Ws – who, what, where, when, why, and how.
- 1.
Why the consumer uses this service?
- 2.
How does the service generate value?
- 3.
Who uses it?
- 4.
Where and when is it used?
- 5.
What is achieved through the services?
- 6.
What are the financial limitations for the customer?
- 7.
What risks are involved that can be foreseen?
Remember that value has a lot to do with perception. You might be brilliant at offering fiber-based broadband Internet service. But if your brand has a negative perception, customers may go elsewhere. So, it is essential in the value generation process to measure value through the eyes of the customer rather than mere numbers. Second, the perception of value does not always remain constant. A beautiful vacation spot in Scotland could have zero visitors in the times of a pandemic, for example. Finally, costs and risks play a significant role whether a customer chooses a service provider or not. Customers may not opt for cheap services for fear that their quality may be substandard, and opt for something reasonable and fair instead.
Obtaining Feedback from Customer
Feedback is like gold dust in the service industry. With the changing perceptions of value to a customer, keeping up with them is a challenge for service providers. So, they try and obtain feedback from their customers on various factors. Try and map this to the 1,001 emails you receive from your service provider seeking 2 minutes of your time. Clicking on this link in the email will take you to a survey that’s aimed at understanding your potentially changing perceptions.
The feedback mainly tries to understand the customer experience (CX), which is also referred to as user experience (UX). CX is defined as the product of interactions between an organization and a customer over a period, with respect to products and services. This experience/feedback will provide information about how a customer feels about the product/service and the organization providing it.
As I mentioned in the previous step, it’s a game of perceptions. CX is based on how a customer feels about a service. For the same service, you will have one set of customers who might love it and an equal measure who might hate it. Take the example of a movie. You have certain critics who are extremely critical and others who hail with big praises. When you look across the spectrum, you will find customer experience expressed in various shades of gray. A service provider organization in such a situation would look at the majority perception, and if the popular feedback is to make certain changes, they will definitely opt to do so.
Applying the Principles/Learnings
What is the point of conducting surveys, taking feedback, and spending tons if you are not going to use the knowledge to make changes to products and services? It’s like a fisherman taking all the trouble to go into the deep sea and catching a fish only to throw it back into the sea.
- 1.
Understand the customer, the customer expectations, and perceptions.
- 2.
Collect feedback on the service from customers, consumers, and other related stakeholders. Feedback should be obtained across the period when the consumers enjoy the service.
- 3.
The service provider’s staff to be made aware of the customers’ interests, their likes, and dislikes. Further train the staff on improving customer experience.
- 4.
Value creation should be done at every step of the service, especially during operations. It is in the operational stages when users interact the most with the service provider staff. So, this is a critical interaction that directly affects value generation. During other project phases such as initiation, design, and improvement, ensure that the customer is factored into co-creating value.
- 5.
People from the service provider staff and the customer organization must be stakeholders in the value generation process during any improvement activities undertaken. Make transparent what value means, how it is measured, and how the parties come together in creating it.
Understand the theme associated with value like focusing on the consumer/customer and their perceptions, feedback, and acting on it. It is like the PDCA cycle. On the exam, you can expect questions that will test your understanding of how value is created.
Start Where You Are
Think about body transformation. To look like a Greek god, you can only start from the current state of your body and start your regimen toward transforming your body. You cannot just say let’s scrap this body and start afresh. It does sound ludicrous doesn’t it? Yes, it does and for a reason.
Many a time, when organizations jump into transformation exercises or even where they need to get to point B from point A, it is exciting and tempting for those involved to start everything anew. Without the overheads of the current state, the architects would be able to build anything they want and design masterpieces. In reality, it doesn’t work this way. To start something from scratch, you need huge capital, and not only financials. It takes more time to get to point B starting afresh and, most importantly, getting used to the new ways of working will never be a smooth ride. Finally, there could be a solid base today that we totally ignore for the sake of excitement.
In this principle, we encourage starting from where we are rather than starting all over. We look at reusing the basic core rather than laying a new foundation. And we define a process to make this judgement call.
More than once I have mentioned that the present and the future is in the DevOps space. For a traditional development and service management organization to switch over to DevOps is a massive challenge. Implementation of DevOps happens in phases, where we try and reuse components of the existing processes and integrate them into the holistic methodology. By doing this, users, staff, and other stakeholders do not feel alienated from the existing processes and resist the new ones.
Assess the Current State
Before you make a call on changing anything, it is worthwhile to see where you are currently. It may not be an arduous road to the intended target if you start with what you have. Or it may be better to scrap everything and start with a blank slate. The answer to either of these options can be obtained if the current state is assessed objectively.
It is often the case that we set out to change something by creating it afresh, and the current state assessment is done merely as an academic exercise; then it is quite possible that we will end up with assessment results that point toward starting afresh. Conversely, if you are bent toward building on top of what you have, the assessment will be colored in the way intended.
Therefore, it is crucial that the assessment carried out is unbiased and is purely seen through the eyes of objectivity. The assessor must therefore put on the hat of an inquisitive child that questions every single move, to identify the motive and to get a true sense of reality.
The true sense of reality can be obtained through measuring. Measurements too can be colored through interpretation. So, it is recommended that the measurement parameters are laid bare, with no ambiguity, and measurements are taken from the source and automated wherever possible.
Measure Everything
When I started my journey on a body transformation, the first thing that my trainer asked me was if I owned a measuring tape and a scale. He emphasized that the baselines need to be measured before we start the journey, and we needed to keep measuring and recording the measurements every single week. How else can we know that something is working unless it is measured?
In service management, several metrics are gathered and key performance indicators (KPIs) are tracked. However, where some of the organizations can possibly go wrong is by measuring the wrong numbers.
Going back to outputs and outcomes: track outcomes, not the outputs. The service desk is often pegged with a KPI known as first time right, which puts the onus on the agent to resolve the issue while the caller stays on the line and not have to put the ticket on hold or pass it to a colleague. To accomplish this KPI, the agent might try to close out the call with an incomplete resolution leading to a desired output but not necessarily a favorable outcome. This will most likely leave a bad taste in the customer’s mouth and the outcome of the service does not generate value in any sense. Instead of measuring the first time right parameter, measure if the customer had to call back again to report the same issue; measure if the customer feels that the solution provided is complete; and measure mainly from the customer’s perspective. This will give the true sense of measurements that gives the organization a taste of reality.
Goodhart’s law is apt for this situation and it states: when a measure becomes a target, it ceases to be a good measure.
Applying the Principles/Learnings
With a good understanding of the current state of affairs backed by measurements that give a well-rounded reality, you will be in a fairly good position to decide to opt for overhaul or build/renovate over the existing state.
Applying the principle of start where you are
Consider an example of a website that needs to be modernized, and certain new analytics features and shopping cart are to be added.
Step 1
You would do an assessment of the different elements of the website, such as the content management system that runs the website, the data, the coding technology, and the flexibility to integrate with other tools that you might want to introduce.
While you do this, you will not stop with just the website; you might go into assessing the server it is hosted on, the performance throughput, and security.
At the end of this exercise, you will have a good handle on what you are dealing with. The next step is to turn this information into knowledge.
Step 2
Now it is time to create two categories: what is working and what isn’t. Remember the saying: if it ain’t broke, don’t fix it.
Your website is running on Wordpress, one of the best content management systems. The theme that you are running is old and buggy. The website is hosted on a server that is shared with other users, which is causing performance issues. The same aspect might feature on your security list too. When it comes to integrating shopping carts, there are plenty of plug-ins that offer ready integration.
Step 3
Put on the hat of a risk manager and start assessing the risks with the current system. How secure is Wordpress, given that plug-ins that work with it pose threats by giving backdoor entry to hackers and spammers. What are the risks associated with continuing with the same server?
Next up, what if you decide to move out of Wordpress to an alternate solution such as Joomla? What risks do you see or is it all bright and green? Will you be introducing more complexity into the content management system through Joomla? If Joomla is more secure, what would the trade-offs be between an easy to use and maintain software like Wordpress and complex and secure Joomla. Plus, there are risks of higher expenses by using Joomla due to its complexity.
Your risk assessment exercise would draw out all these questions, which gives a stable platform for decision making.
Step 4
As a website owner, I need to make a decision based on the information gathered in steps 1, 2, and 3. I don’t want the costs to go out of bounds. Pertaining to security, I am told by the risk manager there are ways to secure Wordpress websites. So reusing Wordpress would help me stay in the familiar zone for making website updates and the miniscule configuration changes that I make from time to time. I decide to stick with Wordpress.
The server is a concern, and I decide to move to AWS on a server that is exclusive to me. This takes care of the performance issues, and I am told that performance can be bettered on the fly by adding resources to the server dynamically.
In any case, going for a new website design was always going to happen. This will be done as a Wordpress theme.
This principle can be applied to products, services, processes, practices, team structure, or any other part of the organization and service value system.
It is extremely uncommon that products, services, or practices get overhauled without reusing what is already there. Even in transformation exercises, we reuse what is already there and start building on top of it.
Progress Iteratively with Feedback
The third principle relates directly to the Agile project management framework, where the work is broken down into individual chunks and is delivered in several iterations. DevOps being a superset of Agile builds on the principle of iterations that are defined by feedback.
The concept of Agile delivery, as the name goes, is built on the premise that the requirements change and a project undertaken with a traditional approach fails to create value, as the perception of value (requirements) changes by the time it is delivered. To avoid this gulf between value and delivery, project management transformed into delivering in several iterations, and each successive iteration would consider the changing requirements and the feedback received from the involved stakeholders.
Today, most IT projects are built in an Agile model and are highly successful because the projects are no longer projects—they revolve around products. Along with the DevOps methodology, product management has replaced project management.
Product management involves building improvements and maintaining the product. Improvements can come in multiple facets – be it changes to the product or service, or the underlying technological environment, processes, practices, and other elements that go into the making of a product or a service.
In the past, under the release management process, we used two techniques to deploy releases: big bang and phased approaches. In big bang, the release was deployed in a single iteration, while a phased approach considered multiple iterations and was aimed at studying the first iteration before proceeding to the next. However, the previous ITIL iteration was designed to work in a waterfall model where the entire requirements are first gathered, designed, built, implemented, and then maintained.
Importance of Feedback
As the saying goes: “feedback is the breakfast of champions.” If a product or a service must remain relevant in the market today, it needs to rely on customer feedback and must evolve dynamically.
The role of feedback must be upheld to the highest order and at every stage of the service delivered. Feedback should be requested and customers must be persuaded to provide feedback. Unless the service provider knows what the customer is thinking, they will never have an accurate understanding of the wants and needs, which translates to value being delivered, which further leads to continuation of the business relationship. So, the burden of identifying when, where, and how to obtain feedback from the customer solely rests on the service provider’s shoulders.
- 1.
Perception of the user of the product/service
- 2.
Perception of the customer of the product/service
- 3.
Upcoming requirements (demand)
- 4.
Understanding of the value chain deficiencies
- 5.
Information around customers’ relationships with their partners, suppliers, and service providers
Let’s say you are building a role-playing game using the Agile framework. In the first iteration, you construct the worlds where the players are going to fight for dominion. The customer (or could be delegates) get a feel for the environment and provide their feedback. Their feedback is considered for development in the next iteration along with designing of characters. At the end of iteration two, the customer says he is happy with the environment, but the characters are not coming out strong—they seem rather puny. In iteration three, you fix the characters. This is how the feedback is used in Agile projects to deliver what the customer wants, where the customer becomes a part of the journey rather than just acceptance at the end of it all.
Not all feedback is gold. You get chaff as well. So, it is important that the feedback is studied, and measured against the product you are designing. If the feedback makes sense, then go ahead and use it. Otherwise, let the customer know along with the rationale.
Feedback Feeding Iterations
Feedback feeding iteration
So, although iteration through Agile gives great flexibility, there are constraints that decide which piece of work gets accepted into an iteration; generally it is not recommended that new pieces of work get accepted into an iteration midway. Also, the team is going to pick only so much work that is proportional to the capacity available. Flexibility does not mean that the resources working on the project would endure night and day and stretch beyond their means to deliver more than they can manage.
In the game development example, typically at the end of a sprint a demo session is held for the customer. The customer is expected to participate and provide feedback. The feedback is immediately considered, analyzed, and the customer is asked to prioritize working on the feedback or other open items. Based on the customer’s directions on prioritization, the team works on the requirements in the next iteration. In essence, feedback fuels iterations and has a definite bearing on the development that happens in every iteration. So, it is essential that the service provider obtains feedback and reverts to the customer quickly to ensure the power of feedback in iteration is not lost.
While Agile is the way today and the way forward, it does not guarantee successes all the time. There are times when the service provider’s team may not succeed in delivering what they promised. The ability of the service provider to learn from mistakes and adapt at breakneck speed to the shortcomings will be definitive. It is about failing fast and learning from the experience. Only then will the quality of the outcome stand in shining armor.
Applying the Principles/Learnings
There are some techniques that the power of iterations and feedback brings to the table. One of the most used is the minimum viable product (MVP). In this, the product/service that you have conceived is built with the minimal possible configuration, and at times a subset of the final product/service. By investing a fraction of resources and efforts, the feedback received from the MVP is valuable for planning and execution of the final delivery.
Say you are building an online banking system. Any such system will have several functionalities like account statements, transfers, and standing instructions, among others. Instead of planning to build all the functionalities, you pick the most basic one: account statements. Develop it and then seek feedback from the customers. In fact, many organizations build an MVP product and invite end users to test it and give them their feedback. In this case, normal bank customers would use it as they would the existing online banking system and would provide their views. Based on the feedback, the product development can alter the course, make corrections, and move in a direction to meet what customers like the best.
Using iterations does not imply that the development happens at a quicker pace. Iterations and MVP also do not imply that incomplete or half-baked products are released into the market. A product can be broken down into several pieces of individual functionalities. In iterations, individual functionalities are identified to be developed in a time boxed period. Specifically, in MVP, the minimum set of functionalities required to characterize the product is included.
While we recommend working in iterations fed by feedback inputs, we should not lose sight of the end product that has been visualized. In other words, do not stray away from the final objective that you need to achieve. It is possible that working in iterations puts on blinders to the teams involved, which is not entirely wrong. Therefore, a customer representative, a project team member called the product owner is in place to keep tabs on the progress in relationship to the final product delivery.
There are many traps that the development team can fall into. One of the common traps is to develop once and develop right; a good amount of analysis goes in before the development can begin. At times, the analysis is so deep and in detail, the team in charge of it would not know where to stop their analysis and this concept is called analysis paralysis . To avoid this, every activity that the team undertakes needs to be time boxed, including the non–core-developmental efforts.
Collaborate and Promote Visibility
Collaboration, cooperation, and visibility are some of the key factors that drive Agile and DevOps methodologies. Especially in DevOps, without team members and teams collaborating, the thought of a single team coming together for the success of a product is unthinkable. Likewise, the work that is done must be transparent to the customer. The customer needs to be involved in day to day activities. Hence the need for the product owner to be a part of the development team. The days of service provider organization being a black box are over. Welcome to the world where customers and service providers collaborate, share, and become partners in creating value and success.
In the past, the concept of work was highly siloed, and we had people sitting in various teams that mastered a particular skill set. They were brought together for the execution of a project, and when the project concluded they went back to their caves. This is a matrix type of an organization. Even today many organizations swear by it, although they claim to run products in a DevOps methodology. Silos promote division and do not share knowledge. Containing information and knowledge will hinder the process of decision making, which impacts the entire organization.
Collaboration Partners
The days of a single service provider or complete in-house delivery are over. Multiple service providers must work together toward a single product delivery. For example, an application could have a company working on the development side of things, another organization supporting it, and yet another organization taking care of its interfaces. In such a scenario, there are bound to certain trade secrets that organizations would want to keep under wraps. However, doing so will only harm the customer because it results in poor delivery, delayed resolution, and increased rework. So, do the organizations shun their differences and their unique selling propositions for the betterment of the customer? The answer could be yes in certain situations. The situation could be when multiple service providers are working on the same piece of code or a shared technology. For example, the service provider working on support could benefit from the coding efforts of another service provider. But consider the bigger picture. Every company will have something to give and something to take. So, while they might end up opening their arms in sharing their skill sets, they might gain in a different area. After all, the other service providers were chosen because of their prowess in their respective areas.
Another collaboration opportunity is between the service provider and the customer. Customers are often kept outside the project, as they are expected only to provide requirements and accept delivery. At least this was how it used to be, but now things are changing with customers engaging at every level of the delivery including initiation and planning. While sharing between service providers is acceptable with a pinch of salt, when it comes to customers it is not that easy. Service providers do not naturally feel comfortable to invite the devil into their homes. They want to avoid questions that might pertain to capacity, ways of working, and the technologies employed. The customer could end up being a constraint rather than a buttress. Once again, these thoughts are archaic, because not only is the service provider’s mindset changing, the customer’s is too. Both work toward a common goal. If one fails, the other does too. The blame game does not end up with one or the other winning. It hurts them both.
The game of collaboration between a service provider and a customer must be played with specific rules. The customer becomes part of the team and is responsible for prioritizing the backlog items and clarifying the requirements. The development team and the customer come together daily to share updates, including those where they are stuck. This necessarily removes the surprise element from the equation. When the sprint ends, the demo that the product owner witnesses is not something like a movie premiere seen for the first time. They would have witnessed its growth from day 1, and the demo is an event where the delivery gets accepted and further feedback is given, which helps during the rest of the delivery process.
Two aspects are important: the service provider would want the customer to be open to providing feedback, and the customer should share their feedback openly without hesitation. If any of the feedback is bad or wrong, so be it; it will not take away the importance of being a customer. The development team will use what is important and discard the rest.
Means of Communication
The world is flat—not literally though! Customers, service providers, and other stakeholders sitting in a single location is as rare as hen’s teeth. DevOps calls for collaboration, and this is possible through frequent conversations and visibility of work. Being remote does not really bode well for collaboration, does it? Well, we have the technology to make up for it.
Tools such as MS Teams, Slack, and Google Meet feature high on the list and promote collaboration. Video calling, group chats, and boards for sharing information (like we do on Facebook) are some of the common features that enable information sharing with the familiarity of sitting across the table. The service provider and the customer must ensure such tools are made the platform for all communications and should move away from other forms. In the programs I manage, it is an unwritten rule that emails are used where formality is called for. Otherwise, all forms of communications—between peers, between the service team and the customer, between the service team and suppliers—are done through a collaboration tool. No emails are used unless approvals are sought for legal and auditing purposes.
For improvements to happen, the role of feedback is at the center. This communication takes place through customers who talk to the service providers, generally speaking. But what about the general users who don’t get a chance to voice their opinion and feedback? To get their feedback, surveys and studies are conducted to gather feedback. Based on the general perception and feedback, contact is made with users to get clarifications if needed, and improvement action undertaken.
Expanding Visibility
The various initiatives and activities that are taken up are not always known to the various layers in an organization. It stops at a certain management level and does not trickle down. This lack of visibility plagues most organizations today and is a leading hindrance factor to creating team spirit and invigorating loyalty. Leaders must spread the message of what the organization is doing, especially in product/service development and improvement initiatives. This information should percolate along with the reason for doing it in the first place and how it points to true north: the organization’s vision and mission goals. Most importantly, this is not a one-time effort. Such communications should be periodic, and the means matter too.
The next area where lack of visibility is common is in product/service development where the customers feel that after getting the requirements, the development team seems to have disappeared. Poor visibility on work progress will set in panic for the customer because without it, there is no guarantee that the product/service will be delivered on time and as per the specifications. The customer may feel that the work entrusted to the service provider is not important to the organization if they do not showcase the work on a regular basis. Therefore, it is important to keep communication going through continual visibility of work progress. Agile provides the best framework to meet the visibility and communication goals.
Think about the domino effect. Poor visibility will impact decision making as well. How can the decision makers provide direction if they have little clue as to how their ship is moving? Therefore, it is crucial for a product or service team that is working on a new product/service or improving one to ensure that open communication and proper visibility are the norm in their organization.
Applying the Principles/Learnings
The principle of collaboration and promoting visibility has multiple facets of learning. The most important of them all is visibility of work across an organization and visibility of work progress to customers and decision makers. Plaguing decision making is perhaps the biggest sin one can make in a corporate setting.
In the world of remote working, the emphasis is on collaboration for successful deliveries. First and foremost, this cannot be achieved if organizations opt for silos. The DevOps model is also a silo in a sense, but it is a silo that’s built around a product/service that provides value to a customer and this is how we must move forward. Keep the customer as the focus and integrate the teams around the customer.
Communication is another key aspect, which according to some studies makes up 65 to 75 percent of the overall project time. So, it is imperative that we get this right. Identify the right types of communication and communicate periodically to the right people. Seek feedback and use it wisely.
I say use it wisely because not all feedback is useful. We need to embrace the good ones and ditch the rest. A common misinterpretation is that collaboration equals consensus. This is not true. Consensus is one way of leading but is not the only way. There are times it does not work. A good leader should be able to choose one type of leadership over the other. For example, we pick an exercise to identify the right technology for a product that we are going to develop. Such a decision should be left to the experts, such as solution architects. Carrying out a consensus activity with the entire team is foolish.
There are different types of leadership. The popular ones are: leadership by example, where leaders set the pace; authoritarian leadership, where the leader makes decisions on his/her own judgement; leadership by coercion, where the leader moves the team toward his/her decision; and leadership by consensus or democracy, where the team’s opinions are given weight in making decisions. No one leadership is good or bad. We need to use different types of leadership in various scenarios. A good leader will know when to wield each of these styles.
Think and Work Holistically
No product or service stands alone to deliver value. It needs to be connected to other services to fulfill all objectives. Take any example that you could think of, IT or not. More and more we are realizing that all things are connected. If any of the leading countries takes a dip, economies and markets around the world follow the dip. For months and years to come, there will be all kinds of problems with supply, demand, and other trades. An everyday product like the Windows operating system cannot operate alone. Try disconnecting it from the Internet and the default applications. Do you find it useful without the Internet and other applications like Office, Chrome, and others? The idea is to think of a connected world and think holistically rather than in isolation. The Windows product development does not think with blinders on when they make changes to the product. They think about the impact it is going to have to the hardware it sits on and the seamless integration with software manufactured by other organizations, to say the least. Likewise, whenever you plan and execute activities surrounding products or services, do not think small, but cover your scope from one end of the spectrum to the other.
Do your suppliers know what changes you are bringing about to the services? Are your customers in alignment with the proposed design changes of the product that they use and integrate with their enterprise toolset? This is the direction that we need to undertake and come to terms with. We might hold all the cards and yet we might have to make decisions and lead in a consultative approach.
Applying the Principles/Learnings
A database such as a configuration management database (CMDB) identifies and documents the integrations and dependencies. Such a picture needs to be drawn for every product/service for us to be able to define the road map with the right set of stakeholders.
One way of defining products and services is through the number of integrations that they come built with. The more integrations, the more complexity, because making any changes would require visibility to all stakeholders and concurrence too. Even if the involved technology and coding could be simple and straightforward, the complexity grows with the integrations. This is one of the primary reasons for middleware products to be considered most complex, and every change requires plenty of forward thinking and planning.
To manage complex integrations or any number of integrations for that matter, collaboration and providing visibility (guiding principle #4) is the key. Without which, managing products or services would be next to a nightmare. Along with this, you need to have an agreed set of principles, processes, and practices so that everybody in the value chain talks the same language and points toward true north.
The more complexity, the more hands needed to manage it, and this could potentially end up with human-induced errors. No matter how brilliant we are, we err, and the panacea is automation. Any work that is repetitive and does not require human cognizance can be easily automated. There is more on this topic in guiding principle #7.
Keep it Simple and Practical
Minimalism is a theme that has been picking up pace since the Second World War. The concept is to do the minimal set of things necessary. In all areas of life such as arts, films, architecture, and even in technology, it has become the new norm. It follows the principle of doing the minimum number of things to achieve the objective as long as it is within the set bounds and is practical.
Keeping things on a leash to achieve the objectives in a minimal way is not alien to IT and IT management frameworks. The Lean transformation framework, which is strongly associated with Agile, guides optimizing the resources, people, efforts, and energy of your organization toward creating value for the customer.
The sixth guiding principle—keep it simple and practical—also embodies the principles of Lean, and the guidance is around keeping things minimalistic and pragmatic.
The outcome that we want to achieve is important. The outcome could be a derivative of a product, service, or a process. If the outcome can be achieved in fewer steps, and remain compliant to organizational and state policies, then this leads to achieving this guiding principle. This could be done either through removing wastes, automating activities (guiding principle #7), and/or doing away with bureaucracies.
We all know that keeping things simple and practical is the best way of achieving outcomes. Yet we falter in our efforts. The most common reason is to add controls at every step of the way, the management’s decision to micromanage activities and to mimic traditional practices.
What to Shelve, What to Keep
This is an interesting decision, isn’t it? When there are several process activities, several services with varying crosslines, the identification of the activities and services that are sheer waste is not visible like neon in the dark. A detailed analytical exercise must be undertaken, especially if the services and processes have overbearing dependencies, to identify the fault lines. We can carry out an activity similar to the business impact analysis, where every activity is analyzed from all possible angles to identify the impact to the business, to the service provider, and to other involved parties.
During design it is natural to add activities to review other activities in a bid to get the outcome right. The number of reviews or controls added make up the bulk. This is still not the problem, as it can be achieved (practically). The problem is when it goes beyond the call of reason—when the process activity reviews or controls become an overhead. Is there a way to make things flow smoothly with validations that can be done automatically? Yes, there are always ways, and the objective of an effective service management design is to find this way.
If a government wants to track cash transactions to ensure that all taxes are paid and all financial activities that are carried out are legal, then they need to set up a number of ‘control towers,’ processes and practices to monitor. What if they reduce the currency in the system and mandate online payments as the norm, even for trivial amounts? This would change the culture of a system, where people would automatically start transacting online, giving the government ample data to track illegal activities through technology.
BIA is an analysis methodology in ITIL V3 that helps in identifying critical IT services for the customer’s organization. This tool helps to spell out all possible impacts when services go down. For example, I am an author, and work full time writing books, articles, and blogs. If I were to lose Internet service, I would:
1. Not meet my writing targets
2. Not make money writing, which is a financial loss
3. Not meet my legal obligations, as I fail on my SLAs
4. Lose readership base, which puts me at a competitive disadvantage over my peers
In this example, I have broken down the impacts of losing a critical IT service. The first three items on the list are black and white, and they are often referred to as hard impacts. The last in the list, losing readership base, is a soft impact, as it is my perception of the impact and it cannot be quantified as I did with the others. To summarize, BIA deals with both the hard and soft impacts of the customer if he potentially loses IT services.
Enablers to Simplicity and Pragmatism
Staying with the same example, if the government wants 100 percent compliance then they must ensure that the system is enabled and free from conflicts. The online banking transfers must be free even for small amounts. Residents must be enabled with free Internet for carrying out banking activities. If these are in place, people will feel enabled to follow the rules that are in place and it is a win-win situation. Let us consider otherwise. If banks charge a certain miniscule percentage on every transaction, why would anybody want to transfer online if they could just do a cash transaction? Who would like to lose money just to keep the government informed of their financial activity? Without free Internet for banking activities, residents will have a way out to not be compliant.
The design that is put in place must look at the inputs, players, triggers, and outcomes holistically and find a solution that is conflict free. You do not want to introduce conflicts, which is a surefire way of ensuring failure.
Picking an IT service management example this time, change management is a classic example of governance playing ball with operations. There are approval processes to ensure changes can go into the system. If you are tasked with a design to expedite changes, you would propose a standard change management process whereby the changes are preapproved and can be carried out during the agreed terms and conditions. Having just a standard change management process is not sufficient; there are too many loopholes and conflicts. How do you ensure that it is compliant? Sure, an audit is one way, but it’s too reactive and the hit rate is too small. How about embedding the change management process with some automation, such as providing write/modify accesses to servers only when a change is registered with the server configuration item mapped to it, along with the change window. Only during the change window does the server allow its configuration to be changed. This is just the tip of an iceberg; a lot more can be conceived and achieved on the back of this idea to ensure that unauthorized changes do not get executed.
Applying the Principles/Learnings
The minimalistic lifestyle is popular for a reason. It gives people fewer things to worry about and increases the happiness quotient. How? It removes the complexities in life that otherwise would take considerable efforts to maintain. Apply the same principle to service management as well. Keep things simple and run proof of concepts to ensure it is practical.
The easiest way to achieve it is by doing a business impact analysis (as I stated—and not the traditional one). For every activity, find out how it is adding value, and whether it is taking you closer to the outcome or not. If it is either taking you away from the goal or standing still, then it is a waste that you can well afford to lose.
The days of bureaucracy are over. Approvals and oversight must find alternatives that involve automation and simplification. Remember that there is always a better and simpler way to achieve things; you just need to think consciously about finding it.
Optimize and Automate
The final guiding principle is around fine tuning and cranking the service management system to deliver in full force: optimize and automate. When this principle is applied, the product, service, or processes are already in place. It is a matter of making it more effective and efficient, and not about the functionality itself. Optimization deals with the effectiveness of removing wastes from the system and introducing activities or modifying existing ones toward bettering the outcome.
Automation, on the other hand, deals with efficiencies that are gained by using technology. Automation removes human intervention and ensures that the activities entrusted to it are completed successfully to a tee. Does it mean that humans are not involved in automation? Absolutely not. During execution, yes, the machines take over. However, the design and build of automation is done by people who identify the activities, define the inputs, design the work processes, and put in checks and balances to ensure that the automation can be relied upon. What we achieve through automation is speed (efficiency gain) and negation of human errors. While humans are prone to making errors, machines do as programmed—you program once and you can execute it a million times and get the same output every single time. However, there is a limitation on the kind of activities that can be automated. Only activities that are repetitive in nature—where the nature of inputs, work processes, and outputs are concerned—can be done by the machines. Other activities that require human cognizance cannot be automated, at least for now. There are artificial intelligence engines built by organizations that are trying to emulate human brains, though it is not conclusive that they can replace them completely.
These days all industries employ automation. It is necessary no matter how many human resources we have, because certain activities such as monitoring infrastructure or self-healing are better done by the machines than us; we are too slow and may lack the focus to keep an eye on things every second.
Optimization and automation
Optimization Practices
Any work processes that we can think of can be optimized. Think about the day to day processes and workflows that we deal with. Even after optimizing them, you can perhaps still find more opportunities to optimize. Example: When we go grocery shopping, we normally grab a shopping cart and walk the aisles picking up stuff that we want. In the end, we stand in line at the cashier’s desk where the cashier scans every single item, bags them, and then we pay. We put the bags back in the cart and take it to our cars and then to our homes. The first level of optimization can be what most grocery shops in the UK call smart shopping. A scanner is given to shoppers when we start walking through the aisles. As we pick up products, we scan them and bag the products directly. At the end, there is a kiosk where we scan the code from the scanner and make the payment ourselves. As the products are already bagged, we take the carts to our cars and then to our homes. The next level of optimization could be doing online shopping and paying for it. We select something called click and collect, which allows us to get to the grocery store at a certain time and all the products that we have paid for are bagged. Imagine the time saved; at least for me, this is about 2 hours saved per week. Online shopping along with delivery can be the next optimized level, where the driving time to the grocery store and back can be saved too. My point is that every process, workflow, and service can be optimized as many times as needed—if there is sufficient capital, zeal, and ideas.
Agree on the scope of optimization
Analyze the areas which are in scope
Measure the baseline for future comparison
Agree with stakeholders on the road map
Ensure all stakeholders are involved in the process and gather their inputs
Execute improvements in an iterative manner
Keep track of the metrics that define the optimization success
Compare metrics with baseline to obtain the level of optimization achieved
Automation Practices
As is the case of optimization, automation too can be applied to most of the areas. The only constraint could be the application of technology into the particular area. Say if you are dealing with a work process that involves interviewing others, then possibly automation would have a limited role. However, even there, automation can be used for initial screening of resumes and to run assessment exams for all candidates.
In the area of DevOps, we use automation heavily: including continuous integration, continuous delivery and deployment, automation/continuous testing, monitoring, self-healing, configuration management, and cloud management, among others.
Applying the Principles/Learnings
As indicated in Figure 6-4, it is a good practice to optimize first and then to automate, to ensure that the automation carried out does not exemplify and increase the complexity required for automation on nonoptimized work processes.
Measure everything. The only way you can decide whether an optimization has worked is through the metrics.
When it comes to technology, there will certainly be dependence on capital. The best way to counter it is to start with technologies that are already employed. Once they bear fruit, capital could flow easily.
All optimization and automation activities should be carried out in iterations, along with the feedback received from previous iterations (principle #3).
Knowledge Check
- 6-1.You are a service management consultant hired by a company to investigate the reasons for their customer’s dissatisfactions. Upon investigating, you find out that the customer’s needs are not met. To fix things, which of these principles would you start with?
- A.
Think and Work Holistically
- B.
Start Where You Are
- C.
Keep it Simple and Practical
- D.
Progress Iteratively with Feedback
- A.
- 6-2.You are an internal service management consultant hired by a project running in DevOps mode. There is a need to increase the operating margin of the project. You find out that the processes are complex and there are plenty of bureaucratic practices. Which guiding principle would be best suitable in this circumstance?
- A.
Optimize and Automate
- B.
Collaborate and Promote Visibility
- C.
Keep it Simple and Practical
- D.
Start Where You Are
- A.
- 6-3.You run a project that has multiple work streams. The product is common but the work areas are different. For example, one work stream is on enhancements, the other on reducing technical debt, and the third on support. Which of the guiding principles will be most beneficial?
- A.
Optimize and Automate
- B.
Keep it Simple and Practical
- C.
Progress Iteratively with Feedback
- D.
Collaborate and Promote Visibility
- A.
- 6-4.Your customer is not clear about what the final product should look like. He is wavering as the days go by. To not lose out on the competition, which guiding principle would serve in this situation?
- A.
Progress Iteratively with Feedback
- B.
Think and Work Holistically
- C.
Keep it Simple and Practical
- D.
Start Where You Are
- A.
- 6-5.Which of the following is the best definition of a guiding principle?
- A.
A recommendation that guides an organization to set up service management system
- B.
A guide to build products and services
- C.
A set of prescribed principles that provide direction to create value
- D.
A recommendation that guides an organization in all circumstances
- A.