Service Lifecycle

[EMMCEE-MT]

Hello everyone. I have this question in mind and would appreciate discussing it so as to clarifying it.

Within ITIL, we find a number of stages within a service lifecycle, namely Strategy, Design, Transition, Operations and CSI. Within each of the stages, we then find a number of processes such as availability management, incident management, capacity management, etc, etc.

My question is this, in a factual manner, how would one explain the service lifecycle in a tangible manner? I mean, does it mean that whenever I am planning for the availability or capacity of a service I am in the design stage of that service? Does it for example mean that I have to manage my Service Catalogue while I am designing my service and not while transitioning it or while operating it?

Are the ITIL stages defined as a cycle because any one of them can be engaged at any point? For example, I can have a service within the operations stage but I engage in design processes for example for its retirement...is this right?

Thank you all in advance.
Matt

[rickstevens]

Hi there.

I think its easier to look at the processes across the whole lifecycle and not just as part of the publication they appear in.

A lot of the processes in reality work across varying areas of the lifecycle, as do the SO functions.

If you take Availability and Capacity as examples, much as they are documented in the Service Design publication, they will be regularly involved in things like Service Operation and CSI.

Similarly with functions, Service Desk, also perform actions within Service Transition and CSI, Applications/Technical Management pretty much work across the whole lifecycle.

Rick

[EMMCEE-MT]

Hi Rick, thanks for your reply.

So if I take your point correctly, the 24 processes across the whole lifecycle may be engaged at any point throughout the existence of a service and thus one is better off not binding a specific process with a specific stage, except for ITIL exam purposes. Correct?

So, I may have a service in operation with an Incident Management process in place (service desk and operations fully adhering to it), however I may engage in say IT Service Continuity process for that service (thus engage a service design process while I am in the operations stage).

Am I correct?

Thanks a lot,
Matt

[rickstevens]

Hi The ITSCM process should have been designed at the design stage of the service, and tested through the transition stage. The implementation (should it be necessary) would more than likely be at the operations stage by Service Desk, or Ops Management, but it would probably be the BRM who makes the decision to implement, which takes you back to the Service Strategy Publication as well.

[EMMCEE-MT]

Hi Rick, thanks.

So ultimately, say I will be implementing a new service within my organization (e.g. a payroll service).

The first processes (strategy apart) I would go through are the ones relevant to me within the Service Design stage of the lifecycle (service level management, IT service continuity, supplier management, availability management, etc).

Then I would progress the service through the Transition stage, applying the relevant processes applicable to me.

Then when the service is ready to go into operations, I would go through and implement the operations stage processes (incident management, request fulfillment, etc).

CSI processes take place throughout and across every phase.

Is the above a correct line of thought?

Many thanks,
Matthew

[rickstevens]

Hi Matthew

Also bear in mind that as a service is being built and tested in the transition stage, it may have to go back to design if testing shows that it will not produce the desired value, or it may go back through design and transition should CSI identify any improvement opportunities at a later stage

Some of the operational processes e.g Incident/Problem/Request Fulfillment etc will more than likely be in place and at some level of maturity before your new service enters the operational stage as you wouldn't generally design one of these processes around a specific service and they would have more of a 'generic' feel about them.

[EMMCEE-MT]

Thanks Rick...that clarifies. Much appreciated and best wishes for the New Year.

[EMMCEE-MT]

Dear Rick and all,

I went through the replies a number of times and while the response clarifies, what would be your feedback to the below specifically:


"In ITIL V3 there are 26 processes within five stages of the service lifecycle. For an upcoming service which is yet to be implemented (e.g. payroll), are these processes (and stages) meant to be followed in a sequential manner that is, starting from processes within Strategy, then onto processes within Design, Transition and Operations? Is this the ideal practice, that is, is this how it should happen in the ideal world?

However, does the concept of service lifecycle in ITIL mean that while I am for example in the Transition phase (testing the upcoming service), I can invoke processes from the previous (or another) stage, e.g. Availability Management within Design?"

Many thanks again!
Matthew

[rickstevens]

Hi Matthew

The 5 stages are a natural progression, e.g it's difficult to build, test and implement a service if it hasn't been designed first. You cant design and implement a service without the business buy in at the strategy stage etc. These stages however could be a seamless process dealt with by very few people in reality as sometimes roles from different stages are combined into one position within the organisation.

Its entirely feasible that in a small organisation, the whole lifecycle for implementation of a new service could be dealt with by 2 or 3 people. The person that designs the new service could also be the person who is responsible for release and deployment in the transition stage. Someone else could be responsible for the validation & testing, and also be the change manager in the transition stage, and also involved in problem management at the operational stage

There may be some processes in various stages that dont apply to your particular situation, and as such would not be applicable. ITIL is a framework, there is nothing stopping you only using certain processes, and omitting others if your personal situation allows it. Similarly, there is nothing stopping you having a hybrid setup, using other frameworks to compliment ITIL. Essentially its a case of 'whatever works for you'.

There is nothing wrong with revisiting processes from an earlier stage if necessary. As in your example with Availability management, if you are at the transition stage of a service, and the specified requirements for Availability Management will not allow the service to deliver the required value, it would be sensible to revisit the design stage. Similarly once the service has entered the live environment, Problem Management, CSI, etc could identify unforseen availability issues that need addressing, and again the design and transition phases could be revisited

[EMMCEE-MT]

Thanks Rick, I find your explanation excellent. Thank you and best wishes for 2013!