Now, for the first time global Organizations wishing to seek assurances that IT Service Providers and Outsourcers are really “up to the job” have a major weapon in their armoury, namely ISO/IEC 20000. The new internationally fast-tracked IT Service Management Standard.
More and more Organizations wishing to ensure that prospective IT Service Providers are capable and have a track record of delivering quality service are ensuring that ISO/IEC 20000 certification has already been achieved and is capable of being achieved for the boundary of service delivery covering their own organization.
But why ISO/IEC 20000?
It’s important to remember that ITIL is NOT a standard. ITIL has no auditing criteria. Contrary to popular belief ITIL tools cannot be officially regarded as ITIL Compliant. ITIL is a framework of best practice that aims to ensure cost effective, appropriate and quality IT services are delivered. But there’s nothing in ITIL to Audit against. It just wasn’t meant to be that way.
Based totally on BS15000, ISO/IEC 20000 certification and achieving the standard is increasing in popularity, especially in the UK and Europe.
Elsewhere adoption is relatively sparse – but this is subject to change considerably since the ISO released it as ISO/IEC 20000 in December 2005. Now, for the very first time the IT Service Management community has an international standard for auditing and certifying IT Service.
But Organizations must beware of Vendor and Outsourcers claims. The Standard has strict eligibility criteria for IT Service Providers. For example, the IT Service Provider MUST maintain effective management control of all aspects of IT Service and there must be a solid commitment to ongoing Continual Service Improvement.
As a standard, ISO 20000 shows IT how to manage and improve IT while establishing audit criteria. In fact, there are 217 requirements that IT Service Providers must achieve when audited by a Registered Certification Body (RCB). In addition, three months worth of actual recorded information must support the IT Service Providers quest for certification.
ISO/IEC 20000 is currently in two specific parts: -
Part One is ISO/IEC 20000-1:2005 => The Specification.
Part Two is ISO/IEC 20000-2:2005 => The Code of Practice.
Part one is ISO/IEC 20000-1:2005 IT Service Management Specification for Service Management. This provides requirements for IT service management and is relevant to those responsible for initiating, implementing or maintaining IT service management in their organization. Organizations can have their IT service management systems independently certified as conforming to the requirements of ISO/IEC 20000-1:2005. Part 1 also defines the processes and provides assessment criteria and recommendations for those responsible for IT Service Management.
Part 2 is ISO/IEC 20000-2:2005 Information technology service management. Code of Practice for Service Management. This gives guidance to internal auditors and assistance to service providers planning service improvements or preparing for audits against ISO/IEC 20000-1:2005. ISO 20000-2 documents a “code of practice” that explains how manage IT with regard to ISO 20000-1 audits.
Both ISO 20000-1 and ISO 20000-2 are related to the ITIL best practice framework. However you DO NOT have to have ITIL implemented to be able to move forward with ISO/IEC 20000 certification. It sure does help though!
ISO/IEC 20000 actually groups many of the core ITIL processes into five core process sets:-
1. Service Delivery Processes – Which includes Service Level Management, Availability Management, Capacity Management, Continuity Management, and Budgeting and Accounting (But NOT Costing) for IT Service Financial Management. These are accompanied with Information Security Management and Service reporting.
2. Relationship Processes – There are two key ones to consider, namely, Business Relationship Management and Supplier Management.
3. Resolution Processes - Incident Management and Problem Management.
4. Control Processes -- Change Management and Configuration Management.
5. Release Process -- Release Management.
So, what does ISO/IEC 20000 actually mean?
It means that there is at last a more assured way of Organizations who spend millions of dollars with Service Providers every year, now have an Audit Standard to help them and ultimately their business.
It also means good news for ITIL which is currently undergoing a re-fresh to Version Three. The development of ITIL Version three is paying close attention to ISO/IEC 20000.
With ITIL and ISO/IEC 20000 combined, although different and exist to deliver quite separate deliverables, will enable IT Service Providers to march ahead with confidence in their ITT bids and their day to day IT Service Operations.
The development of ITIL into Version Three can only fuel the demand for ISO/IEC 20000 further.
To learn much more about ISO/IEC20000 why not download my free resources.
You can gain access to a free 65 minute audio briefing and PDF download.
Free Registration HERE.
The Lost World Of Problem Management
Karen Ferris' excellent article is here and it helps to uncover the lost world of problem management.
Karen points out, quite rightly, that many organizations think they are doing Problem Management when in fact they are managing major incidents.
So, if you think you know about Problem Management, have you got the answers to these questions ?
- What's the main difference between Incident and Problem Management ?
- What skills and people are required to run a great Problem Management function ?
- How can Problem Management ROI be demonstrated ?
Read the full article to find out for yourself (just you make sure you got the right answer ;> )
Download the Full PDF Here
Karen points out, quite rightly, that many organizations think they are doing Problem Management when in fact they are managing major incidents.
So, if you think you know about Problem Management, have you got the answers to these questions ?
- What's the main difference between Incident and Problem Management ?
- What skills and people are required to run a great Problem Management function ?
- How can Problem Management ROI be demonstrated ?
Read the full article to find out for yourself (just you make sure you got the right answer ;> )
Download the Full PDF Here
Labels:
itil v3
Dr ITIL's Diagnosis and prescription
Diagnosis Of Common issues Affecting Many Organizations Today.
"Firefighting", "too busy" and seeing repeat problems time and time again are all symptoms of a stressed or innefficent IT Service Management environment. Specifically, these include:-
*Stress - too many incoming problems generated by the production environment for the number of people available to handle the problems
*Innefficiency - correct amount of people available but those people are not trained/practicing best practice
*Lack of knowledge, appreciation and understanding - The people and teams who support the production environment are not structured correctly around the ITIL process descriptions, which are there to underpin the IT strategy (which should have a clear line of sight to the overall business strategy). The people lack experience in identifying multiple and/or repeat problems. The incident management process is not closing down and categorising incidents and known errors correctly - so you need to look further up the "food chain" to the Service Desk and level one support team operations.
Prescription.
1. Take the temperature down.
The goal here is to attack the worst offending problems first, eradicate some of them quickly and "buy yourself" some valuable thinking/planning time.
If you don't do this you will move from one fire to the next.
Some thoughts...
- Identify where the sources of pain are regularly coming from. Track the "Top 10" problems by impact on the business/operation and also by frequency of occurence. Produce these reports and trend them by week, month, quarter and eventually year.
- To do this effectively you will need to correctly label your problems by categorising them properly (severity / priority / impact / cost of occurence / cost to close down etc).
- Focus more support team activity on understanding exactly why these occur in the first place using true root cause analysis techniques. More people onto temporary assignments. Use overtime. Backfill 'regular' roles with temps. Create new "task forces" designed to attack these problems.
2. Make elimination a part of everyday life.
The goal here is to build into the day to day operation all those activities that need to take place to effectively DO Problem Management.
- Examine the Service Desk, Incident Management and Problem Management functions. Look at the flow of different types of incidents through these functions and (i) ensure that simple incidents are in fact resolved early on (say by the Service Desk), (ii) check that the incident management function is correctly categorising your problems. Without this the volume of problems being pushed through to Problem Management will always stay overbearing.
- Establish (if you have not already done so) a separate and independent Problem Management team. It should be independent from the Service Desk and all support teams. Give this function some 'real teeth' and management support. Empower the people who work in this team to "do whatever it takes" or "no door is closed" when assertively trying to eliminate problems from production. Enable the team to talk to and freely communicate with suppliers, internal support teams and managers to drive forward the Problem Management agendga. From this description you can see that strong communicators and relatively assertive people are best for this role.
- Track progress every day. "What gets measured - gets attended too". Publish daily, weekly, monthly and quarterly reports - not just on how many different types of problems you experienced - but what the teams did to prevent future recurrences.
3. Establish the continuous improvement mindset across the IT organisation.
- To deliver world class service, you need world class delivery processes/tools and most importantly people. It's people who make the ultimate difference.
- Hardwire the results and achievements of Problem Management (I.E. reduction of repeat and high impacting problems) into everybody's in-box, across IT, in the correct way.
- Help people understand how they "fit in" to what Problem Management are striving to achieve. E.g Project managers can deliver new releases with minimal (but known) errors and assist by improving future deliveries through improved testing and/or original build quality.
- Let all the project managers KNOW how their release did, say, for the first six weeks after the release. There are many more examples across the IT organisation.
* KEY *
- Recognise and reward progress. It's people that make service happen - not tools or technology. So make sure that management recognise and reward people for a 'great job' done. Afterall every problem permanently resolved means a cost saving to the business/organisation in some way. It also means that attention can shift to the next problem on the list. Recognition also reinforces the reality that Problem Management is vital and sends out the right message to other teams within the IT organisation.
THINGS TO AVOID
- "Hero" mentality. Too many people actually get a buzz out of firefighting and actually enjoy the adrenaline rush it creates! Watch closely the next time some major incident occurs. There are probably groups of people huddled over PC screens busily discussing the problem - often far more than should be involved. It's infectious and eats up a tremendous amount of the organisations time. Time is money. The "Hero" mentality also physically drains people (adrenalin effect) and they will often be troughing their performance level for hours if not days after a major incident.
- Upsetting the Technical folks. Technical specialists do not enjoy Service Management people wandering around and 'poking their noses in' where it's not really welcome. Problem Management have a tough job to perform - so it's vital that they strike up and maintain solid real-life working relationships with the other teams. Firm - but fair. The Techie folks should be subtly reminded each week/month (via reports) that if it was not for Problem Management then they would actually spend more time on repeat (boring!) incidents. So Problem Management must be seen as a benefit to the organisation/business as well as to the internal Service/support/techie teams. Having said all this sometimes you have to break down doors when the heat is on and this means being demanding and/or going over people's heads to get the job done. Be careful when Problem Management need to use these cards.
- Upsetting Suppliers. In the long run, most Supplier managers are agreed. You don't get anywhere 'bashing' suppliers with the perverbial stick. The best approach is (a) have sound contracts in place to fall back on [note - if you have to refer to the contract every incident - that's a sure sign that the relationship is in trouble!], (b) nurture true business relationships based on mutual respect and an understanding that you are trying to deliver the best you can for the same organisation/business and (c) People who have been previously bashed are far less likely to step-up and risk getting bashed again. I.E. You never know when you need a particular skills set or person in the future.
- Solving the whole organisations problems. The function is not the agony aunt of the business or the technology department. Ensure that Problem Management have a clear mandate and scope so that it is not used as a scapegoat for legacy issues/political agenda's that are found in most organisations. Keep the Problem Management team focussing on reducing business impact of repeat problems.
Bottom Line:- Problem Management is vital. It saves money. It prevents time wastage. It's difficult to set-up and establish. It needs the right kind of people working within it. Right skills, right knowledge, right level of authority.
"Firefighting", "too busy" and seeing repeat problems time and time again are all symptoms of a stressed or innefficent IT Service Management environment. Specifically, these include:-
*Stress - too many incoming problems generated by the production environment for the number of people available to handle the problems
*Innefficiency - correct amount of people available but those people are not trained/practicing best practice
*Lack of knowledge, appreciation and understanding - The people and teams who support the production environment are not structured correctly around the ITIL process descriptions, which are there to underpin the IT strategy (which should have a clear line of sight to the overall business strategy). The people lack experience in identifying multiple and/or repeat problems. The incident management process is not closing down and categorising incidents and known errors correctly - so you need to look further up the "food chain" to the Service Desk and level one support team operations.
Prescription.
1. Take the temperature down.
The goal here is to attack the worst offending problems first, eradicate some of them quickly and "buy yourself" some valuable thinking/planning time.
If you don't do this you will move from one fire to the next.
Some thoughts...
- Identify where the sources of pain are regularly coming from. Track the "Top 10" problems by impact on the business/operation and also by frequency of occurence. Produce these reports and trend them by week, month, quarter and eventually year.
- To do this effectively you will need to correctly label your problems by categorising them properly (severity / priority / impact / cost of occurence / cost to close down etc).
- Focus more support team activity on understanding exactly why these occur in the first place using true root cause analysis techniques. More people onto temporary assignments. Use overtime. Backfill 'regular' roles with temps. Create new "task forces" designed to attack these problems.
2. Make elimination a part of everyday life.
The goal here is to build into the day to day operation all those activities that need to take place to effectively DO Problem Management.
- Examine the Service Desk, Incident Management and Problem Management functions. Look at the flow of different types of incidents through these functions and (i) ensure that simple incidents are in fact resolved early on (say by the Service Desk), (ii) check that the incident management function is correctly categorising your problems. Without this the volume of problems being pushed through to Problem Management will always stay overbearing.
- Establish (if you have not already done so) a separate and independent Problem Management team. It should be independent from the Service Desk and all support teams. Give this function some 'real teeth' and management support. Empower the people who work in this team to "do whatever it takes" or "no door is closed" when assertively trying to eliminate problems from production. Enable the team to talk to and freely communicate with suppliers, internal support teams and managers to drive forward the Problem Management agendga. From this description you can see that strong communicators and relatively assertive people are best for this role.
- Track progress every day. "What gets measured - gets attended too". Publish daily, weekly, monthly and quarterly reports - not just on how many different types of problems you experienced - but what the teams did to prevent future recurrences.
3. Establish the continuous improvement mindset across the IT organisation.
- To deliver world class service, you need world class delivery processes/tools and most importantly people. It's people who make the ultimate difference.
- Hardwire the results and achievements of Problem Management (I.E. reduction of repeat and high impacting problems) into everybody's in-box, across IT, in the correct way.
- Help people understand how they "fit in" to what Problem Management are striving to achieve. E.g Project managers can deliver new releases with minimal (but known) errors and assist by improving future deliveries through improved testing and/or original build quality.
- Let all the project managers KNOW how their release did, say, for the first six weeks after the release. There are many more examples across the IT organisation.
* KEY *
- Recognise and reward progress. It's people that make service happen - not tools or technology. So make sure that management recognise and reward people for a 'great job' done. Afterall every problem permanently resolved means a cost saving to the business/organisation in some way. It also means that attention can shift to the next problem on the list. Recognition also reinforces the reality that Problem Management is vital and sends out the right message to other teams within the IT organisation.
THINGS TO AVOID
- "Hero" mentality. Too many people actually get a buzz out of firefighting and actually enjoy the adrenaline rush it creates! Watch closely the next time some major incident occurs. There are probably groups of people huddled over PC screens busily discussing the problem - often far more than should be involved. It's infectious and eats up a tremendous amount of the organisations time. Time is money. The "Hero" mentality also physically drains people (adrenalin effect) and they will often be troughing their performance level for hours if not days after a major incident.
- Upsetting the Technical folks. Technical specialists do not enjoy Service Management people wandering around and 'poking their noses in' where it's not really welcome. Problem Management have a tough job to perform - so it's vital that they strike up and maintain solid real-life working relationships with the other teams. Firm - but fair. The Techie folks should be subtly reminded each week/month (via reports) that if it was not for Problem Management then they would actually spend more time on repeat (boring!) incidents. So Problem Management must be seen as a benefit to the organisation/business as well as to the internal Service/support/techie teams. Having said all this sometimes you have to break down doors when the heat is on and this means being demanding and/or going over people's heads to get the job done. Be careful when Problem Management need to use these cards.
- Upsetting Suppliers. In the long run, most Supplier managers are agreed. You don't get anywhere 'bashing' suppliers with the perverbial stick. The best approach is (a) have sound contracts in place to fall back on [note - if you have to refer to the contract every incident - that's a sure sign that the relationship is in trouble!], (b) nurture true business relationships based on mutual respect and an understanding that you are trying to deliver the best you can for the same organisation/business and (c) People who have been previously bashed are far less likely to step-up and risk getting bashed again. I.E. You never know when you need a particular skills set or person in the future.
- Solving the whole organisations problems. The function is not the agony aunt of the business or the technology department. Ensure that Problem Management have a clear mandate and scope so that it is not used as a scapegoat for legacy issues/political agenda's that are found in most organisations. Keep the Problem Management team focussing on reducing business impact of repeat problems.
Bottom Line:- Problem Management is vital. It saves money. It prevents time wastage. It's difficult to set-up and establish. It needs the right kind of people working within it. Right skills, right knowledge, right level of authority.
Labels:
itil v3
What are the Critical Success Factors for ITIL ?
Much of what has already been written about ITIL is based on the premise that it's some kind of 'magic wand' or 'silver bullets' that will quickly improve and bolster an organizations service delivery capability.
Unfortunately, this ITIL consultant knows different.
Let's begin with a tour of the critical success factors for ITIL and I will highlight key considerations as we go.
The purpose is to quickly establish that implementing, running and improving an ITIL based service delivery organization is just as hard work, if not more, than one that has never been near ITIL.
The benefits, as we shall see, however make this all worth while.
Critical Success Factors for ITIL:-
- Proven best practices used by many top private and public companies that delivered results.
- It gives a good structure for the organisation as far as development of processes and procedures.
- Increased knowledge on the processes and systems across departments and offices.
Consistency in the use of processes and procedures.
- Better tracking, increased customer service, management control quality product and services
- Increased moral and better adaptation to change.
- Alignment to business need.
- Management and staff belief in ITIL vision.
- Required budget available.
- Plan that provides regular stream of wins during implementation.
- Building on existing practices rather than starting anew.
- Common terminology and definition of processes and functions is the primary success factor.
- Repeatability.
- No need to re-invent the process flow.
- Good base information.
- Clearly defining the processes.
- Monitoring the performance of processes.
- Reviewing and improving.
- Standardisation.
- Comprehensiveness.
- Relatively easy to understand.
- Adaption of common processes.
- Ability of an organisation to compromise and accept standards.
- Support from upper management.
- Establishing culture of service management.
- Ability to build and maintain configuration database.
- Understanding what your services are.
- Building a reasonable cost model.
- Understanding how the framework can be applied to your business.
- Reduce data duplication and redundancy.
- Improve process understanding.
- A foundation against which to measure.
- Buy in and tailoring Support from senior management/CIO.
- Training for all/most IT staff.
- Evangelise.
- Demonstrate to business the benefits of user pays.
- Do it better/ Do it cheaper than competitors.
- Management support from the top.
- Effective leadership and desire for improvement is fundamental.
- There must be a real, communicatable vision with the realistic timeframes set.
- A organisational change management program is essential.
- The business also has to be willing to embrace change and possess a holistic view of the benefits to be gained over the long term, not just immediate.
- The framework is there, it is best practice, you can talk to others about their experiences as it is.
- Cost savings.
- Service Continuity.
- Increased assurance is provided to the business that processes are in place to give an efficient and business focussed IT Service.
- ITIL describes very well the relationship between processes and brings an organisational focus to the work of individuals.
Unfortunately, this ITIL consultant knows different.
Let's begin with a tour of the critical success factors for ITIL and I will highlight key considerations as we go.
The purpose is to quickly establish that implementing, running and improving an ITIL based service delivery organization is just as hard work, if not more, than one that has never been near ITIL.
The benefits, as we shall see, however make this all worth while.
Critical Success Factors for ITIL:-
- Proven best practices used by many top private and public companies that delivered results.
- It gives a good structure for the organisation as far as development of processes and procedures.
- Increased knowledge on the processes and systems across departments and offices.
Consistency in the use of processes and procedures.
- Better tracking, increased customer service, management control quality product and services
- Increased moral and better adaptation to change.
- Alignment to business need.
- Management and staff belief in ITIL vision.
- Required budget available.
- Plan that provides regular stream of wins during implementation.
- Building on existing practices rather than starting anew.
- Common terminology and definition of processes and functions is the primary success factor.
- Repeatability.
- No need to re-invent the process flow.
- Good base information.
- Clearly defining the processes.
- Monitoring the performance of processes.
- Reviewing and improving.
- Standardisation.
- Comprehensiveness.
- Relatively easy to understand.
- Adaption of common processes.
- Ability of an organisation to compromise and accept standards.
- Support from upper management.
- Establishing culture of service management.
- Ability to build and maintain configuration database.
- Understanding what your services are.
- Building a reasonable cost model.
- Understanding how the framework can be applied to your business.
- Reduce data duplication and redundancy.
- Improve process understanding.
- A foundation against which to measure.
- Buy in and tailoring Support from senior management/CIO.
- Training for all/most IT staff.
- Evangelise.
- Demonstrate to business the benefits of user pays.
- Do it better/ Do it cheaper than competitors.
- Management support from the top.
- Effective leadership and desire for improvement is fundamental.
- There must be a real, communicatable vision with the realistic timeframes set.
- A organisational change management program is essential.
- The business also has to be willing to embrace change and possess a holistic view of the benefits to be gained over the long term, not just immediate.
- The framework is there, it is best practice, you can talk to others about their experiences as it is.
- Cost savings.
- Service Continuity.
- Increased assurance is provided to the business that processes are in place to give an efficient and business focussed IT Service.
- ITIL describes very well the relationship between processes and brings an organisational focus to the work of individuals.
Labels:
itil v3
Subscribe to:
Posts (Atom)
Posts
