Order of Implementation

[Harvey]

Hello all,

I expect this question to return a lot of "it depends" type answers, but I'm execting and willing to read through everyones opinions.

In a truely messy organization that wants to introduce Service Support ITIL practices, where is a common beginning point?

Currnently we are considering tackling our Asset Management, and Incident and Problem Management problems first. Hopefully, this will involve introducing some software packages, likely Remedy or CA tools.

This is far down the road as we need to completely understand our current process, and fix the manual processes first before thinking about digitizing anything... but those are the areas we plan to look at.

Does anyone have any opinions on this?

Regards,

Harvey[/i]

[H]

Harvey,
Actually the answer is not an it depends. The first thing to do before implementing any service is to be sure that someone wants and needs it. Step One- Service Level Management- know what your customers want, if indeed they want anything at all and know specifically what they want, when and how- document it. By the way this works both in and out of your company and organization and is a very sensible way to proceed. Next , be sure you have approval and sponsorship from 'on high'. Then your next step would be configuration management- knowing what you have in order to do the job your customers want. I hope this helps.
H.

[leebc]

Harvey,

I would suggest you assess your organisations current environemnt and the future requirements based on the business strategy. Once you know where you are and where you need to go to, you need to then identify the gaps and devise a route map for bridging the gaps. When identifying and assessing initiatives required to reach you goal and attaching weights and priorities to these intiatives the answers should hit you in the face. The order in which you inplement the processes will depend on the requirements, priorities and effort required. Remeber however to "eat the eplephant in small manageable mouthfulls".

It is difficult to advise or to determine which processes should be tackled and in what order. Each situation is different and the requirements and aspirations of management are also different. Always look at Service Management from the point of view of PEOPLE, PROCESSES and TECHNOLOGY. The technology should not drive the solution. If you have the right processes and people in place the technology becomes the enabler. It may not even be necessary at the end of the day to "automate" the processes if the other two are in place.

I hope this is of some benefit to you.
Colin.

[mcardinal]

Harvey,

I am going to "borrow" an answer provided to me by Ian from ITSMI (thanks Ian).

Ian suggests the best place to start is with IT Service Continuity. Most companies are already doing this process. They will have a handle on what is important to the business and give you a sense of "pain points" to tackle using the other processes (Asset/Config, SLM, IM, PM).

I agree with H. that SLM is probably the overall best place to start, but since I am in the middle of helping that happen at my firm, I realize now it is also the most difficult. SLM tends to bring the biggest organizational change beast out of the cave. I think of implementing SLM like trying to light a match in a tornado. Not impossible, but damn tough!

Once you get going, you will recognize lessons learned and the direction for the next step.

Hope this and the suggestions provided by the others help you get going!

Michael

[Guest]

In my opinion, without Service Desk, the rest are very hard to develop. Since Service Desk should be the single point of contact for all other areas.

[H]

Michael,
You are right- the hardest to implement is Service Level Management but what it does is point out the relevance of IT to the business and so it should be the first. You see in 2004+ IT people have to think in terms of governance. We cannot go on doing point solutions in specific areas.
If we know what the business wants and we align to those needs and implement them then things move much more smoothly with a higher degree of customer buy-in.
I would suggest to us all that implementation as IT gets us looked at as IT- our imperative is to shift that focus to IT as being a core aspect of the business value chain
But yes, this represents a cultural change for both the business and IT- However as IT, ITIL and business professionals the point of focus should always first be - 'What does my customer want' then 'Can I deliver it"
Then the business sees the value.
H.

[GSR]

Hi,

Many of the points provided are good places to start. Management support is critical, and one way to get this support is to let them know what it is costing in terms of dollars, lost productivity, etc... However, this will be difficult if you do not understand the current environement.

To support the buy in by management, you need to know as you stated, the current processes and practices. In short, take one process and and complete a thorough analysis and be sure to invlove the persons t/departments that have a stekhold in the process For instance: Where does the process start and end, who is supporting a given activity, any sub activities, etc... In theory Who, What, When, Where, and How.... not necessarily in that order.

Part of the review includes identifying the information that is currently on hand, such as asset information and continuity management information, forms, and previous documented activities etc... If there is no information, then this information gap should be noted. This info gap often helps in later activities, i.e you find an asset database, but without a tie in an incident tracking system. In reviewing the DB you may disover missing/inaccurate data. If this is noted and you can estblish what information is needed, then when implementing SLM you can make sure these issues are covered.

From this data you can identify critical components that need immediate attention, and where temporary measures can be implemented to alleviate some of the pain as well as to stabilize the activity.

At this point you could then begin developing and implementing SLM activities. From the SLM, then other activities can be estblsihed and supported, withh agreements between multiple departments etc...

Keep in mind that a business process review/analysis will be met with some resistance and this is not something to be completed in just a day or two. Just defining the process for buying a PC and installing the device, could take four days to completely define, and document...

Hope some of this helps...

GSR

[meindert]

When you look at ITIL processes, expect for the obvious things like management support etc, the "customers" mainly are the end-users of IT. So start with what they need first (quick win)

What has been best practice in many companies is to start:

simple incident management + simple change management + simple config/asset mgt

to start incident management, establish a point-of-contact (for "customers") , no matter how simple; this will speed up the need and awareness in the organisation that "this"is helpful.... not peer support, but a single point of contact to start solving incidents and listen to the problems that end-users have....

Meindert

[blamblam]

I think the best place to start is with Service Support activities as most organisations are doing these to some degree. Within this Service Desk, Incident Management and Change Management are the clear must do's. I typically start with Change Management as it's fundamental to controlling the supported infrastructure.

[cysun]

We normally do an initial assessment exercise as part of our delivery methodology, to see where are the weakest areas from an ITIL perspective and then make a presentation to the customer to show them the results of our initial study. If, for e.g. they are already strong in Incident, Configuration and Problem Management (i.e. strong foundation present) there's no point taking on those processes. If the report highlights the fact that Service Level is an area which needs greater improvement, then that's a place to start. In essence, an assessment study would be a good tool to have.

If we're talking about greenfield implementations, I would have naturally thought that deploying Configuration Management would be the place to start. I'm of the opinion that no point talking about the higher level customer facing processes until the foundational processes which users see most visibility needs to be in place before anything else. I wouldn't dare to sign an SLA with a team who can handle my service calls in the first place. So I agree with blamblam and meindert on this: start with the foundational processes like:
- Configuration
- Change
- Incident & service request
- Problem
- Release
Then move on to the other processes once the foundational processes stablises out. Foundational processes are there to show value and capability of the IT organisation. The remaining processes, IMHO, show business to IT alignment and further builds on the trust relationship.

[Harvey]

Thanks for the tips everyone!

We don't have the resources available for an official asssessment actually.

[slash]

Harvey,

Most organizations will have a Service Delivery Organization in place. It may be called something else, and may be based on the older OSI FCAPS model.

I am on my third ITIL process implementation project. My Best Practice approach (very high level) is as:

1. Review and document (high level) existing functionality and capability within the current Service Delivery Organization.
2. Perform Gap Analysis using CMM against the end state ITIL Process model. Though CMM is primarily used for process maturity rating, it can be stretched to cover organization (staffing, skill sets, org structure) agains the the ITIL RACI chart, and for technology (coverage, effectiveness, process mapping, etc.). Consider Business Alignment as another factor for analysis.
3. Review Gap Analysis results with Executive Level Sponsor to estimate costs, resources and implementation schedule.
4. Generate an Implementation Plan (Overall to begin with) focussing on quick hit improvements and migration to ITIL which will have an immediate and significant positive impact on Service Delivery. This will help with the business justification aspect. Be EXTREMELY REALISTIC.
5. Upon approval from the Exec. Level Sponsor, detail Implementation Plan in to sections covering each required ITIL process within Service Desk and Service Delivery and the implementation schedule, usually 6 months, 12 months and 24 months. The objective is that all ITIL processes must achieve a CMM level 3-4 rating at the end of 24 months.
6. Use a Project Management Information System (like Primavera or MS Project Server) to manage all action items (project taks), resources, costs, and schedules.
7. Use either COBIT or PRINCE2 for Program Governance of the entire project.
8. Develop and implementation a documentation standard:
Level 1 – Logical
Level 2 – Detail Logical
Level 3 – Work Instructions
I also use Quickplace to store all documentation centrally.
9. Develop a training plan for ITIL training and certification. Ultimately all ITIL Process owners/managers should be certified at the Manager level for their respective processes. Include within the OCM (Organizational Change Management) Plan.
10. Manage the entire project closely and tightly, else failure is guaranteed.
11. Towards the end of project, document tangible and intangible benefits of implementation to determine and claim project success.
12. Upon project completion, implement process for Continuous Improvement.

So, does everyone agree?

-Slash