*NEW! Just before you get into this article - you may like to pop over to our very latest site "AskTheServiceExpert".
We have just prepared a free download of a special two hour Teleseminar covering ITIL Implementation Strategies.
You can access the replay, notes and special bonus resources.
To Learn More Click HERE.
Scott, over at Real World ITIL, has recently raised several excellent questions on his Blog about Real World ITIL implementation. If you have not read this Blog before you really need to check it out today. Lot's of interesting and complimentary advice over there.
We thought we would take each of Scott's questions, in turn, and have a good go at answering it here - and then post all the article back over for Scott's readers to absorb too.
Please feel free to add your own comments to this article. It's a healthy debate - and your ideas and experiences will be appreciated by many!
Key Questions (and Dr. ITiL's Answers):-
Should there be only one entry point into IT for incidents and other requests or multiple points-of-entry depending on type of request?
Like Highlander (seen the film?) - "there can be only one". What we mean is this - one entry point ensures that the IT Service Organisation has one version of the complete truth at any one time.
This helps to ensure that everything is prioritised for resolution (or completion) against everything else. Also, it ensures that related (linked) Incidents are tracked and a complete picture of what's happenning where - is maintained at all times. Multiple entry points leads to conflicts when Incidents are presented to Support people. Multiple entry points also means that Senior Management and the Customer will not necessarily receive timely, complete and acurate Incident updates whilst service is restored - a recipe for Service disaster.
Work requests should be prioritised differently and allocated to different functions for processing. In both cases the end-user should have access to online tools that ask the approriate questions to help drive the accuracy of incident or work request allocation.
• What process should be implemented to govern requests for IT services that are neither incidents nor ordinary service requests (e.g., a request for a new major project).
Also, how much latitude do our IT managers really have to deny a request for a service that is not defined in our Service Catalog? There should be a 'one stop shop' approach for ANY incoming request to the IT Service Organization - the Service Desk (the clue's in the name!!) The Desk can log and track all requests - however some 'out of line', unusual or out of service scope type requests should be allocated to hand-off points, such as "new project" type requests. Such a request can then be examined in more detail by the appropriate team and feedback provided.
This makes everything very simple for the end-user, the business and ultimately the IT Service Function. Most Service Desks are used to the opening line, "I don't know whether you can help me - but I would like to know.......". As for the second point, denying requests, the astute IT Manager should never say "no", but should learn to say, "Yes, however...". Everything is possible - but requests take time, effort and money to process successfully.
The Service Desk should direct difficult and unusual requests to some kind of predefined 'back stop' manager, who's responsible for reviewing and then re-allocating such requests. So, returning to our example (above) you would hear something like, "Yes, you can have what you need, however, it's going to need to go through the project approval process... and here's how you can do that..."
• Should root cause resolution be pursued for all problems or only the ones that had the highest negative impact?
I don't really agree with the 'either' / 'or' premise here. Also, we're assuming the question should have used the word "elimination" rather than "resolution". With only a few exceptions (later) ALL problems should have their root cause assessed, analysed and where possible eliminated. Where this cannot be done a business decision about "impact V's frequency of occurrence V's workaround effectiveness" should be made. Obviously, the higher the impact and frequency of occurrence - then the higher the priority of permanently removing the problem from production.
As for the exceptions, well they are generally based on two criteria:- "It's just not worth spending the time to eliminate that problem" (probably because the system is being upgraded or retired soon) and, "We can't find the problem - it's far too complex to eliminate - therefore (in agreement with the business) we will just 'live with it' for now". Not perfect - but certainly real-world!
• Should dedicated teams be organized around Problem Management, Service Level Management, Change Management, etc. or should there instead be “virtual” teams defined from the existing hierarchy?
Mmmm, very interesting question. Your first answer would always be, "yes, let's get some dedicated resources focussing on each team." However, this is massively influenced by the maturity level of ITIL within your organization. When you are in 'start-up' mode or you have just recently launched a new service function - you definately require dedicated and focussed resources to drive through the benefits of the function and ensure that the business receives the service that (some how) it's paying for.
Thinking ahead though, when things are bedded in and running more like clock-work (which is influenced by the rate of internal change!) you will want to more efficiently allocate resources to the service functions. Having an expert team of cross-skilled ITIL'ers capable of delivering against multiple functions is a very advanced way of working. [anyone doing this??] It's also a very cost-effective way of working.
My advice would be: start off by being dedicated, then get smarter and utilize your resource capability across multiple functions. Warning: It's advisable to still have the functional manager focussing on one, maybe two key processes. The resources underneath, who perform the real work(!), can be 'pooled' over time. This also gives them a more dynamic career path and ensures job enrichment.
• If we’re a global corporation, should there be only one Definitive Software Library at a single location to hold all master media, licenses, etc. or should it be distributed?
Yes, again the one version of the truth model applies here too. One complete picture removes the need for multiples copies, which can lead to inconsistent views and erroneous decisions being made. In reality, several Sub DSL's will probably feed into ONE master DSL, in a logical sense. Note: Local contracts, laws, information/property/storage restrictions can apply that make the one version impossible.
• Given that completing an actual physical inventory of IT assets is unfeasible and that automated tools can only discover a portion of our assets, how much inaccuracy can we stand in our CMDB and still have it be of value?
Ask yourself this: "What happens in each ITIL process when my CMDB is innaccurate for X% of the data I use?". For example, during Incident Management you need to know your Infrastructure topology to determine the Incident's impact and be able to correctly categorize the Incident. If your CMDB is missing assets - how can you do this?
Another example, the Change team are assessing the risks of performing a change on your live production environment but the CMDB information cannot see the linkages between the item being changed and any related items for another geographic location. How can you determine the true risk without an accurate picture? In the real-world, the cost of moving from 95% CMDB accuracy at any one time - to 100% is likely to be very high.
You need to weigh up the cost of achieving and maintaining 100% V's 'the impact to service of <100%.>
If your team feels that you've settled for, say, 80% than that's all you'll ever get.
• How do we define “overprovisioning” and “underprovisioning” with respect to Capacity Management? Should we for instance establish a policy such as “we will manage infrastructure capacity to within +/- 10% of actual client demand for service?”.
In our view, Client Demand differs greatly from "what you need to effectively run the service - and keep it running!" Clients are humans too and will always go for whatever the maximum is. They don't want any downtime as a result of a system running out of capacity and neither do you.
In this example any past experiences with the level of demand should also be factored into the decision making process. So, for example: If the Client has (or is likely to have) high levels of new users on any system, but with incredibly short notice (that's if you get told at all!) then you know that you need to run capacity with an in-built slice of capacity to accommodate this scenario. Subject to SLA's, contracts etc.
In our experience - especially where resources are relatively inexpensive compared to the impact of downtime (e.g. Disk, CPU, Bandwidth) you should aim to keep between 15%-25% capacity free, when balanced against the potential to actually use it, the costs of providing it (and maintaining it) and the Clients demand profile. We find it rare that systems are so nailed down, change so tight and the Client so well informed that everything run, "just in time at the optimum level".
• What are the three most essential governance metrics that our processes should generate for management purposes?
[1] Satisfaction with Service Availability, [2] "Under Control", [3] Future-Proofed delivery.
Ok, we've tried to be clever and make some thing high-level and generic. But for me the most important aspects of delivery are:
[1] Is the Client and your board satisfied with your level of delivery against Service Levels - Are you delivering what you need to - to the Clients Satisfaction?
[2] Is everything "Under Control"? Are you managing your Audits, issues, risks, maintaining standards, delivering against KPI's, hiring people fast enough - there's a big list of things that fall under this category.
[3] Are we continuing to do the right things, at the right time, to assure and future-proof the delivery of service today, tomorrow and in a years time.
• How much influence should the Financial Management team have over the control of other service delivery processes? How much effort should we put into developing a cost transparency model for our processes?
None. It's not the Finance teams' role to control any other Service Delivery Function. However, they directly influence, impact and enable (all at the same time) the resource and cost levels apparent within the other Service Functions. This then determines the quality, scope and capability of the team [people, tools, training,etc].
As for transparency, this will depend on your desired cost-model and how the Client has opted to pay for the service it receives, via the Contractual terms. Smart outsourcers know, hoever, that transparency gives them greater scope for making ongoing cost casvings - and therefore helping them to increae their margins faster over a shorter time period - so they will opt for greater transparency. A smart Client will be keen to understand who they pay for , in terms of service delivery, and what saving they can make over time - this reduces the Outsourcers revenue stream. Natural tension or Tough Love? It all happens in the real-world!
Anything to add? Why not post your own views below and add to the debate.
Posts
