In the past, the idea was to build in the non-functional requirements of service to the best of our ability based on experience or best guess. Sometimes the general thought was, “We will worry about any residual work for availability, capacity, and reliability after the product or service is deployed”. This focus ensured that the product was fit for purpose, but did not ensure that the product was fit for use, that it was reliable. This approach is very costly to the operations of the service and negative consumer impact impedes opportunities for market share.  This type of focus also creates silos between Dev and Ops and Ops become firefighters.  The costs for operations are not sustainable! In addition to loss of revenues, staff morale begins to slip.  So, reliability is really the key to success. Think about your cell phone. A heavy focus on functional requirements would mean that you can make phone calls. You can text, you can  take photos, you can use your maps and a variety of

Learn more about new ways to do work! Explore DevOps, ITIL, SRE, XLA’s and more ! Silos are not uncommon, but when you silo the service desk from second and third-tier support staff, you likely have a recipe for pain. An ineffective incident response system within the organization is painful and disrupts the entire organization, especially the customers. We must shift the way we think and work to stabilize and improve the situation. One organization felt that they had a grip on service desk and incident management, but they blamed the subject matter experts for breaches to Service Level Agreements . The blame game is always detrimental. Their process consisted of the service desk agents receiving the incident, performing the initial triage, and then forwarding it to the subject matter expert based on how they categorized the incident. Sound familiar? Sometimes we pass tickets to and fro, get everybody and their brother involved, wait on email responses, and create chaos that frustrat

Originally posted on owlpoint.com , August 11, 2020, and written by Mark Blanke , CEO of Owlpoint, and Chairman of The CIO Initiative One of the aspects of ITIL 4 that has impressed me the most is the integration and reference to so many other best practices and frameworks. One such reference is to Site Reliability Engineering aka SRE . SRE was originally developed by Google in the mid 2000s as a way of operating and administering productions system with a software development mindset. One of Google’s key drivers in building out SRE was to help bring developers and operations people together. Sounds like DevOps , right? In reality, they come from the same mindset, but there are key differences. Google only recently started sharing the SRE concepts. It was their secret sauce and a way to be far more effective in operating their systems and maintaining a highly reliable environment. However, over time, they realized that it would be better for them to share their methods, so the

ALL CALL SREs REQUIRED!  Let’s take a walk down to the ocean and while you consider the opportunity, benefits, and $$$, think about dipping your toe in. Let’s explore Reliability, Site Reliability, and the Site Reliability Engineer .  No doubt the world is evolving. People are evolving and tech is evolving. Business and customer requirements are evolving. The evolution of systems requires the evolution of engineers. Nature and pandemics put undue stress on our resources! In comes the Certified Site Reliability Engineer .  "Urgent, Urgent, Urgent… All hands on deck!",  is a call that practitioners, managers, and organizations do not want to hear and recognize must stop! Reliability – At a minimum, we recognize that the delivery of service is not dependent solely on the quality of the product itself and the goal is not that the products or service merely be deployed. A service must be operated and sustained over a period. How long? For the life of the service.

There are three core frameworks that can help us to shift the way we think, do work, and ultimately shape the behaviors and values that are the heartbeat of our organizations - CULTURE! Each of these models can be used to identify, analyze, and move an organization to new heights, new ways of collaborating and increasing speed and value for service consumers. Models for learning how to "Shift the Culture!” Erickson Model – Identifies the stages of psychosocial development  The Erickson Model helps as a starting point for “Where are we now?”. Westrum Model – Focus here is on the organizational types :  - Pathological  - Bureaucratic  - Generative  The Westrum Model helps providers get detail on the behaviors within their organization and teams.  Laloux’s Culture Model – Frederic Laloux’s model provides a clear picture of how culture may evolve in an organization. Laloux expands the concepts of the two previous models. The model comes f

The risk is below the water and we are headed right towards it. Organizational Transformations, Business Transformations and IT Transformations are all at their very core really CULTURE Transformations!  Ok friends, I’ve loaded this one up. For a deeper dive into some of the topics addressed in this blog, be sure to click on the embedded­­ links provided. Culture must be considered to Drive Stakeholder Value - This is POWERFUL! Think about how a culture shift  enables the following: Mapping the customer journey with all touchpoints and interactions. You can potentially map the customer journey and map the stakeholder’s roles and responsibilities brilliantly, but what about the cultural shift to enable these stakeholders? Without it we will likely fall short of our goals. If we have any hope of converting demand into value via IT-enabled services – culture is key!  Properly designing XLAs , SLAs and meaningful measurement models.  Without culture, the risk is high t

Considering an Instructor-Led Virtual Classroom for your next class?  Online Instructor-Led Virtual Classrooms allow YOU the learner to immerse in material that is presented in a fun, practical manner. Try it! I promise you won’t be disappointed.  Virtual Classrooms are available for Certification and Non-Certification courses including: Agile Service Management   DevOps ITIL CX and XLA Training Value Stream Mapping (VSM) This is NOT a Webinar! This is NOT an e-learning self-paced computerized course.  You are not on your own!  Instructor-Led Virtual Classrooms Allow YOU to :  Learn online with a live experienced instructor. Interact in group discussions and activities with others in the class. Engage your instructor with ongoing Q and A throughout. Listen to or share real-world examples. Participate in analyzing sample exam questions with the instructor.  Collaborate with chat, open mic, polls, and other interactive tools – VOIP or phone!  Learn f

Survival - For a service provider to survive in today’s fast-paced delivery environment they will likely need to move away from old ways of doing things. We hear things like; "Terms matter", "Shift your thinking!" or "Shift the focus!" and "CHANGE the CULTURE!".  It is becoming more evident than ever that our organizational structure including silos could be an impediment. Structure – An organization’s structure impacts how work gets done. Structure influences the actual product and service architecture. Some organizational structures even have siloed within silos.  Structure matters. Silos can fracture the velocity of delivery and the quality of what is delivered. We can transcend silos!  ITIL 4 Foundation or the new DevOps Leader  certification classes are a good place to start learning new and better ways for the conversion of demand to value for service providers. Considerations for Transcending Silos Measurement – High performin

Originally published on DevOps.com , written by Jayne Groll , CEO of DevOps Institute For over a decade, ITIL has been the leading ITSM framework adopted by enterprises across the globe. So, what is driving a rapidly increasing interest in Site Reliability Engineering (SRE) as a service management alternative? In its own words, Google refers to SRE as its approach to service management: “The SRE team is responsible for the availability, latency, performance, efficiency, change management, monitoring, emergency response and capacity planning.” In traditional ITSM terms, the role of the SRE is responsible for service level, change, availability, event, incident, problem, capacity, performance, infrastructure and platform management. While the operational practice areas may be similar, there are significant differences in how the practices are approached. ITIL4 Framework Compared to SRE Released in 2019, the newest update to ITIL4 remains a complex governance model with four dimensi

I find that there are many people that do not understand WHAT a Certified Process Design Engineer (CPDE) really is (be sure to scroll down on the page and then download the free whitepaper for surprising details). The CPDE role is likely much broader and deeper than you might think! Time and Money?! Yes, but not at the expense of quality and stability!  The role of a Certified Process Design Engineer is a critical skill set for all IT service  providers. There are many frameworks and standards that  define practices and methods for achieving success; ITIL 4 , Agile , Lean , DevOps , COBIT, ISO, and Site Reliability Engineering (SRE) are only a few. My point is that while each describes processes and controls (what to do), they don’t provide clear, step-by-step methods and techniques for designing, reengineering and improving processes (how to do it).  A Certified Process Design Engineer equips managers and staff at all levels to lead the organization to do t

For high performing IT providers, the sands are shifting. If you are getting certified in ITIL 4 , DevOps , or Agile Service Management you hear that we have to “Think BIG and ACT small!”. Minimum Viable Products and Minimum Viable Processes (MVP) are on the move. Historically, IT organizations delivered products and processes into production with huge batch runs or the big bang approach. This method is fraught with issues, escalations, and constant firefighting. These large releases are tightly managed, governed from the highest levels, and require participation from all parts of the organization. The days of large batch runs that take months to create and war rooms staffed 24×7 for weeks before and after the release, have given way to small incremental deployments. In comes Minimum Viable Products/Processes:  High performing organizations know that deployments that deliver value to the consumer fast are required. The idea is not to stage, stage, stage until you have a huge batch

The Service Value System (SVS) and Service Value Chain as indicated in ITIL 4 Best Practices give you the big picture macro view that should be the start of every DevOps Pipeline . Without it, you could get swept into the undercurrent and potentially focus too much effort or misdirect resources towards the technical and automation aspects of continuous integration and continuous delivery (CI/CD).  Components of the SVS include:  The ITIL4 Guiding Principles, Governance, The Service Value Chain, Practices, and Continual Improvement. A Service Value Chain and Value Stream Mapping (VSM) exercise provides all stakeholders with a high-level view of the end-to-end steps required for your DevOps Pipeline. Applying the concept of “Systems Thinking” to the overall CI/CD Pipeline is critical but without including the information/data and flow of work we truly miss the mark. This is where Lean  principles and VSM are helpful.  Notice in the above image from our Value Stream

Part of ITIL 4 ’s value proposition is that it embraces newer ways of working, such as Agile, Lean and DevOps. I was recently asked whether there was a compelling argument for individuals to go to ITIL for information about these approaches, vs. going to ‘the source’. Here’s my answer and I’d love to hear yours. 3) What source? Yes. There is a massive amount of information available about these topics. There are many ‘definitive’ sources of knowledge. For lifelong learners such as myself, these sources are a joy. They can also be overwhelming and at times a challenge to apply. A search for information about Lean, for example, may take you down a manufacturing route which then requires translation. Looking to learn more about Agile? Which method? Scrum, SAFe, extreme programming … you get the point. 2) The source is evolving. As an example, DevOps practitioners often pride themselves in the fact that there is no definitive body of knowledge; rather, there is an evolving col

Keeping it Simple is one step towards creating a world where people get up in the morning and are inspired to go to work and love to do the work that they do. The more complex something is, the more there are ways for it to go wrong. We as an industry of service providers must become educated and stop the insanity! Getting the education and the certification is a wonderful first step but once qualified we must adapt those learnings to make it simple and “Keep IT Simple”  “Keep it Simple”, one of the seven ITIL 4 Guiding Principles is a topic we have written about many times over the years.  It is anything but simple. We must acknowledge that IT services are comprised of many complex systems and if there is a way to make them even more complex IT Professionals in general seem to have that idea down to an ART.  So; How did we get that way. Business requirements are dynamic and are consistently evolving even as you read this line. Over a period of years and in ma

Communication has always been a key principle for service providers and this ITIL 4 Guiding Principle “Collaborate and Promote visibility” takes us to new heights. Encouraging staff and giving stakeholders the opportunity to develop this skill, will amalgamate teams in ways we never thought possible.  This guiding principle also represents the influence of Agile, DevOps, and LEAN on ITSM and best practices. A pillar of Agile is to be “transparent” and LEAN encourages making work visible in order to remove waste and increase flow. Both collaboration and being transparent are a key focus of DevOps integrated teams in order to ensure a continuous delivery pipeline. To understand this further let’s look at the two elements of this ITIL4 Guiding Principles. Collaborate  When we communicate, we are notifying or telling something to a person or a group. Collaboration is quite different and occurs when a group of people work together. The key word here is “together”. They wor

Adopting the ITIL seven “Guiding Principles” for service providers could be the best way to establish a healthy organizational culture. All “Guiding Principles” are powerful but today are some thoughts on just one and that is “FOCUS ON VALUE”.    ITIL 4 best practice guidance says to focus on value.  Getting level set on what VALUE is for your business partners, customers and consumers is critical to every strategic, tactical, and operational action! To understand this better let’s start with the official definition of a service. “A service is a means of enabling value co-creation by facilitating OUTCOMES that customers want to achieve without the customer having to manage specific costs and risks". If this is so, then there is a direct correlation between VALUE and OUTCOMES. When it comes to defining “VALUE” we must get OUT of “IT”.  An “OUTCOME” is what we deliver. It is not the activities within the value delivery stream but rather the RESULTS of all people,