An IT partnership with 'the Business' is now found to be a fundamental requirement of most medium to large organizations today. The knowledge of IT has grown within the user / customer base to the extent that the 'mystic of IT' does not wash so well as it did in the eighties. The astonishing growth in IT D.I.Y. experts (Do It Yourself) may well have contributed to the fashionable phase of 'outsourcing'. A phase closely preceded by the intimate examination of IT costs by financial 'whiz kids', who wielded the unscrupulous scalpel in an attempt to drive costs down without adversely affecting service or 'the Business'. It could be argued in some cases achieving short term wins at the expense of medium term business objectives.
Whatever the history 'the Business' always demand from IT a consistent service level, all that IT are required to do is supply it. Well if it was only as simple as that!
The IT / Business relationship often reminds me of the magician (IT) at the kids party who as part of his act, decides to demonstrate his 'plate spinning' skills. Beginning slowly with two or three and gradually growing to seven, eight, ten plates (services). Before he is running around like a headless chicken just trying to keep all the plates spinning and the audience (the Business) satisfied. Eventually the audience become bored or just for fun ask if he can juggle as well (broom)!
Understanding 'the Business' and IT requirements has, in some cases, spawned the Account and Relationship managers, allowing invaluable communications to be kindled between both parties. The next logical progression has been the creation or revision of Service Level Agreement(s) (SLA), and their associated Service Catalogue(s). The SLA and Service Catalogue provide the opportunity to clearly define the roles responsibilities and requirements of each party and associated services.
Having established a human or 'in your face' relationship between IT and 'the Business', documented and agreed each others requirements in the form of SLAs and Service Catalogues we should be home dry - No such luck. Sure 'the Business' confidence with IT has improved, marginally, as they now understand what IT requirements are. The question being asked is why have the Service Levels not significantly improved? The answer could lay with Change Management.
Change Management should not be confused with the group of 'Dr Marten gum-chewing thugs' who wonder IT departments, chastising every individual who raises a Request For Change (RFC) and forgets to enter the correct extension number in the non-mandatory field.
ITIL Change Management is a culture that every member of IT plays a part in, and not something simply resigned to the Change Management department. RFCs come in all shapes and sizes and in the majority of occasions it is the skills and experience of the relevant departments (e.g. Technical Support, Application Support etc.) within IT who are able to assess the RFC, decide whether it is practical, provide some idea on how many man hours / days are involved and prioritize accordingly. Some inevitably become full blown projects with the necessary authorization from those who are empowered with the purse strings, budgets and resource allocation. No doubt such projects will generate their own RFCs.
If the RFC is successful in passing the assessment and authorization stages it then begins the build stage. The build should not only undertake the construction or development of the Request For Change but should also consider and define the Implementation plan, Back-up requirements prior to the implementation taking place, and subsequent Back-out procedure in the event of the change being unsuccessful.
The RFC then moves into the Test stage where the build is proven and honed. The Test also provides the opportunity to prove the Implementation, Back-up and Back-out plans. Once the Test has been completed satisfactorily the RFC can then be scheduled for Implementation in accordance with the Change Management procedures.
The scheduling involves reviewing all RFCs planned for a particular date and ensuring that any interdependencies are high-lighted, prioritized or even re-scheduled. All proposed Implementation plans should include details such as, at what point the Implementation should commence, the duration of each of it's stages (if applicable) together with who is responsible per stage. In addition, checkpoints should provide the opportunity for the Back-out plan to be invoked thus preventing the RFC from 'drifting' and entering a stage of fait accompli where damage limitation becomes the prime objective.
Having obtained the agreement for the RFC to precede it now enters the Implementation stage and in theory should now enter the 'live' or 'production' arena seamlessly. Once completed the RFC enters the post implementation review stage, where lessons learnt can be adopted and thus allowing for the continuos improvement of the change processes within IT. Finally, the RFC can be closed.
The Missing Link
The Request For Change process specified above lends itself well to that stated in the Change Management chapter contained within the IT Infrastructure Library. As a consultant I have had the opportunity to visit many blue-chip organizations and more often than not I have found the Change Management processes to be over complicated and on some occasions over engineered.
I believe there is a missing component within the Request For Change process which could, if introduced, increase the success rate of the majority of RFCs that are currently Backed-out. The component is Verification. The verification component or process is introduced into the RFC at the Build stage. The verification should be clearly defined and include each expected result as it is followed. Ultimately it provides the opportunity to not only confirm that the proposed change has been successful, but that it has not had any untoward or detrimental effects on the remaining service, system or infrastructure.
As before the Build then enters the Test stage where the Verification process can also be tested and refined accordingly.
Once the Implementation plan is completed the Verification process provides the opportunity to prove whether or not the RFC has been successful, if the Implementation is found to be unsuccessful then the Back-out can be invoked. Following the implementation of the Back-out the Verification process should again be invoked but this time minus the change(s) as specified in the RFC, thus ensuring the integrity of the service, system or infrastructure prior to the customer or user community having access.
As the verification process evolves, normally as the result of the post implementation reviews, a standard set of verification processes can be defined and maintained. The duration of the verifications can be accurately calculated in advance and factored into the overall Implementation plan. Primarily without the formal verification processes IT is allowing 'the Business' to provide the verification, to decide the success or failure of an RFC during the 'online' or 'production' day, as agreed and specified within the SLA and Service Catalogue. An identified failure by 'the Business' affects the confidence in IT but ultimately, it affects the bottom line of the balance sheet, either due to lost production, lost customers to competitors or both.
Wherever possible 'the Business' should be encouraged to be involved and provide verification for certain high or major impact RFCs, as part of the Implementation plan. The advantages are two fold, not only is IT able to obtain appropriate verification from 'the Business' but it also helps to build relationships and ultimately partnership and support. One word of warning the whole of 'the Business' will never be available for verification purposes outside of the SLA hours, therefore the ultimate verification from a capacity perspective may well reside within the 'online' or 'production' day.
If you decide to introduce the verification process or simply formalize something that may already exist, then I believe you will reap the benefits.