In a previous blog I wrote about the need for a high performance Service Desk.   So what do we get in terms of business benefit? The value statement in IT terms is reduced re-work, less down time, better utilization of higher cost resources (knowledge management), increased stability, reliability, availability  and predictable levels of IT services. So the question is how do we effectively communicate the business benefit of our support efforts? The goal of course is to align our IT metrics to the business benefit and define that benefit with language the business can relate to and understand.     IT Metric Average speed of answer.  First Call Resolution.  Average Escalation Duration. Total # of incidents recorded by: Service, CI, Assignment team. IT Goal Less down time, lower abandon rate, quicker speed of answer. Less down time, lower abandon rate, greater use of knowledge bases.   Less down time, predefined escalation paths, greater cooper

It’s that time of year where the kids are heading back to school, the seasons are about to change and YESSS it’s time for FOOTBALL!!!! The other night I was watching the HBO series NFL Hard Knocks about the Los Angeles Rams training camp and it dawned on me how much a football organization is like an ITSM organization and how they can incorporate the 12 Agile principles into their game plans.  I know your saying, what?? But hear me out and let me explain: Our highest priority is to satisfy the customer. Ultimately this means to win the Super Bowl, but we have to win each week against a different opponent, with different circumstances at each game. Weather, crowds, injuries all have to be adapted to. We have to welcome changes, even late in the game.   Some changes might not be so welcome but we have to be agile and adapt to whatever circumstances arise during game day. This may mean dealing with something bad or some opportunity presented to you during the game.   (Respond to

The “Best of the Professor” blogs focus on one unique individual topic and will be followed by links to papers with more in depth information. DevOps initiatives are supported by three basic principles. In his book “ The Phoenix Project “, Gene Kim  leverages the Theory of Constraints and the knowledge learned in production environments to describe the underlying principles of the DevOps movement in three ways. These principals are referred to as The First Way, The Second Way and the Third Way.    In earlier papers from the “Best of the Professor” we discussed  the “First Way” and how this DevOps principle was all about the flow of work from Left to Right.  We then discussed the “Second Way which was all about the flow of work from right to left and how critical that is for measuring DevOps value.  In this iteration from “The Best of the Professor“, the focus will be on the last of these three DevOps Principles known as “The Third Way”. The Third Way – Continual Experimentati

I was recently asked if I had any insights into what roles (titles) are commonly used in companies and organizations to fulfill the BRM function.  This individual commented that the BRM function is one that they wholeheartedly support, but were finding that investing in a resource that is exclusively focused on that is something that companies either can’t afford (legitimately) or that they struggle to justify the cost for the position. Finding the suitable individual with the proper skill set to fulfill the Business Relationship Management (BRM) role can certainly be a challenge.  One thing to recognize is that the BRM job role function is dual fold.  This person represents first and foremost the customer.  They must be familiar with intimate details regarding customer needs, expectations and preferences.  On the other side the BRM also will liaise with the business to ensure that the service provider can fulfill those customer needs.  This is sometimes more of an art than a

The “Best of the Professor” blogs will focus on one unique individual topic and will be followed by links to papers with more in depth information.  DevOps initiatives are supported by three basic principles. In his book “ The Phoenix Project “, Gene Kim  leverages the Theory of Constraints and the knowledge learned in production environments to describe the underlying principles of the DevOps movement in three ways. These principals are referred to as The First Way, The Second Way and The Third Way.    This segment of “Best of the Professor ” will focus on “The Second Way”.   The Second Way                In an earlier “Best of the Professor” paper we discussed “The First Way” and how this DevOps principle was all about the flow of work from left to right.  “The Second Way in contrast is all about the flow of work from right to left.  It is reciprocal. How do we take all of the knowledge and learnings acquired and create feedback loops to the previous s

In every organization the one constant is change.  In operation all functions, processes, and related activities have been designed to deliver specific levels of service.  These services deliver defined and agreed levels of utility and warranty while delivering an overall value to the business.  The catch is this has to be done in an ever-changing environment where requirements, deliverables, and perceived value change over time.  Sometimes this change can be evolutionary or can take place at a very fast pace. This forms a conflict between maintaining the status quo and adapting to changes in the business and technological environments.  One of the key roles of service operation together with processes from the other stages of the life cycle is to deal with this tension between these ever-changing priorities. This struggle can be broken down into four general imbalances so that an IT organization can identify that they are experiencing an imbalance by leaning more tow

I often get asked where change evaluation takes place.  Isn’t it part of change management?  It is a separate process however it is driven by change management and is triggered by the receipt of a request for evaluation from Change Management. Inputs come from several processes including the SDP and SAC from Design Coordination, change proposal from SPM, RFCs, change records and detailed change documentation from Change Management.  It holds discussions with stakeholders through SLM and BRM, testing results from service validation and testing to ensure that its members have a full understanding of the impact of any issues identified and that the proper risk assessments can be carried out against the overall changes and in particular the predicted performance, intended effects, unintended effects and actual performance once the service change has been implemented. The purpose of change evaluation is to provide a uniform and structured means of determining the performance of a

The “Best of the Professor” blogs will focus on one unique individual topic and will be followed by links to papers with more in depth information.  DevOps initiatives are supported by three basic principles. In his book “ The Phoenix Project “, Gene Kim  leverages the Theory of Constraints and the knowledge learned in production environments to describe the underlying principles of the DevOps movement in three ways. These principals are referred to as The First Way, The Second Way and The Third Way.    This segment of “Best of the Professor” will focus on  “The First Way”. The First Way Workflow.   "The First Way" is all about workflow or the flow of work from left to right. Generally referring to that flow of work between the business and the customer.  Work that is flowing from development to test and then test to operation teams is really only work in process.  Work in process really does not equate to anything until value is realized on the other

The aim of Minimum Viable IT Service Management (MVITSM) is to put in place “just enough” process to meet your organizations, needs, goals and circumstances. Minimum Viable Product To understand this concept let’s take a look at some of the origins.  The term Minimum Viable Product (MVP) originated in software development.  If we research the definition we find that in product development, the MVP is a product which has just enough features to gather validated learning about the product and its continued development. Gathering insights from an MVP is often less expensive than using a product with more features which increase costs and risk in the case where the product fails, for example, due to incorrect assumptions. Minimum Viable Process In a recent workshop Donna Knapp from ITSM Academy indicated that the Minimum Viable Process is really a matter of looking at what are the minimum critical activities that need to be performed in a process.  Complex bureaucratic processes

Business Relationship Management (BRM) is the process and role that allows us, as a service provider, to establish a strategic and tactical relationship with our customers. This will be based on ensuring we understand the customer and the business outcomes they are trying to create and how and what services are engaged by the business to meet those defined goals and objectives. A key activity of the BRM process is to ensure that as business needs change over time, we as a service provider, are able to translate these needs into requirements through the use of a Service Level Requirements document (SLR) which then manifests itself into the portfolio in the form of defined services.  The BRM will assist the business in articulating these requirements and the value of these services that the business places on them. In this way the BRM process is executing one of its critical success factors, which is to safeguard that the customer’s expectations do not exceed what they are

If you are a strategist, manager or practitioner working in service management today you will probably be working on ways to improve lead time, cycle time and overall flow of work through the lifecycle of delivery.   Business demand requires speed and dynamic business requirements force us to look at ways to bust out of silos for cross functional integration.  Time to market, customer satisfaction and the need for secure robust systems are being optimized by many service providers as a result of successful DevOps initiatives.  When considering where and how to optimize the flow of work from ideal to end of life for a service , managers and IT staff frequently have a subjective view of what DevOps is all about and will often get into war room discussions around what certain terms mean.  Over the last year there have been many papers written by the ITSM Professor that clarify terms, concepts and methods current in the industry for service providers.   For clarification, and to ensur

So I assume everyone has heard the phrase “death by meetings”, that fear that you are going to be in a series of meetings and that no matter how hard everyone tries, you seem to come out of these meetings with the same to do list or a larger one.  I know your all shaking your head yes or saying “been there done that and have the tee shirt to prove it”.  We at ITSM Academy recently had our yearly strategic meetings and I want to say up front, Best Strategic Meetings in the eight years I have been with the organization. Now that it is not to say that we haven’t had great Strategic Meetings in the past, because we have.  And that is not to say that I wasn’t heading into these meetings with a bit of trepidation, as I think most of us do. I recently read an article called Managing Yourself, Learn to Love Networking*. It defined four strategies that you can engage to help you network with other people even if you really don't enjoy it.  I thought, why can’t I take these 4 approaches

As most of us are already aware, the business of IT has become even more critical in ensuring the overall success of an organization.  In today’s fast pace and fluid environments the statement that “every business decision triggers and IT event” is becoming increasingly true for those of us who operate in the world of ITSM. One of the most valuable tools that we can employ is our service catalog.  In a mature ITIL organization we can have two views of this catalog. The first being the Business/Customer catalog where we connect our customers/users to the standard IT services that we offer, deliver and support.  The second view is the Technical/Supporting service catalog, which when appropriately maintained is a very powerful tool that allows us to relate IT services to our supporting services and the underlying supporting infrastructure.  It is this second view that we will review here. Our service catalog provides us with a central source of information on all of the IT servi

We all know failure!  If a deployment for a critical service fails and negatively impacts business partners and consumers that can not be good.   One would have to consider why did this happen?  And even more critical is, why does it happen more than once? There are times when failure can be viewed as good. That of course is when we admit and then correct the reason or the cause of that failure.  Many organizations struggle with a culture that fosters hiding failure.   It is very difficult in this type of stringent culture to be effective and even more difficult to be efficient and innovative.   Not being able to admit or to discuss failure generally will lead to repeated and more disruptive failure.    What is a service provider supposed to do?  Do we fire individuals who drop the ball and fail?  If so, what size of failure would instigate such an action?  Do we restrict staff from elements or areas of the value stream so that their failure does not have the opportunity to impact u

The people factor and your ability to absorb change could and does make all the difference for IT service providers.  Most IT practitioners will agree that “change” requires some organizational change management.  Organizational Change Management (OCM) is the process of preparing, motivating and equipping people to meet new business challenges.  Conflict can be looked upon as good!  Embrace conflict don’t ignore or avoid it because it is necessary to listen to conflicting opinions that may not have been considered.  Learning to use different conflict modes helps to move forward and increase engagement that could make your organizational change a success. The   Thomas-Kilmann Conflict Mode Instrument   is a tool for helping people understand how different conflict-handling styles affect interpersonal and group dynamics and for empowering them to choose the appropriate style for any situation.  I was studying this in preparation   for an “Organizational Change Management” workshop an

In the introduction of her book The ITSM Process Design Guide, Donna Knapp writes “In today’s competitive business climate it’s not enough to do things right; Information Technology (IT) organizations have to do the right things right.”  Well what happens when we don’t? Remember New Coke?  Not every decision we make, every new design or redesign we engage in goes according to plan.  What happens when we fail?  One of the most important and most deeply entrenched reasons why established companies struggle to grow is fear of failure. In fact in a 2015 Boston Consulting Group survey, 31% of the respondents identified a risk adverse culture as a key obstacle to innovation. (1)  ITSM processes for strategy, design, transition, operation and CSI are all based on efficiency and effectiveness.  It’s about being in control of our IT environments and that we must do everything we can to prevent failures.  Now this may go against many of our strongly held beliefs but Pixar’s president, Ed Ca

The Service Portfolio represents the complete set of services that is offered and managed by a service provider.  It corresponds to the entire lifecycle of all services and is made up of three sections.  The first, the Service Pipeline (proposed or in development) denotes the future stance the organization is going to take in meeting customer requirements and aligning to the future business strategy. Next is the Service Catalog (live or available for deployment) which is what the service provider is currently delivering and maintaining to meet the organizations current and near future goals and objectives.  Finally we have the Retired Services, which have been deemed no longer valuable enough to sustain their continued delivery, but may need to be continued to be supported for some defined time to meet some regulatory or legal requirement. The Service Portfolio is an integral tool in helping us define perspective and position. It is a tool for our customers/business and ac

IT managers gather and distribute metrics that reflect their group’s performance on a regular and timely basis.  But outside of their immediate organizations do these metrics have any real meaning or impact? Do these measurements really define the value that IT is delivering?  Business executives shouldn’t have to work to see the positive impact of IT performance.  It should be made readily visible, in language they can grasp quickly and easily.  In many IT organizations there is a continued focus of their reporting towards the performance of the technology and not the value being delivered to the business.  This emphasis continues to create a gap between IT and the rest of the organization. (1) What metrics do you employ?  Service metrics, measuring the end to end performance of your services, based on your technology metrics.   Technology metrics, performance of your components and applications. Are they available when needed? Do you have the correct levels of capacity to meet d

Demand is increasing.  Dynamic or changing business requirements are a norm.  Business and customers must have quality services provisioned fast.  Ok … we get that.  Now let’s think about the service provider and what their condition or state is.  Some service providers are stuck in an organizational structure and management style that propagates an isolated us vs. them type of culture.  Others have legacy overburdened outdated systems.  Disparate and replicated tools between networking, storage and other functional teams including service desks generally create more havoc than business value.  Many efforts including data center transformation, new sourcing models, cloud computing and more have helped to some extent.  Even after these very costly initiatives many service providers experience a resistance to change and find they are working within a very rigid environment. Rigid structures, rigid process or rigid anything will not enable a service provider for success.  Some organi

The question about how to manage virtualization and configuration items pertaining to the Cloud continues to challenge service management practitioners and managers who are trying to strategize and architect a working solution to provision business services.  Some would say the idea of the CMDB (Configuration Management Database) is dead because we use the infamous “Cloud”. Let’s start with a refresher about the structure and purpose of a CMDB and system and then move into how that relates to the management of virtual Configuration Items or Cloud services. Configuration Management System The key to a CMDB, or the sets of data that comprise your broader Configuration Management System (CMS), is “Relationships”.  When provisioning a service, the service provider must be able to manage and control all of the items necessary to produce “Value” to the consumer.  All elements in the end to end service that need to be managed and controlled are referred to as a Configuration Item