Skip to main content

Posts

Showing posts with the label IT Service Management

Nine Guiding Principles for ITSM or… for Everyday Life

ITIL Practitioner focuses on nine guiding service management principles that distill the core message to facilitate improvement and success at all levels. The principles not only guide providers who want to adopt a good approach for successful products and services but can also be applied to ensure our day to day success. Yes, that’s right! These principles could be applied to buying a car, ordering food and more. Example: I want to purchase a car . 🚗 Guiding Principles ITSM Academy's ITIL Practitioner course is based on these 9 Guiding Principles 1) Focus on VALUE - I need a car but I don’t want to exceed my budget for this. Value for me means awesome performance and that this car looks amazing. It must be a good fit and be cost effective. Good luck, right? Value is determined by price but also by performance and perception. 2) Design for Experience – Here I would be looking for something that is durable, has lots of techno gadgets built into the dash and if it is luxurious w

BRM, DevOps and Excellence in IT Service Management

To say that digital technology has changed the world is an understatement. Digital transformations are revolutionizing entire industries and reshaping every aspect of business. To stay competitive, businesses must accelerate the delivery of digital products and services. To meet business demand, IT organizations must accelerate the delivery of secure, high-quality and reliable software features and functionality ( DevOps ). The thing about any transformation, whether it’s the digital transformation affecting the world, or the DevOps transformation affecting IT organizations and their business partners, is that it’s never only about the technology. A successful transformation requires shifts in peoples’ behaviors, mindsets, vocabulary, roles and reporting relationships. It requires changes to processes and to day-to-day operating procedures. Perhaps most importantly, the ability to undertake and achieve any transformation is determined by whether, or not, the company’s leaders

DevOps & the Top 5 Predictors of IT Performance

DevOps is here and it seems to be what everyone in ITSM is buzzing about. So what are the goals and how do we know it’s not just the next hot kitchen color for this year?  DevOps is a cultural and professional movement that stresses communication, collaboration and integration between software developers and IT operations professionals while leveraging agile, lean and traditional ITSM practices. Stakeholders on the development side will include, but not be limited to, all of the people involved in developing software products and services.  On the operations side it will include, but not be limited to, all of the people involved in delivering and managing those software products and services and the underlying IT infrastructure on which it is being delivered.  The goals are to better align IT responsiveness to business needs, smaller more frequent releases, reduce risk, increase flow, improve quality and reduce time to market. These can only be accomplished by underst

IT Benefit to Business

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 Services: External View vs Internal View

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

Change Evaluation

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 Technical Catalog

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

FAIL

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

To Collaborate or To Compromise … Which Is Best?

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

Failing Forward

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

Do LESS with LESS! Really??

Since the start of the millennium we have all heard that we must do “More with Less”. I recently read an article where the idea of “Less for Less” was looked at from the perspective of if our resources are cut then we will have to cut programs, products, and services also.   Perhaps we should look at how to cut back on to whom and what we produce in order to stay within our means. Government sequestration may have triggered this way of thinking for some service providers. This is a catchy title but is this really the case?   Is there a different perspective on “Less for Less”? Think back a few years when a downturn in the economy negatively impacted the workforce.   Families got creative.   The new trend became staycation instead of vacation.    A staycation meant less travel arrangements for less time in planning, less time on the road or in airports and therefore less missed connections, less cost for the family resulting in less stress and less debt!   What about VALUE!   W

Building a Community of Practice (Part 1)

What do you think would happen if everyone who attended an IT service management (ITSM) class – ITIL, ISO/IEC 20000, MOF – went back to work and talked to the person who sits next to them about how their organization could apply best practices? Or, what if everyone shared their ideas with just the people in their work groups. Those organizations would see tremendous benefit. Even small steps – think plan-do-check-act – can reap large benefits over time. But why stop there? Many organizations have people in different departments and locations, perhaps even in different parts of the world, who must work together to realize the true benefits of a consistent, integrated approach to ITSM. A community of practice can be used to bring these people together. A community of practice (CoP) is group of people who are bound together by similar interests and expertise. Members are active practitioners who come together to share information, experiences, tips and best practices. Members prov

Celebrating National Customer Service Week (Part 2)

It’s National Customer Service Week (NCSW). Held every year during the first week in October, NCSW provides an excellent opportunity to explore ways to better serve your customers. A great starting point is ensuring your policies, processes and procedures are customer friendly. What does that mean? Be a customer for a moment. What are the things that drive you crazy? Here is my list of pet peeves, along with a few suggestions. Limited options – Every process begins with a trigger. For IT organizations, a common trigger is a call to the Service Desk to report an incident or submit a service request. Times have changed. Increasingly customers want the ability to use other channels such as email, self-help via the internet, chat, and in many cases, all of the above. There are currently four generations in the work place, all who have very different expectations and desires in terms of how they obtain support. Are your processes keeping up with the times? Surveys, focus groups and needs a

Process Improvement is Like Driving a Stick Shift Car

Have you ever driven a stick-shift car? At first, it feels as if there are way too many steps to remember just to move from park to drive. Step on the clutch, put the car into gear, ease off the clutch as you gently press on the gas. Once you are moving, you then have to upshift and downshift to navigate thru traffic, all the while hoping not to stall the car or strip the gears. What if you get stuck on a hill? It takes all of your skill not to slip into the car behind you. You may have thought, "Is this really worth it? If I were in an automatic, I could just put it into "Drive" and go. This stick-shift is slowing me down". So why do race cars choose manual transmissions over automatics? The answer is simple - it gives the drivers better control, helps them meet the challenges of the track and allows them to go much, much faster. IT Service Management process improvement is similar to driving a stick-shift car. At first, you may perceive newly implemented processe

Defining Categories

I often hear from organizations that they are not reaping the expected benefits from their Incident Management Systems or integrated Service Management suites. One of the biggest reasons is that they are struggling to determine how to categorize incidents, problems, service requests, changes, and so forth. Coming up with the right categories for your organization is easier said than done. If you’ve had to do it multiple times, you’re not alone. Having said that, it is important to persist. Categories drive many process activities such as: Incident matching Second- and third-level escalations Workflow management Self-service decision tree logic Priority definition Knowledge base searches Trend and root cause analysis Metrics production SLA reporting Miscategorized records cause inefficiencies, ineffective reporting and can even damage the relationships between lines of support. For example, are your second-line support teams regularly asking “why was this record assigned to me?” If so,

Service Requests and Change Management

I was having a discussion with a learner this morning about the difference between Service Requests and Standard Changes. This learner's organization publishes a list of standard services that users can request via a self-help tool. The Service Request will be routed to the Service Desk. The Service Desk will review the request. If appropriate, the Service Request may be fulfilled by applying a Standard Change that has been approved by Change Management. By definition, a Standard Change is a pre -approved, low risk change (such as a new hire) that can be fulfilled almost immediately. Standard Changes must be recorded, possibly as a Service Request. They do not require operational oversight by the CAB. It is important to note that not all Service Requests are Standard Changes. Service Requests can include questions, queries, complaints and compliments. Similarly, not all Standard Changes are Service Requests. Standard Changes can include batch jobs, patches and other low risk chang