Skip to main content

Posts

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

Service Transition: Release Unit vs Release Package

A “Release Unit” describes the portion of a service or IT infrastructure that is normally released as a single entity according to the organizations release policy. The Release Unit can be thought of as a collection of infrastructure items that when packaged together could perform a useful function. The unit may vary depending on the type or item of service asset or service component.  The actual components to be released on a specific occasion may include one or more release units, or may include only part of a release unit.  Release Units should contain information about the service, its utilities and warranties and release documentation.  These components can be grouped together into a Release Package for a specific release.  In general the aim is to decide the most appropriate release unit level for each service asset or component. A “Release Package” is a set of configuration items that will be built, tested and deployed together as a single release.  Each release will take th

Continual Service Improvement (CSI) - Thoughts on Measuring, Value and Risk

The best practice approach and the Seven-step Improvement Process for Continual Service Improvement (CSI) begin with identifying the vision, mission, goals and objectives of the business.  In order to measure with appropriate targets these outcomes and objectives must be quantified. If you cannot measure it you cannot improve it.  First and foremost in order to perform ongoing CSI for a service we must identify the service.  That is just common sense right?  Yet how many discussions take place in Sales, in Development, and in Operations about whether something is or is not a service.  Collectively everyone in the lifecycle has a mission to meet the outcomes of the service or services that are being provided.  Measuring and Reporting For CSI to be successful we measure and monitor and report upon a service end-to-end.   When measuring and reporting IT managers will generally report availability in terms of percent with such things as 99% availability on a server or other c

The Importance of Demand Management

I was recently asked to comment on the importance of Demand Management for IT Services as it relates to the IT Business organization. Demand Management Demand Management is tied to the “Customer” or consumer demand. It is more about the market and what is the demand from that level. Strategic Example Strategic Demand Management might be a business strategy for how to influence user behavior. The telecom industry a few years back offered “Free nights and weekends”. This was a “Strategy” to manage the “Demand” until the provider could get all of the infrastructure laid down to support the demand for service. Tactical Example Within the activities of “Demand Management “ are those that are defined to monitor, manage, and report upon the patterns of business activities (PBA) and the activities of the varied user profiles (UP’s) . Demand Management would provide the UP’s and PBA’s and work very closely with Capacity management (managing workload at the component level to meet