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

What is the difference between Process Owner, Process Manager and Process Practitioner?

I was recently asked to clarify the roles of the Process Owner, Process Manager and Process Practitioner and wanted to share this with you. Roles and Responsibilities: Process Owner – this individual is “Accountable” for the process. They are the goto person and represent this process across the entire organization. They will ensure that the process is clearly defined, designed and documented. They will ensure that the process has a set of Policies for governance. Example: The process owner for Incident management will ensure that all of the activities to Identify, Record, Categorize, Investigate, … all the way to closing the incident are defined and documented with clearly defined roles, responsibilities, handoffs, and deliverables.  An example of a policy in could be… “All Incidents must be logged”. Policies are rules that govern the process. Process Owner ensures that all Process activities, (what to do), Procedures (details on how to perform the activity) and the

Visible Ops & Agile Service Management

I highly recommend The Visible Ops Handbook by Gene Kim, Kevin Behr and George Spafford. There are a lot of intersections between Visible Ops (VisOps) and being Agile.  In fact, following Visible Ops practices allows you to achieve an Agile perspective in a shorter time scale.  There is an area in particular where I think alignment between VisOps and Agile is very strong. One of the four tenets of the Agile Manifesto is that we value “Responding to change”.  This is further underpinned by the principle “Welcome changing requirements, even late in development”.   Agile processes harness change for the customer’s competitive advantage.   This also ties us to the goal and objective of Agile Service Management in “Improving IT’s entire ability to meet customer requirements faster”. Responding to change does not equate to bypassing process or controls.  Every business decision triggers an IT event.  Industry statistics tell us that 80% of outages are a direct results from poor

Visible Ops

Anyone who has worked in Information Technology knows that today, there is and always will be improvement opportunities available to our organizations.  This is especially in light of the pace of change that is taking place in all market spaces and the level of customer expectations that accompanies that change. If you have worked in IT for a number of years, you may remember when change was not welcomed. Well the good old days weren’t always that good and tomorrow ain’t as bad as it seems (Billy Joel).  The challenge is in getting started. If……. ·        the processes that are currently being engaged are not as efficient and effective as you would like ·        you are finding that your environment isn’t as stable and reliable as it should be ·        that when you make changes to your environment it generally results in an outage and prolonged and repeatable firefighting then ……. I recommend that you read The Visible Ops Handbook by Gene Kim, Kevin Behr and Geor

Service Management - Education vs. Training

Although these terms are frequently used synonymously, “Training” is not “Education”.   This is not to say that training is not important because without training, education would be incomplete.  When investing your capital to increase performance and change behavior it could be beneficial to understand the distinction. Education When we are educated we learn facts, theory or required details about the who, what, where, when and why of a particular subject.  Sometimes education will build on a foundation of knowledge so that you may become more expert in that area.  A simple example is given with the idea of a language.  You may know how to speak it.  When you go to school and are educated you learn what a verb is, and how adjectives are used.  We learn the syntax and constructs of the language.  Some move on to be expert linguist. They become educated and highly skilled in the subject of language. When you are attending a Service Management or DevOps course you are learning

Asset Management or Configuration Management - Which Do I Need?

I once heard an IT manager say… “We do not need Service Asset and Configuration Management”!  We have Asset Management and we can add a few more fields of information for IT in that database.”  Is this true?  Would this give the service provider the same value as a Service Asset and Configuration Management Process and System?  Asset Management Most organizations have a process that tracks and reports the value and ownership of fixed assets throughout their lifecycle. This process is usually called Fixed Asset Management or Financial Asset Management.  Activities in traditional Asset Management include such things as documenting the cost of the asset and projected life of the asset.  Other bits of data captured might be the cost of maintaining the asset.  For the most part this is financial information.  Being able to determine the depreciation of an asset is year over year, Total Cost of Ownership (TCO) and Return on Investment (ROI) are key.  Fixed Asset Management maintains

Agile Service Management – Techniques and Methods

Most of us are aware that Agile can be used to improve the effectiveness and efficiency needed for software development.  Agile core values and principles are defined in the Agile Manifesto . But wait!  There is more! While there are many techniques, methods and frameworks that can be utilized to ensure agility within your organization, what is important to note is that they can and should be expanded beyond software development.   Agile Values are realized via many different techniques and methods including: Continuous integration - A software development practice where: Members of a team code separately but integrate their work at least daily Each integration goes through an automated build and test to detect errors and defects The team collectively builds the software faster with less risk Continuous delivery - Continuous delivery does not infer that you are deploying every day or every hour. It means that you COULD release when needed.  It is a softwar

Agile Service Management – Roles and Responsibilities

Agile Development is an umbrella term for several iterative and incremental de velopment   methodologies.  In order to achieve Agile Development, organizations will adopt frameworks and methodologies such as SCRUM and LEAN. Being Agile and using SCRUM, LEAN and other methodologies in development is good!  What happens when development starts adopting this culture and becomes more agile and begins to move faster and leaner than ever before, only to come up against laborious and bureaucratic change management and Service Operation processes?  One example that I heard lately is that it is like pushing more and more paper into a printer and expecting it to print faster!   It doesn’t work! The Agile Principles and the  Agile Manifesto  are applicable beyond software development. Therefore, service providers not only need Agile Development we also need to adopt Agile principles throughout the entire Design, Transition, and Operation lifecycles.  Agile Service Management (Agile SM)

Agile Self-Organizing Teams

“Knowledge workers have to manage themselves. They have to have autonomy”, leadership guru Peter Drucker states in his   Management Challenges for the 21st Century . So what is a self-organizing team?   In many situations teams will be comprised of a group of people working together but not really dependent on what the others do to complete their individual tasks.   Teams should have four main qualities: Collaborative tasks to fulfill a  defined mission . Tying it to the overall vision, mission and strategy. Clear boundaries  in terms of information flow and alignment with other organizational teams, resources or decision-making policies. Roles, responsibilities and interfaces must to be defined. Authority to self-manage  within these boundaries. Must adhere to the overall organizational governance. Stability  over some defined period of time. Possibly defined in a project lifecycle or some other overarching documentation. In addition to these qualities, five essential

Agile Principles & ITIL

Underlying and supporting the  Agile Manifesto  are the twelve principles that help to bring the Agile philosophy to life. The DevOps movement encourages us to adopt and adapt these principles into the ITIL lifecycle not to reinvent it, but to allow us to make it spin faster.  Let’s take a look at them individually and interpret them from an ITIL, operational and support perspective. Our highest priority is to satisfy the customer.   We do this through early and continuous delivery of the proper utility & warranty. Welcome changes, even late in development, by using well defined and nimble change, release and deployment management, teams and models, allowing our customers to remain competitive in their given market spaces. Deliver updated working services frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. OK that one I modified a bit. We’ll   be Agile about it. Business people and IT must work together daily and collaborate

First Call Resolution (FCR) According to ITIL and General Best Practice

A reader recently asked me to comment on what a First Call Resolution (FCR) is according to ITIL and general best practice.   When collecting metrics you want to be sure that the reporting brings good business value. From a reporting perspective it might serve well to report incidents and requests separately.      Each organization will have to have policies for how the metrics are reported based on business value.  One option is to have a policy that will report on “Service Requests” separate from “Incidents”.  If we do not separate the logging and reporting for these very distinct processes the combined metrics and reporting might not be something that is meaningful or that could be acted upon correctly.  You could end up with a very high FCR rate but your Mean Time To Restore Service metric could be breaching the SLA.  Therefore, the question is not whether the call was resolved at first line, but rather was it a FCR for an Incident or Request/Standard Service?  Report upon them

The Difference Between Change and Release Management

A reader recently asked me to comment on the difference between Change and Release Management. The first question “is it a request or proposal?” is a good one.  When we use the term proposal, normally we are speaking about major changes that will involve significant risk, cost or organizational impact.  Proposals are normally initiated by the portfolio management process.  They can also be submitted by a program or project management office.  Again remember that each organization is unique and how they do this and at what level it takes place can be different from organization to organization. This is defined at a high level, but the details necessary will depend on the organizational requirements.  For the most part before the new or significantly changed service is chartered it is critical that the proposed change be reviewed for its potential impact on other services, shared resources and the change schedule. These proposals are submitted to change management before being chart

Service Portfolio

The service portfolio is made up of three distinct elements.  These are the pipeline, catalogue, and retired services. The services themselves will move through thirteen unique statuses that help to define where the service is currently in its lifecycle. The portfolio represents the complete set of services that is currently being managed by the service provider and in turn represents the service provider’s commitments and investments across all of the customers and market spaces the provider is engaged in. It is a portrayal of all contractual commitments with current customers, new service developments for either current or new customers and any ongoing improvement plans initiated from CSI.  Additionally the portfolio can also contain any third party services that are currently being engaged by supplier management.  It can be presented as anything from a structured document to a database and is a tool that is utilized from service strategy to continual service improvement. The

Definitely Definitions

What is a Service? ITIL defines a Service as "a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks."   In other words, when we do something for another party that gives them something they need or creates value for them, we are providing a service. Customers/users want to enjoy the benefits of the services we provide but don’t want to take on the challenge of managing those items themselves, therefore we provide those items to them in the form of services. It is also important to differentiate between client-facing services that allow end users to do their work and internal technical services that enable those services to be delivered efficiently and effectively. At a strategic level it is important to understand the concepts of services, customers, value, service providers and how organizations relate to them to help us define which services will be delivered and to whom they will be