By Donna Knapp and Jeff Jensen Let’s answer the obvious question first. What is a service management office (SMO)? ITIL® describes an SMO as a “group or department that functions as a center of excellence for service management, ensuring continual development and the consistent application of management practices across an organization.” So given that service management is a “set of specialized organizational capabilities for enabling value for customers in the form of services”, it is the SMO that helps the organization to develop these capabilities. A SMO can be formalized and have significant authority to drive service management in the organization, or it can be less-formal teams focused on continual development of the organization’s management practices. In some organizations, the SMO provides a management structure for the various practice/process owners and managers to report into. This also allows for a roll-up of enterprise metrics and reporting, and in some cases provides...

By Donna Knapp We sometimes hear from organizations that they are “good with ITIL® v3”. We’d like to encourage an alternative point of view. AXELOS launched ITIL 4 in February 2019 and since then, the world has changed dramatically. COVID-19 has taught us all that the need for organizations to undergo a digital transformation is paramount to survival, as is the need to understand and leverage emerging disruptive technologies. But let’s be honest, that’s been the case long before a global pandemic changed our landscape. The gap between those able to benefit from the digital age and those who are not has been widening since the 1990s. What COVID-19 has done is accelerate the digital transformation processes in organizations. According  to a McKinsey survey of executives, “companies have accelerated the digitization of their customer and supply-chain interactions and of their internal operations by three to four years”. Let’s accept the reality of that… things have sped up dramatical...

As the pace of technological innovation increases and digital disruption becomes the norm, the need to adapt and accelerate IT service management (ITSM) processes is more critical than ever. It’s no longer a debate about whether ITSM and DevOps should interface; ITSM professionals must now understand how the practices they use to co-create value can either support or undermine the flow of work and pervasive automation in a DevOps environment. It’s easy to understand why ITSM professionals are skeptical about DevOps. ITSM performance metrics and service level agreements (SLAs) often revolve around the IT organization’s ability to mitigate risks, minimize impact, and “guarantee” availability. While these measures have value, sacrificing speed, agility, and innovation can negatively impact the business. Even with the evolution to ITIL 4 , the what and why of ITSM haven’t changed. A customer-focused culture in which everyone understands how they contribute to the co...

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 map...

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...

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 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,...

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 or...

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 b...

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 fr...