Skip to main content

The Status of a Service

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 anticipated investment to achieve them.   Is it a strategic plan with identified market spaces, outcomes, priorities and policies?  Is it a formal proposal from the business or a SIP to an existing service from CSI?  Most importantly, the impact to the existing portfolio and resources must also be defined.
  • Analyze: The analysis phase requires input from multiple specialized areas.  Ensuring the correct people with the right skills and knowledge to perform the analysis can be quite challenging.  Many organizations employ a standard pool of engineers, architects and managers to evaluate each service and the changes to be undertaken.  The methodology in how the service will be analyzed must be defined so the correct sets of data can be collected with minimal disruption to the existing environment.  Of course any analysis must include working with financial management to correctly calculate the values of the service  in order to be able to properly prioritize the investment for strategy.
  • Approve: Once the value proposition has been communicated and the business case documented, management can begin work with customers and business executives to decide if the service is feasible.  Once feasibility has been agreed in the case of strategic changes by portfolio management , the new service or change to an existing service will be submitted as a proposal to change management for a detailed assessment and final authorization. There are two separate rounds of approvals here.  Portfolio identifying the boundaries of what the service should achieve and how much investment is available. Change management facilitates further investigation by providing a high level blue print for the new or changed service.
  • Charter: This is a document authorizing the work to begin.  It has defined objectives, outputs, schedules and expenditures.  Charters are usually used to initiate the design stage of a project or change.  The charter ensures that all development, testing and deployment staff have a common understanding of what is to be built, by whom, a schedule of when and a budget of how much it will cost.  The term charter implies that an organized approach such as project management will be undertaken to ensure that all changes will be properly carried out. The charter will typically include an overview, scope and objectives, assumptions, sponsorship, deliverables, resources, risks, schedules, controls and authorities.  This charter will be used throughout the design and transition stages of the service.
 So we can see that even before a service begins to take shape, a vast number of resources, processes and activities will be undertaken to ensure that once the service goes live it will deliver the optimal levels of utility and warranty. That it will be available to the right people at the right time and the service will be one that given the cost will deliver the required value for money.


Comments

Popular posts from this blog

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 policies (r…

How Does ITIL Help in the Management of the SDLC?

I was recently asked how ITIL helps in the management of the SDLC (Software Development Lifecycle).  Simply put... SDLC is a Lifecycle approach to produce the software or the "product".  ITIL is a Lifecycle approach that focuses on the "service".
I’ll start by reviewing both SDLC and ITIL Lifecycles and then summarize:
SDLC  -  The intent of an SDLC process is to help produce a product that is cost-efficient, effective and of high quality. Once an application is created, the SDLC maps the proper deployment of the software into the live environment. The SDLC methodology usually contains the following stages: Analysis (requirements and design), construction, testing, release and maintenance.  The focus here is on the Software.  Most organizations will use an Agile or Waterfall approach to implement the software through the Software Development Lifecycle.
ITIL  -  is a best practice for IT service management (ITSM) that focuses on aligning IT services with the needs …

Incidents when a Defect is Involved

Question: We currently track defects in a separate system than our ticket management system. With that said, my question is does anyone have suggestions and/or best practices on how to handle incidents when a defect is involved? Should the incident be closed since the defect is being worked on in another defect tracking system if it is noted in the incident ticket? I am considering creating an incident statuses of 'closed-unresolved' so the incident can still be reported on in our ticket management system but know it is being worked on/tracked in the defect system. With defects, it is possible that we may never work on them because they are very low priority and the impact is low to the user. However, in some cases a defect is being worked on. Should we create a problem ticket instead?
Thanks, René W.

Answer: RenĂ©. In ITIL, the activity you are describing is handled by the Problem Management process. ITIL does not use the term “defect” but it does use the term “known error” to…