The relationship of IT Performance on Business Performance is becoming more evident today as service providers strive to meet the dynamic rate of change that is required to meet business requirements.  It is unfortunate that all too often the evidence for the lack of IT performance is brought to the forefront because processes break down, cost overruns occur, and business outcomes suffer.  When the flow of work is broken the service provider is not enabled to provision service at the rate of demand that is required and the cost of provisioning tends to soar. When we look at the lifecycle for the deployment of a new or changed service we recognize that there are many roles, functions and activities that a service provider must manage and control.  When the development activities are silo’d from deployment and operational activities the value stream tends to break down and IT staff suffer.   This breakdown often results in frustrated staff that feel that they are not enable for

You may have heard a lot of buzz around the DevOps movement that is taking hold in today’s industry where service management quality and efficiency are paramount.   The term "DevOps" was popularized through a series of "DevOps Days" starting in 2009 in Belgium and it is said by those present that they knew they were witnessing something very different and unique.  They knew they were on the verge of something that would change the way that all service providers designed, developed and delivered services in every industry.  Since then, there have been DevOps Days conferences held in India, Brazil, Australia, Germany, and Sweden and other parts of the globe including the United States.  So what is it? Business demand is increasing! That is not news. The need to produce services fast is increasing!  We know that methods such as Agile, Scrum and others that have increased capability for development of products but we must recognize that as only one element in the

During the lifecycle of a service, it will progress through thirteen different statuses as it moves from the portfolio into the service catalogue and finally into a retired state.   We are going to look at four of the statuses, that are undertaken within the service portfolio that help to bring a service from an idea, suggestion request or plan to one that has been commissioned and authorized to meet a set of defined objectives. They are define, analyze, approve and charter. The process for initiating a service can come from any number of sources and take a number of different formats.  For simplicity we will just refer to these as requests. These requests can come in the form of a strategic plan, an enhancement from BRM, an opportunity for improvement from CSI or as a suggestion from some other service management process.  Define: Here we define the desired business outcomes, opportunities, utility and warranty requirements.  A definition of the service itself and any anticip

In the Strategy stage of the Service Lifecycle there are several questions an IT service provider must ask in order to determine the services they should be delivering, whom they should be delivering them to and is value creation and capture possible.  They are:  What is our business? Who is our customer? What does the customer value? Who depends on our services? How do they use our services Why are they valuable to them?  Given the answer to those questions, the service provider can then determine the types of services to be delivered, resources needed and what risks and constraints need to be identified and managed.   There are three types of services the provider will have to consider, supporting services, internal customer facing and external customer facing services.  Services whether internal or external are further broken down as core, enabling or enhancing.   Here we will be looking at supporting, internal and external facing services. Supporting Services:   A serv

The definition of an IT service has certainly evolved: IT Service   (ITILv1) :     A set of related functions provided by IT systems in support of one or more business areas, which in turn may be made up of software, hardware and communications facilities, perceived by the customer as a coherent and self-contained entity. An IT service may range from access to a single application, such as a general ledger system, to a complex set of facilities including many applications, as well as office automation, which might be spread across a number of hardware and software platforms. IT Service   (ITILv2) :     A set of related components provided in support of one or more business processes. The service will comprise a range of   Configuration Item   ( CI ) types but will be perceived by   Customers   and   Users as a self-contained, single, coherent entity. IT Service   (ITILv3) :   A   Service   provided to one or more   Customers , by an   IT Service Provider . An IT Service is base

A process is doomed if you ever consider it done!  Unlike an audit that examines evidence to determine compliance, a process assessment is conducted to evaluate and organizations strengths and weaknesses.  The assessor will ensure that this baseline is utilized to identify process improvement opportunities that ensure business outcomes. The ITIL Process Maturity Framework (PMF) was defined specifically for ITSM processes and consists of five levels of maturity. ·          Level One – Initial At this level there is not a defined process, there are some procedures and few results are retained. ·          Level Two – Repeatable At this level of maturity there is a recognized process but the objectives are not clear and targets are not formalized. ·          Level Three – Defined It is at this level of maturity that the process is defined and documented and there are agreed upon targets. ·          Level Four – Managed A managed process at this level is well defin

There are many challenges to defining and documenting a process for ongoing continual improvement and to ensure process maturity is in alignment with the overall business strategy and outcomes.  One such challenge is to be able to document the “As Is” process. When documenting the “As Is” process caution must be taken not to accept the existing documentation, or flowcharts provided as the true baseline of what is really being done.  What are the current activities and procedures that are being used and what is the step by step workflow that participants and stakeholders are actually performing?  The actual is what really needs to be captured.  The complexity of this challenge is exasperated by the fact that frequently when determining and “As Is” state for immature processes the assessor or process design engineer will discover that there is not one single process that is being followed but in fact many?  What then? Non adherence to process is generally due to little or