ITILnews editor comment: Following the publication of an article on ITILnews we are pleased that one of out readers has decided to expand the article by sharing his experiences of working with ITIL in practice. I hope you find the response from Colin Mayers, an ITIL Manager, Red Badge certified professional, of value. Further information regarding Colin is found at the end of the article, Colin's comments are written in normal font and the text from the original article is in italics. Any questions you may have or assistance from Colin should be made via the email/comments facility at the foot of the article. As always we welcome all your comments and feedback and none will be published or forwarded without your permission.
I found the article referring to the global challenges very interesting and it was the trigger for some further thoughts that centred around Change Management, Governance and ITIL, and owing to the manner in which the thoughts were generated I thought the easiest flow would follow from dropping the comments around the original article.
During the current global economic challenges, expenditure is probably the most important focus of any organization.
I don't think that anyone would disagree with the above statement, however I would also suggest that value is currently viewed to be of equal priority by some organisations - as the times we are in are complete with competing pressures that include keeping costs down, achieving economies of scale and trying to get a little more for your dollar!
When third parties are involved this can feel even more difficult, as what appears to the purchaser to be a minor adjustment to the tiller invariably comes back with a cost for the work already done that requires settlement or agreement to, and that before work in the new direction, however slight, is taken.
So in these interesting times how do we focus on value too?
Assuming that we are following the ITIL Lifecycle approach then our Service Strategy should have already reacted to the business strategies especially in the areas of market development, financial management and the strategic risks.
The governance of the majority of economic expenditure within IT is performed primarily through the Change Management process. For clarity the definition of 'Governance' according to ITIL is:
Ensuring that Strategy and Policies are actually implemented, and that required Processes are correctly followed. Governance includes defining Roles and Responsibilities, measuring and reporting, and taking actions to resolve any issues identified.
Change Management is critical but I would also look to the Service Reporting of Key Performance Indicators (KPI's) and Critical Success Factors (CSF's) to assure that Governance is working along with the pure financial aspects of budget reporting, one of the surest signs of it not working within Projects or Change Management is scope creep leading to cost overrun. ITIL has always been strong on the need and value of Management Information Reporting and I think this is a prime example of where it is proven. It can also pay dividends to map out the meetings that carry a responsibility for governance, the levels at which they work and their escalation routes.
In mapping out the governance structure, an actual drawing showing the meetings and escalation paths can be extremely useful. If you further divide the drawing to show the management tiers of strategic, tactical and operational levels then the context of the meetings and structure becomes clearer still and that can further increase the usefulness. Well worth trying - believe me.
In my view, as well as authority levels and audit, Governance is also about the right information being available to the decision makers at the right forum. It is important to remember that some very large costs will be tied into and managed via projects and programmes and their internal change management processes.
The ITIL Change Management process provides the opportunity to access and ultimately authorize only those Requests For Change (RFCs) that meet the assessment criteria that is defined and enforced at that time by the organization. As part of ITIL all processes are subject to continuous improvement and the Change Management Process is no exception. Consequently the assessment criteria should be reviewed periodically to ensure it remains appropriate and current to the organization.
It should be remembered that the portfolio effect of a number of changes and/or projects that individually have come in within tolerances (usually +10%) can still have a dramatic effect. Changes should also be confirmed as aligning with Service Design in order to turn the strategy into portfolios of services that deliver in line with those strategies to both the organisation (business) and Information Services (IS).
During the current global economic climate it maybe worthwhile to review the assessment criteria and ensure the criteria to review the financial benefit(s) to the organization of implementing the RFC is undertaken for every RFC.
It is essential that IS based RFCs (those that IS have instigated) are couched in language that the business understand, especially where the risks of both doing and not doing the change are explained - in the end it is most likely to be their (the business) budgets that pay for it, and even more likely under the prevailing conditions.
The business case for business change and the quantification of benefits may be an area where IS are not the experts. Being close to the business and supporting them with sound information is a hugely important role, but, in my opinion, maintaining credibility is important too. Where you are not an expert in their business admit it, the business will see through you if you attempt to bluff whilst in their territory and then may doubt other advice you give them that is in fact good. It is a skill to be aware of what you do not know.
In cases where the change is IS instigated then ensure your business case and the expertise you use in creating it, is worded in business terms, or better still - plain English. Credibility is essential in keeping close to the business and attempting to pull the wool over their eyes will, if you are lucky and extremely good at it, work only a very limited number of times.
Upon assessment of the RFC it is found that the implementation simply provides a 'nice to have' result, then a considered decision to reject the RFC could be made. Every RFC has a financial cost implication associated to it and this is also a primary consideration when assessing the RFC, which is especially important during periods when budgets are being scrutinized and expenditure reduced where possible.
The Change Advisory Board (CAB), assuming that it is properly representative, should contain or be able to call on the most appropriate people to support them in understanding and making business based decisions, and if the RFC is one that has been initiated by IS, the affect of not proceeding may still become critical and that will affect IS's capability for supporting the business. So be honest with the business, in their language, get their backing for the change and through that the funding for it. This serves fundamentally to reinforce the importance of the Service Level Management type functions, where there are people who are truly close to the business and speak in their terms. On-going management and support of services are essential costs that are not 'one-off' and must also be considered and be approved by the business.
ITIL RFC Assessment Criteria
The following list provides assessment criteria which can be considered to all Requests For Change:
What impact the RFC will make upon the Customer's business operation
As mentioned previously IS may not be the best placed to judge business operations, but the sponsors of change and the business most certainly should be, by the time the change has been formalised into the RFC that level of information should be clear and if it isn't, there is nothing to stop the CAB from asking for it. Indeed many would believe that it is their duty to do so.
It is also worth considering that the business priorities may be biased by the area asking for the change - if in doubt over relative business priorities push back and upwards (escalate if necessary), ask, and when asking do so in business terms. The alignment with business strategies will help with identification of divergences.
Most organisations strategies for change pay lip service to the need for flexibility, this can be at odds with economies of scale, and fixed standards. Time taken to ensure that RFCs are not going to prevent future actions, leaving as many paths open for the future as you can will not to be wasted.
What effect the RFC will have upon the infrastructure and the Customer service as defined within the Service Level Agreement (SLA)
It is the duty of Change Management to protect the current production services, Business as Usual (BAU) and although the business functional areas will undoubtedly focus on their own particular lines of business, IS, through the Change Management Process and the impact assessments must take into consideration the IS services view from end to end.
The effect upon the capacity, performance, reliability, resilience, continuity plans and security of the Configuration Item (CI) to be changed
There is a cumulative effect of change in infrastructure terms; be alert to the need for a step change of supply, but also if that change is required it may be that the cost can/should be shared across a number of changes that have bought you to the threshold. In isolation one change that causes the threshold to be crossed is likely to appear too costly, whereas a number of changes that contribute towards the cost of the threshold and requirement immediately look more equitable.
Transition Management, Service Introduction, release management - all the current terms have an absolute duty to protect the current Production Services.
The impact upon other services including any current or planned projects
The Programme Management Office (PMO) should have already considered the opportunities for genuine economies of scale within the development environments by looking at their demand plan and where individual projects may be delivering products that can be used by other projects. Likewise they should have checked the Service Portfolio, especially the Service Catalogue to check if there is a service that already delivers a reasonable percentage of what is required.
Also the current IS Production infrastructure should be confirmed against the possible need of a step change requirement, which could in itself push the cost of the project beyond its' budget.
Impact on non-IT infrastructures within the organization (security, office services, transport, business Customer Help Desks)
The more broad the spectrum of attendees to the CAB the more likely it is that the non-functional requirements will be met.
The effect of not implementing the RFC
This is really an exercise in Risk Management, but it is very important that if you wish to get the business on your side that your risks are written up in terms that the business will be familiar with. If you can refer to the business strategies that the RFC would be supporting then this is better still.
IT, Business and other resources that are required to implement the RFC, the availability of the resources, anticipated costs, elapsed time and any new infrastructure required.
This is really referring to the 'Portfolio Effect' of the other projects and services that are in process at the time. Will you need to buy--in expertise, are there resources (human) that know the organisation and its ways and processes that will be available in the right timeframe? Is it more cost effective to wait for those resources? Are there projects that will free up infrastructure items that can be utilised? - Re-use.
Review against the Change Schedule (CS)
The Change Schedule (CS) has two primary and important functions, diagnosis and planning, for high level diagnosis, e.g. an initial quick check for the Service Desk to confirm when the CI or service was last subject to a change, and co-incidentally is that when the incident/s started happening. Guess we may suspect the change then!! The other primary function is to assist the planning process for Change and general Operations Management.
The management of the effect of finding that the dates of changes are going to contend is easier the further away from the scheduled implementation date you are. The Law of Diminishing Returns that applies works along the lines that given 6 months notice it is easy to manage expectations, given 6 weeks notice and the hassle factors have risen enormously, given 6 days and/or hours notice and the rise in inconvenience and blood pressure is exponential, and more importantly, it is also avoidable!!
Additional ongoing resources required if the RFC is implemented
Whatever is implemented into the 'Production' environment will require an infrastructure or some components of an existing one on which to run and in service terms it will require to be managed, maintained and reported on. This is true whether or not the service is bought-in or managed in-house.
It would be good if all projects and programmes either delivered the complete set of processes and procedures for on-going management or confirmed that the existing ones were appropriate. Checking is a resource requirement, but if the processes and procedures do not exist then the resource requirement associated with the RFC will increase dramatically.
In the present economic climate it may be a good time to add a new or revised service as described above, for a supplier to manage at little additional cost on the basis it will make their service better value for money, it is the time that those considerations are uppermost in many peoples (and financial directors) minds.
Another consideration is to review the previously authorized and in-flight 'significant' or 'major' RFCs, more often than not managed as projects, which in reality are simply large and complex changes.
Criteria by which the projects were initially assessed may have changed due to the economic climate and therefore consideration should be made to re-access the previously identified benefits of the project and whether or not they are still able to be recognized or achieved. If following the re-assessment the benefits have changed considerably then a decision should be taken as to whether to stop or suspend the project until such time the benefits can be realized.
This is really a repeat of comments about the Programme Management Office made earlier, when considering the benefits of an RFC it is valid to consider the potential for economies of scale or the fact that there is already a team doing good work to give you leverage for further work without the overhead of recruitment and team building time? It can also be that if a project was implementing some complex processes and or procedures that doing so at a time when transaction rate is low will lower the risk of implementation.
If you have additional advice and guidance to offer and prepared to share then please contact us.
About the author:
Colin is a committed Service Management professional who enjoys his work, he is qualified as an ITIL Manager (Red Badge), a Prince 2 Practitioner and an ISO 20000 Internal Auditor and Consultant and has been contracting his services to private and public sector organizations for the past 10 years.
Colin's career has seen him deliver and manage operational services and processes ranging from SLAs, OLAs and Service Catalogues to policy documents for the entire range of ITIL disciplines. Colin's current experience being focused on the service and service management being delivered by his client organisations suppliers, where he works directly to the Head of Supplier Management.
CV available on request, simply make your request via ITILnews, who receives no financial gain from such requests.