Skip to main content

Posts

Demings 7 Deadly Quality Diseases

Often, when we talk about implementing IT Service Management we refer to one of the Founding Fathers of the Quality Management movement, Dr. W. Edwards Deming. Most people focus on the Deming Cycle of Plan-Do-Check-Act. Perhaps lesser known but just as important is the fact that Dr. Deming spoke of the changes needed within an organization’s culture to make the Deming Cycle work to its greatest effectiveness. Dr. Deming wrote and spoke of Seven Deadly Diseases that infect an organization’s culture and prohibit it from truly succeeding in achieving quality for the customer. Lack of constancy of purpose: You must remain focused on doing the right things because they are the right things to do for your customer and to achieve quality. ITSM is not a fad it is a way of behaving. Emphasis on short-term profits: Cutting costs can bring short-term profits and are easy to achieve. But cutting costs can only go on for so long, before you have cut to the bone and have nothing left to cut.

Digital Ingenuity

It is official.  All service providers are or soon will be going through some form of digital transformation. As you begin to transform be sure to take into consideration the Values of DevOps, Agile Service Management, Lean and ITSM.  They each have beneficial results and each dovetail together to ensure that the service provider can move fast, change on a dime to meet dynamic requirements, and also be able to deploy into an antifragile stable environment.  Business transformation can appear to be daunting.  Sometimes it is somewhat of a labyrinth, involving a constant need for collaboration and engagement between customers, business partners and Information Technology functions. All are required for proper strategic vision and operational execution. That is likely not news to you.  We KNOW that is required and yet there are many service providers that still today need to bridge the gap between Business, Development and Operational teams.  When setting expectations for a Digital tran

WARNING! The Titanic is Sinking! Service Providers… Stay CALM & Share!

(DevOps VALUES revisited) We used to talk about the rate of demand for change and how that was forcing service providers to change course.  Service Providers are the current Titanic.  Many believe that they are invincible.  The iceberg today is multifaceted. It is not only speed and quality but the challenge of dynamic business requirements, complexity of new services and rigid silo’s. These all add to the depth and potential threat of this new iceberg.  To avoid sinking, Service Providers must consider the DevOps values and stay C A L M and Share!  There are five DevOps values that will help us avoid the iceberg.  These values include: C - Culture A rigid, “We have always done it this way” culture will break your capability to steer the ship in the direction that you must go to avoid the iceberg.  A Cultural shift will steer your ship in the right direction.  Those shifts include Shift Left Culture – Getting representation for change, compliance, security and operations

The Top Benefits of ITIL

Stronger alignment between IT and the business: Historically IT has not been a participant in helping to create business strategies, it was normally in the role of supporting them. Recently, with the speed of innovation impacting businesses position in the marketplace, IT has been playing a greater role in helping to develop that business strategy. The ITIL framework enables IT to act as a service provider and become a core and more strategic part of the business. Pre-defined processes and best practices from the ITIL framework enable businesses to react quickly to today's rapidly changing technology landscape, focus on innovation and ultimately keep customers satisfied. Improved service delivery and customer satisfaction: Event, incident and problem management processes included within the ITIL framework enable businesses to review performance, perform root cause analysis, resolve issues and through problem management, prevent future incidents from occurring and allows us

The ITIL Practitioner – Relevant and Required Today

What are the challenges that every CIO, CEO or service provider faces? EVERY Service provider today must move BIGGER, BETTER, MORE… FASTER than ever before and do it at the LOWEST COST possible! We used to speak about the rate of change and yes that is still increasing. The rate of change is only one of many aspects that present challenges that must be considered, others include: Dynamic Business Requirements - We do not even get started with the deployment and the requirements are changing. This can no longer be an excuse for overruns. The service provider must expect this and have the people, process and technology in place to respond quickly to these expected changes. Transformational Change – A transformational change is designed to be organization-wide and is enacted over a period. Transformational change and this culture shift will result from a change in the underlying strategy and processes. This includes strategic transformations for DevOps initiatives, Agile or the

Digital Transformation - What Is It?

Customers are empowered and connected. To stay relevant many organizations are asking “how can we evolve with the digital era?” To lead the change, we must understand it.  It is likely that in the next one to five years your organization will focus on digital transformation in three or more of these areas: Artificial Intelligence / Machine Learning Defined as the study of " intelligent agents " on any device that perceives or learns its environment and takes actions toward success at a specified goal. The Internet of Things (IoT) The IoT refers to the connection of devices (other than typical computers and smartphones) to the Internet. Today things like cars, kitchen appliances, and even heart monitors can all be connected through the IoT. Who would have known that we might need to add items such as drones to an asset registery and learn how to manage them? And as the IoT grows in the next few years, more devices are and will continue to join that list. (Editor'

Why I Love Teaching ITIL Foundation

I have been instructing ITIL classes now for almost ten years and wow have things changed in our industry over those ten years.  Many new tools, concepts and practices have been introduced along the way.  Yet somehow, I still get excited about teaching ITIL Foundation even after presenting it a few hundred times.  The material has changed somewhat, my presentation techniques have gotten better and my jokes and stories still seem to be timeless, kind of like me (Lol). I guess part of what is amazing to me, is the fact that there are still many people out there in the world of ITSM that have not been formally introduced to ITIL best practices but yet participate in them.  So I take very seriously the responsibility to not only educate the learners, but hopefully to inspire and excite them to really want to utilize these practices in their everyday activities;  to see the value in these practices and not view them as just something else they must do. Given the number of times that I

ITIL – Back to Basics for Agile and DevOps

ITIL advocates that IT services are aligned to the needs of the business and support its core processes. It provides guidance to organizations and individuals on how to use IT Service Management (ITSM) ­­­as a tool to facilitate business change, transformation and growth. Some are believing that ITIL has run its course.  In truth I believe the opposite is true.   In the past, and still today, many organizations believe that Best Practice and ITSM processes are focused on the Service Operation Lifecycle.   Implementation, process design, and ITSM tools have had a very heavy focus on processes like Incident, Problem, Change and Configuration Management. Few have yet to recognize or have not seen the value in the guidance for Service Strategy and Service Design processes and roles.   How did these get overlooked? In the last three or so years I have seen a bit more buzz about “Business Relationship Management”.   Less so for “Demand” and “Strategy Management” for IT Services. Few are

ITIL Practitioner - Components of a Service

At the core of ITSM is the idea of delivering services to customers, how these services will be engaged to deliver some form of value to the customer and the customer’s organization, and the value captured by the service provider.  For this to be accomplished we must first understand the key elements of an IT service and how, as a service provider, we deliver the correct set of services effectively and efficiently.   “A service is a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks”.  This allows the customer to create the desired business outcome without having to invest in specialized tools or skills.  By linking activities performed by the service provider to the desired business outcomes the provider can be seen as contributing value, not just as a cost to the business. The value of a service is derived from what it enables someone to accomplish or what outcomes it enables them to

Continual Service Improvement (CSI) and Survival

The systems, the processes, and the culture that worked for IT service providers 20 years ago will not work in today’s environment.  No big news here!  Most IT support staff will agree. The truth is that the same could be said for systems or methods that service providers used five years ago or even last year.  The dynamic and rapid change of business requirements demands that a service provider be dynamic and continuously adapt to evolving business needs and outcomes. When you get into your car and turn the key or push the start button, most would expect that the car is going to start.  You might also expect that it has wheels, an engine, and all the elements necessary to drive this car, right?   This is the same expectation that a business operation expects.  When a service is provided the business expects that service is going to have all the working elements to ensure that it does what they need. The customer expects that the service is available and secure for day to day oper

Measuring Goals for DevOps Test Succcess

Each organization will have to define what their quality goals are for integrated testing based on the business and customer requirements for speed and outcomes.  The fact is that these goals must be quantified or in other words measurable. If you are not measuring your testing activities in alignment with the strategic goals then success becomes subjective and it will be very difficult to show value for your effort. Some examples of measurements might be in the form of Run-To-Plan and Pass-To-Plan. Run-To-Plan (RTP) is the number of the total planned tests that have completed and typical goals are to have 95% RTP Pass-TopPlan is the number of tests that have passed and a typical goal for this metric is to have a 90% PTP The criteria for determining when testing is complete is agreed by all stakeholders.   It will be impossible to have all stakeholders on the sprint team, but certainly input and validation from key stakeholders will have to be included before acceptanc

Changing Culture to Become Agile Based

 Success in modern technical endeavors absolutely requires multiple perspectives and expertise to collaborate. (1)  When I ask managers attending my classes if their organizations practice ‘agile’ they hesitate and say something like we kind of do but not in all areas of the organization. Further questioning usually uncovers that most of this agility starts and ends with the software development teams. When asked if these practices have been introduced to the business units there is a long uncomfortable pause, and then I hear 'we don’t usually talk to those groups'. Over the last couple of decades, a new set of major management philosophies have been developed and are now being adopted to ITSM. These new ways of thinking enabled manufacturing, software development and others to analytically realize both disciplined execution and continuous innovation, something that was thought to be mutually exclusive and impossible to accomplish with traditional management methods. Over

Agile Change Management

I always hear people say ‘Don’t like the weather, wait an hour it will change’.  The one constant in our lives is change. In business today, customers, users and stakeholders all have the expectation that as IT service providers we can and should be able to handle change requests at an ever-increasing pace.  Yet they still have the expectation that an appropriate response to all requests for change entails a considered approach to assessment of risk and business continuity, change impact, resource requirements, change authorization and especially to the realizable business benefit. For us to be able to do change management in an Agile environment, does that mean we must give up those requirements for speed and agility? The purpose of Change Management is to control the life cycle of all changes enabling beneficial changes to be made.  I was once told by a very wise thought leader ‘Being agile is a state of mind.  It’s more perspective than prescription.’  Why can’t we have a

Service Offerings and Agreements

When we think about what services we are going to offer we immediately think of the Service Catalog.  We must also consider what agreements go along with the delivery of those services.  What levels of utility and warranty are going to be expected over the life of our services?   What about services that will be supplied by external service providers; who is going to manage those?  Let’s take a look at which ITSM processes we will need to engage to ensure that we are able to strategize, design, deliver and maintain services that will meet our customers’ needs over the lifetime of the services. In Service Offerings and Agreements (SOA), we look at Service Portfolio Management (SPM), Financial Management (FM), Demand Management (DM) and Business Relationship Management (BRM).  These are all processes within the Strategy stage of the Lifecycle.  We also explore Service Catalog Management (SCM), Service Level Management (SLM) and Supplier Management (SM) processes within the Design st

CSI and the Communication Plan

Timely and effective communication forms a critical part of any service improvement project. To transform an organization and move people and process from just thinking about Continual Service Improvement (CSI) activities to actually allotting time to be able to performing CSI activities, it is critical that all stakeholders are informed of all changes to the processes, activities, roles and responsibilities. The goal of the communications plan is to build and maintain awareness, understanding, enthusiasm and support among all stakeholders for the CSI initiative. A communication plan is much more than just sending out one notification on what is about to happen and should be a series of notifications and meetings to keep people engaged, informed and passionate while incorporating the ability to deal with responses and feedback from the targeted audience. First, we must design how we will communicate and then we must define what and to whom we will communicate. The pla

The State of ITSM: One Company’s Assessment!

Here is an article I thought you might find interesting.  It was first published in itSMF USA's Source EJournal, April 2017.   The State of ITSM: One Company’s Assessment! By Keith D. Sutherland and Lawrence J. “Butch” Sheets Educators and consultants operating in the formal practice of IT service management (ITSM) have largely been doing so since the mid-90s. Even though the best, codified practices of the IT service management framework, ITIL®, is now just over 30 years old, there remains a large number of organizations still in initial adoption of ITIL.  And of those service providers with longer histories of using ITIL, many still have a significant need to increase maturity, or more fully implement their ITIL practice. The need in these companies for structured education, assessments, and roadmaps still abounds, even while multiple approaches for these practices are available for each. Beyond ITIL (and in many cases, alongside), are the many other evolving a

Agile Best Practices in the Incident/Problem/Change Cycle of ITIL

ITIL is not in conflict with DevOps, ITIL supports DevOps with a solid foundation by providing an up to date an accurate configuration of our IT infrastructure. This, in turn, supports the ability to accurately carry out the detection of issues and underlying problems and deliver collaborative, permanent solutions to operational deviations. Further, it engages the Second Way by “shortening and amplifying the feedback loop” to development.  Historically most IT organizations structure their incident, problem and change processes within a very confined view, typically utilizing these processes from an operational perspective and only marginally engaging them at the design stage of the lifecycle.   ITIL should and can be adapted to DevOps practices to proactively define when incidents and problems arise while still in the design phase of the lifecycle.  This means engaging both software development and infrastructure design in a way that allows us to capture these deviations proactivel

Process Practitioner Examples – Roles and Responsibilities Revisited

Assigning clearly defined roles and responsibilities are critical to the success of every process. These roles need to be defined early and reviewed periodically to ensure proper training, communication and education.  A process without clearly defined roles will fail at some level.   There is a very clear distinction in the activities or the roles that are played out by individuals in your organization.  You should determine and communicate who is accountable and who is responsible for the process activities.  A role is like a hat.  One individual could wear two or more hats.  Watch out for titles.  You might have a title such as Service Transition Manager.  What role(s) would this individual fulfill? It all depends on WHO is best suited for the role or task that needs to be performed when it comes to assigning roles. The Service Transition Manager could be accountable or OWN the “Release and Deployment” process but might also be a practitioner and be responsible to perform task

Agile Service Manager

What is an Agile Service Manager? The following is a definition from the University of California Santa Cruz for an IT Service Manager. “The Service Manager has overall accountability for defining the service, ensuring services meet the business need and are delivered in accordance with agreed business requirements and managing the  service lifecycle  – often in conjunction with a  Service Team ” . I also looked up some jobs offerings from around the globe that were described as Agile Service Management and took some pieces from them.  Here are a couple of examples: Has responsibility for defining and creating the global service, developing the reliability and performance of the services in line with the business requirements, and managing the overall service lifecycle within an agile environment. This includes stability, performance, capability, risk acceptance and analysis of the services. Developing a deep understanding of what is important to the service, you will be pri