Skip to main content

Posts

Showing posts from June, 2015

Service Operation and the Service Lifecycle – Yesterday and Today

ITSM Best Practice will align five main process with the lifecycle of “Service Operation”. Incident Management Problem Management Event Management Request Fulfillment Access Management  It was not too long ago that the idea of some of these processes were new to service providers. Most will find them to be common in today’s market place.  An organization may not literally follow the best practices for the service operation processes but most likely have some close facsimile when executing Incident, Problem, Request Fulfilment, and Event management processes for provisioning IT services and support.  In order to ensure identity management and authorization for access, some form of “Access Management” will also be needed to support an overall security policy in Service Operation.  I would like to focus on some thoughts for “Event Management” and early engagement of operational staff in the service lifecycle. As organizations mature they begin to realize the value

Transition Critical Success Factors (CSF’s)

IT is a large and growing slice of the overall budget for many companies. That money spent on IT is anticipated to create business value and support business growth. However in many IT organizations, a considerable percentage of this budget and IT labor is consumed on managing of incidents. First, second and third tier levels of support along with support technology and tools can become expensive to retain and maintain. In fact this is unplanned work which inhibits value creation and business growth. Many people will advocate a solid proactive problem management process to eliminate the root cause of these incidents and I am right there alongside them. However, I think we need to look even earlier in the service lifecycle. The standard statistic that I see most often quoted is that up to 80% of all incidents are cause by undocumented and unauthorized changes.  So for the sake of this argument let us take that as our baseline and discuss critical success factors facing service tran

Thoughts on People and Process

The “ Agile Manifesto ” states that “We value Individuals and Interactions over processes and tools”.  What? Some have taken that statement and interpreted it to mean that when it comes to design and development … “No Process” is required!  In fact if we look further in the manifesto we see clearly that the value of process and tools is indeed recognized.  The manifesto is trying to impart the importance of people and interactions.  If we have a brilliant process that is defined and documented and yet drop the ball when it comes to people and interaction we will surely miss the mark every time.  Therefore, while there is value in process and in tools service providers must value the people and interaction with them more. In her book titled “The ITSM Process Design Guide” Donna Knapp stresses the importance of “Just Enough Process”.  When designing ITSM processes such as Service Level Mgmt, Change Mgmt, Incident Mgmt and others, service providers could miss the mark and over design

The Agile Service Manager

A core principle of popular Agile methodologies is to limit “Work in Progress”. Self-organizing Scrum teams, will only take on a small piece of work from the overall backlog that can be completed within a timeboxed period, normally between 2 and 4 weeks. By limiting their focus and attention to what is most important (priorities are set and agreed to) you enable the team to complete the agreed to work and by limiting work in progress we train teams to finish work, rather than begin added work. With this focus to customer requirements, a higher level of quality and more satisfied customers is the result.  Additionally, because the work is done in smaller increments, there is much less risk to our environment. In order for our ITSM teams to move from the methodologies currently being used to Agile methodologies such as Scrum and Kanban to name a couple, we must have an advocate for our teams to be able to engage in this new way of developing and maturing our ITSM/ITIL processes. T

Operational Support and Analysis (OSA)

What if we did not build an operational support system to meet current business requirements?  That might sound a bit outrageous and contradictory to everything we have learned. If you are a service provider than you are aware that what we consider premium service support today could be accepted as the norm and sometimes can be outdated before it becomes a reality.  The key to sustaining underpinning operations for any industry is in the constructs of the system.   If we build a system to provide what the customer and business outcomes require now then that is what we will have.  The likelihood is that we will have a system that provides for a service that will render itself less than optimized in a shorter time than we would like to think. What is required is an operational support system that can deliver fast but also one that is able to shift, bend and weave with the ever-changing environment and outcomes that it supports.  We need a growing living moving system that can ad