Implementing Effective Change Management

Change is inevitable in any organisation; and with change comes risk. When one actively stops to think about change, one can be surprised at how big a part it plays within IT operations, ‘Run the Business’ as well as the ‘Change the Business’ function. Whether it is reactive to resolve errors or to adapt to changing circumstances; or proactive to provide new services or functions to increase performance; or to reduce costs or increase efficiency.

Such change is generally a good thing; however, as far too many organisations have learned, uncontrolled or poorly managed changes can (and probably do) lead to business-affecting incidents and problems. Thus they need to be closely managed to minimise exposure to risk, to minimise disruption, and to ensure success at the first attempt. Hence, given the potential gains from its adoption, a formal Change Management system (of policies, processes, procedures, and technology) is often lauded as a top priority for IT organisations. However, its implementation isn’t easy or, more precisely, implementing effective Change Management isn’t easy.

Whilst many might consider formal Change Management processes and procedures overly bureaucratic, it is relatively easy to quickly formulate a list of the issues caused by the absence of a Change Management process, or a poorly designed or deployed one – the main one being the adverse impact of change-related incidents on business operations (the unexpected and unwanted side-effects of deployed changes). Beyond this, even though one can’t help thinking that this is reason enough for the introduction of ITIL-based Change Management, an organisation is still subject to the risks and impact of unauthorised changes, rush jobs to deploy poorly planned changes, the inability to back-out changes, rush jobs to deploy fixes (or even fixes of fixes), and change scheduling conflicts.

The lack of effective Change Management within an organisation can also be a major stumbling point in corporate IT governance and compliance initiatives, particularly the inability to consistently demonstrate that change requests are approved and prioritised by appropriate owners, there is appropriate segregation of duties between all key elements of the change management process, critical changes can be tracked and escalated as needed, change impact is appropriately assessed, and audit trails are sufficient to meet the requirements of both internal and external scrutiny.

From an IT Service Management (ITSM) perspective, Change Management is one of the lynchpins of the IT Infrastructure Library (ITIL) best practice framework. Sitting within ITIL’s Service Transition quintile, it is defined as the process that ensures that standardised methods and procedures are used for the efficient, prompt, and successful handling of all changes. Its importance can be demonstrated by the fact that it is often one of the first processes implemented as part of a green-field ITIL implementation – with common implementation starting points either Incident and Change Management, or Configuration and Change Management – and that it is the second most implemented ITIL process (after Incident Management) in both v2 and v3 adoptions.

There are obviously financial benefits associated with minimising the volume and business-impact of change-related incidents and problems but effective Change Management also enables greater visibility and collaboration, supporting the ultimate aim of achieving the ITIL and ITSM Holy Grail of IT-Business alignment. The financial benefits, in the main, relate to the avoidance of costs associated with lost IT service availability such as the business cost of business-critical service downtime (reduced productivity or lost revenue); or the IT costs of dealing with associated incidents and problems, backing out the change or deploying change fixes, or on-the-fly code fixing. However, another which cannot be understated is the business cost of delays to important or mandated changes.

Beyond these top-level financial benefits, the business case for the introduction of ITIL-based Change Management should also include those associated with improved visibility, control, and speed. These include greater understanding of the change pipeline and the ability to handle a greater volume of changes, the communication of the Schedule of Changes to interested parties, a stage-gate approach to change approval, and prioritisation and fast-tracking through the use of Change Models and a purpose-built Emergency Change process. Finally, business-wide collaboration benefits offer the opportunity for better cost, risk, and impact assessment, and improved change prioritisation and scheduling.

From a practical perspective, it is not always necessary for an organisation to reinvent the wheel with ITIL-based Change Management – most organisations have some semblance of control over IT change even if informal, inconsistently applied, and lacking sufficient documentation – and to facilitate adoption it should build on these existing practices wherever possible. It should cover the Seven ‘R’s of Change Management – who ‘raised’ the change; what are the ‘reasons’ for the change; what is the ‘return’ required from the change; what are the ‘risks’ involved with the change; what ‘resources’ are required to deliver the change; who is ‘responsible’ for the build, test, and implementation of the change; and what ‘relationships’ exist between this and other changes? Beyond this, it should be a documented, repeatable, and scaleable process, facilitated by technology that provides capabilities to monitor and manage change progress, collaborate across functional barriers, measure performance, and identify opportunities for improvement.

Importantly, any Change Management initiative needs to be supported by top-level business backing such that there is a single, business-mandated Change Management process which applies to everyone and every change, with no exceptions – no matter who you are or who you know. In addition to this, Butler Group recommends that Change Management is driven through policy, which explicitly states how changes should be processed within the organisation, by whom, and by what method. With technology-enable workflows that move the change through the process, from Change Request logging and recording through categorisation and prioritisation, evaluation, approval and scheduling, implementation, and Post Implementation Review (PIR).

It is imperative, however, that an IT organisation, pursuing effective Change Management ensures that it has placed sufficient consideration into the avoidance of common Change Management pitfalls. The toughest and the most frequent of these is making the cultural change required to support the effective utilisation of the new Change Management process and enabling technology. As an extension of the already mentioned top-level business support, everyone within the organisation contributing to, and/or impacted by changes needs to be signed up to the diktat of a single, enterprise-wide Change Management system for the production environment (as a minimum). To this extent, the relative weight of the Change Management process is vital, and an over-bureaucratic process will not only stifle adoption but also its operation.

An IT organisation will also struggle to deliver effective Change Management without first ensuring that a robust management framework exists to support it. Firstly, business and IT ownership is key – specific people (or roles) need to own IT and business services, and the applications and infrastructure that deliver them where ownership is not just a title, but alternatively the ability, inclination, and authority to provide information and make decisions in the context of their charges. Without this, change impact assessments and scheduling, in particular, will be at best sub-optimal and at worst, dangerous to the enterprise.

Some semblance of Configuration Management is also vital to the success of any Change Management process, allowing not only the correct owners to be identified and consulted but also the necessary level of configuration item understanding (both individually and in the context of relationships) to ensure that risks are minimised through the comprehensive assessment of change impact. Finally, and importantly, the IT function needs to continually remember that they are not dealing with IT change; they are dealing with business change.

In terms of implementation best practice, getting the organisational approach right is critical. Before setting out on the journey to effective Change Management, senior management needs to fully understand and appreciate why the business needs it. As with the adoption of ITIL as a whole, Change Management should not just be introduced as a good thing to do; alternatively, it needs to address specific business issues or pain points.

Importantly, an organisation must also recognise that Change Management is not just the introduction of new processes and enabling technology; that alternatively, it is an organisational change which needs to be communicated to all levels within the organisation and bought-into by the key stakeholder groups affected by the delivery of change. Importantly, everyone within the organisation needs to understand that the corporate Change Management process is mandatory, with no exceptions, and best practice suggests that employees are made fully aware of the reasons for, and impact of the new Change Management system before it is ‘used in anger’ – maximising the opportunity to avoid resistance.

So where should an organisation start once focus, top-level support, and business mandate are in place? Butler Group recommends that an IT organisation starts with policy – developing, agreeing, and then communicating enterprise-level Change Management and Release and Deployment policies which explicitly state how changes should be processed within the organisation, by whom, and by what method.

Within this, an organisation needs to define various elements within the Change Management ecosystem: what a change is and the types of change that will fall within the remit of the new Change Management process. This should be followed by the creation of a Change Management process that both supports the policy and, importantly, is aligned to the organisation’s needs across the various areas of change initiation – such as requirements for new application features, security imperatives, demands for increased capacity, or incident and problem-driven fixes.

In dealing with different types and origins of change, an organisation should ensure that it benefits from the use of Change Models and technology-enabled workflows which predefine the way in which a particular change type should be handled. Common examples are Pre-defined/Pre-approved Change/Release, Standard Change, Non-Standard Change, and Major Incident Change. Emergency changes are inevitably needed but policy and process should ensure that these are both kept to an absolute minimum and managed differently, particularly in the level of approval and control.

An organisation must also not miss the opportunity to baseline the ‘as-is’ state before starting the transition to the desired future state. Without this baseline data it is nigh on impossible to fully quantify the benefits realised from the introduction of the new way of working – IT should be able to communicate the step change in Change Management performance as well as the ongoing, incremental improvements identified through the utilisation of Key Performance Indicators (KPIs) and Critical Success Factors (CSFs). Such ‘success stories’ will be vital in demonstrating the value derived from formalised change control in the context of the increased ‘pain’ of accommodating the additional internal controls, particularly in the early life of the new Change Management system. Ultimately, it may take time for the organisation as a whole to fully appreciate the benefits of the enforced formalisation of change.

However, even with the required Change Management ecosystem in place, there are also operational areas of best practice to consider. Firstly, not all changes were born equal. This is not just the fact that some applications, infrastructure, or IT services are more critical to the business than others, it is also that an analysis of Incident and Problem Management data, if available, or customer perceptions if not, will identify the areas of greatest business-impact caused by previous change failures. These problematic applications, infrastructure, or IT services should be short-term areas of focus to help ensure compliance with the new way of working and, more importantly, to maximise the benefits realised from the new Change Management system. It might be necessary to take action both within and outside of the Change Management process, such as focused monitoring of enacted changes (relative to authorised changes), additional education for offending individuals or IT groups, or even removing their access to the affected components.

Leading on from this, organisations need to realise that most change failures are people failures – whether it is an unauthorised security patch or failure to follow agreed work procedures that results in a business-affecting incident or problem. As with any other instance of employee negligence or deliberate failure to follow agreed processes, the IT organisation must make it clear that such behaviour is unacceptable and if consistently displayed, that it will be addressed through disciplinary action via agreed Human Resources-supported procedures. This will also need to be communicated as part of the overall transition, as part of a culture of personal and role-based accountability.

The knowledge, skills, experience, and capabilities of the people filling key Change Management roles are also critical. IT organisations should use the ITIL (or elsewhere-provided) guidance on Change Management roles and responsibilities to ensure that they slot in the right type of employees. Taking the Change Manager role as an example, a balanced mix of organisational, negotiation, communication, and analytical skills is required. Importantly, having the ability to see the bigger (business) picture and to repeatedly say ‘no’ when necessary is required for the benefit of the business.

Finally, in the area of operational best practice, the Change Management process stipulates the requirement for PIRs and an organisation should not view this final stage of the process as just a bureaucratic add-on that can be avoided to save time. Alternatively, it should use the reviews to not only identify what went wrong but also what went well; feeding findings into the ITIL-promoted Continual Service Improvement process to enable the ongoing improvement of change delivery across the enterprise.

Originally published on www.ovumkc.com

Functional Parity In The IT Service Management Support Tool Market

Over the last six weeks, as an input to an (Ovum) Butler Group Technology Evaluation and Comparison Report, we have spoken to ten major IT Service Management (ITSM) tool vendors regarding the functionality and capabilities offered by their solutions.

Something that became obvious early in the process, even though somewhat expected, was the extent to which ITSM tools have achieved a level of functional parity on the back of the continued worldwide adoption of the IT Infrastructure Library (ITIL) ITSM best-practice framework. In Ovum’s opinion, this levelling of ITIL-supporting functionality and capabilities raises many additional questions for organisations seeking to procure an ITSM solution.

While not a bad thing, functional parity does make one think about the commoditisation of ITSM tools on the back of, or indeed in the support of, the commoditisation of IT (or IT services) and wonder where true innovation can be found within the ITSM tool arena today. Traditionally, choosing an ITSM tool has been a difficult task complicated by many factors including the fact that different ITSM solutions support different ITSM processes to different degrees. This issue is disappearing but is being replaced by some new ones.

Thankfully, an IT organisation looking to procure a new or replacement ITSM tool can leverage external commentary from IT analysts or seek evidence of a solution’s level of ITIL-alignment from third parties such as Pink Elephant (the PinkVERIFY assessment scheme) or the more recent Office of Government Commerce (OGC) ITIL Software Endorsement Scheme. Interestingly, Ovum is observing far greater communication of achieved PinkVERIFY certification, in particular by the ITSM vendor community, and considers it a sign that this parity of functionality across core ITIL processes is changing the way in which ITSM solutions are presented to potential client organisations, with the support of core ITIL processes no longer enough.

The third-party certification of some or all of the 14 core ITIL processes should give IT organisations a head start in determining whether a particular vendor solution is capable of delivering the functionality required to support its required set of ITSM processes. There are of course product differences at a functional level, be it ease-of-use or a clever way of achieving a particular ITIL process requirement, but the certification does provide an assurance that the vendor solution is ‘fit for purpose’ when considered against a generic ITIL-based process. However, the certification cannot be viewed in the context of an organisation’s particular (although probably not unique) way of working, and given that ITIL adoption should be driven by people and processes, it is the technology that needs to adapt, not the other way around. Therefore, the certification, while extremely useful, is not enough to confirm applicability.

Beyond the delivery of core ITIL-based capabilities, however, many vendors have their own unique selling point or points to differentiate them from the pack. This is usually their own particular slant on, or flavour of, ITSM innovation. For instance, IBM takes a business view extending asset management to all business assets and supporting business service management, Service-now.com offers value for money and convenience through what it terms ‘modern Software-as-a-Service’, FrontRange offers additional ITSM efficiencies through telephony integration, and both CA and HP offer the benefits of true service portfolio management capabilities through their Project and Portfolio Management solutions.

In Ovum’s opinion, the fact that many ITSM products have achieved this functional parity around the support of the core ITIL processes means the product selection bar has been raised, or at least skewed. Whereas before, a request for information or request for tender might have easily separated out potential winners, it is now far more difficult to differentiate between the leading ITSM vendor products based on functionality alone. Client organisations will also assess standard criteria such as inter-process integration, interoperability with existing IT and management software, technical requirements (including performance, security, and resilience), total cost of ownership, supplier background (including product assurance, and financial stability and reliability), implementation parameters, and support and maintenance arrangements.

Beyond this is where an ITSM vendor will try to differentiate itself in the context of delivering innovation in its products and services. Therefore, a procuring organisation must ensure that the promised innovation will actually deliver against a corporate need, rather than being a ‘nice to have’ and, importantly, is not favoured above the primary reason for tool selection: seamlessly supporting ITSM processes.

Originally published on www.ovumkc.com in October 2009

SaaS and ITSM – a Marriage Made in Acronym Heaven?

In the last two years, both Software-as-a-Service (SaaS) and Cloud Computing have gained much publicity and vendor backing, and a growing corporate acceptance with SaaS, in particular, viewed as an immediate opportunity to quickly, and flexibly, deliver business-enabling IT services at lower cost. The drivers around speed, flexibility, and cost have similarly focused CIOs on the use of IT Service Management (ITSM) processes and IT Infrastructure Library (ITIL) best practice in the pursuance of IT service delivery optimisation. However, the question now being asked is ‘Can SaaS and ITSM be used in tandem to deliver even greater business value?’

Whilst a definitive definition of SaaS is still elusive given that, as with Cloud Computing, everyone has their own particular take on what SaaS is and the term is used somewhat excessively, most readers will hopefully recognise the SaaS-delivery model as one that involves applications hosted, maintained, and updated by a provider which are accessed (as a service) by subscription-paying customers via the Internet; and in this context, the ITSM tool market is rapidly filling with SaaS-delivered solutions from SaaS-only vendors, traditional ITSM vendors with SaaS-versions of existing ITSM offerings, and new dual-play vendors.

This lack of clarity of definition has caused some confusion between SaaS and its logical precursor, the Application Service Provider (ASP)-delivery model – the remote provision of an application through a traditional licensing and annual maintenance payment model. The distinction between the two models is important, however, when understanding how SaaS can deliver substantial benefits over on-premise tools but also how it avoids the pitfalls that ultimately led to the downfall of the ASP model.

The confusion between SaaS and ASPs is understandable, with the ASPs of the late 1990s essentially offering what SaaS vendors do today: the provision of hosted applications delivered over the Internet. However, the ASP model equated to little more than the transfer of application purchase and support costs, activities, and risks from the client organisation to the ASP, for a price, with the ASP burdened with the legacy costs of maintenance, support, and upgrades. The applications themselves were not designed for Internet-based delivery and often precluded the economies of scale necessary for ASPs to operate in a cost-effective manner. The loss of venture capital availability after the dot-com bubble had burst just sealed their fate financially. However, post ASPs, the success of SaaS Customer Relationship Management (CRM) vendors, such as Salesforce.com and RightNow Technologies, has demonstrated both the possibilities and the benefits of the SaaS-delivery model within the corporate arena.

This article does not dive down into the complexity of SaaS-variants such as SaaS 1.0, 2.0, and 3.0, or the single-tenancy versus multi-tenancy debate, or terminology such as Hybrid SaaS. It does, however, assume a perspective that views enterprise interest in SaaS-delivered ITSM solutions in the context of replacing already deployed on-premise ITSM applications – a viewpoint that is also used by many vendors to calculate the Return On Investment. Moving from on-premise Product A to SaaS Product B rather than determining the underlying benefits an organisation would realise from utilising their technology to support ITSM processes and procedures.

The market penetration of SaaS ITSM tools is still extremely low compared with on-premise tools; it is, however, a rapidly growing market segment both in terms of customer interest and vendor entry (or re-entry for traditional vendors offering a SaaS-version of existing tools). No reputable market size information is available, but Butler Group has watched with interest as Service-now.com, the largest SaaS-only ITSM vendor, has grown its annual subscription revenue from US$6m in 2007, to US$14m in 2008, to close its 2009 financial year at US$28m – US$3m ahead of expectations in spite of the current financial climate (although some would argue that it is because of the current financial climate). Vendor confidentiality prevents like-for-like comparison with sales of traditionally sold (and delivered) ITSM software, but Butler Group believes on-premise ITSM tool revenues to be stable at best.

However, SaaS vendors are not just riding on the back of the global recession. An oft-quoted industry figure is that, on average, organisations change their ITSM tool every five years, and whilst the effect of the current financial climate on this statistic is unknown, Butler Group is seeing greater attention placed on the overall cost of providing ITSM-related services and increased consideration made before an organisation will commit to the cost and inconvenience of upgrading an existing ITSM tool. Vendors are also reporting that customers are still readily switching between ITSM tools – archiving rather than porting historical transactional data across – with some clients viewing SaaS a low-risk, potentially tactical solution in the knowledge that they can readily return to an on-premise solution (with the existing or an alternative vendor) if needed.

In Butler Group’s opinion, after the functionality and capability additions necessitated by the move from ITIL v2 to v3 in 2007, the SaaS-delivery of ITSM-enabling capabilities is the biggest shift in the ITSM product landscape in the last five years. Of the many benefits to be realised (from the adoption of a SaaS-delivered ITSM tool), a critical one is aimed directly at the heart of the now common overstretched IT function – given that a SaaS-delivered ITSM tool should only require a Web browser and an Internet connection to function – no client to install, no hardware to support, and nothing to upgrade locally – scarce IT resources can be redirected away from IT-internal systems to focus on the delivery of business-critical IT services.

For many organisations, however, the key benefit of SaaS is its simple, subscription-based pricing model – usually a cost per month (or year) per user that covers everything needed to operate including support and maintenance – that provides a lower and consistent level of expenditure which is OPEX rather than a CAPEX investment. This simplicity of pricing can also be viewed from a value-for-money perspective, in that a per-seat subscription will usually cover access to capabilities across multiple ITIL (or ITSM) processes rather than the traditional need for organisations to buy multiple licences across multiple ITSM products (or modules), giving an organisation the freedom to continue its adoption of the ITIL framework over time without additional cost.

The third main benefit is also cost-related – the effort and associated costs required to achieve ready-to-use status for the tool. Whether it is the time to initially deploy (and thus to start to realise value from what is a significant IT investment) or the upheaval involved in upgrading to the next release of the application. Along with the potential to reduce the Total Cost of Ownership (TCO), SaaS tools also promise a significantly quicker time to deploy (and to value) and effortless upgrades (at least on the customer’s part).

It is worth noting at this point that the lack of clarity over the meaning of SaaS can cause problems for procuring organisations. Whilst the transferral of the application, hardware, and support and maintenance activity to the vendor and a better TCO scenario are relatively ‘black or white’ issues, there is an area of greyness to traverse related to the technology that sits behind the ‘vendor curtain’. In Butler Group’s opinion, a SaaS solution must be architected such that the customer is able to self-customise its ‘application instance’ (to reflect in-house processes), with these customisations preserved through what should truly be an effortless upgrade process. Without these facilities, the SaaS business case is not so compelling.

SaaS-delivered ITSM tools should also offer high levels of scalability and security, with the latter a key area of SaaS vendor focus, along with availability, given their standing as two of the early barriers to SaaS-adoption. Two additional areas require customer scrutiny – an ITSM tool’s ability to integrate with existing ITSM and IT Management tools and the level of vendor stability (given that not all vendors are experiencing the 100% per annum revenue growth of Service-now.com).

Jumping back to the ITSM side of the equation for a moment, the ITSM tool marketplace has somewhat levelled-off in terms of the functionality and capabilities delivered in support of individual ITSM processes, driven by the direct matching of the technology to ITIL-based requirements (although different vendor products continue to support different sets of ITIL-based processes). Whilst this is good in that differing vendor products are comparative on a process-by-process basis, it has also moved much of the business thinking around tool adoption away from direct functionality to indirect functionality (such as security), ease of implementation and associated time to value, the quality of professional services, the upfront and ongoing cost of ownership, the ability to customise, integration facilities, analytics capabilities, and the complexity of product upgrades. This is by no means a bad thing, but be aware that it can potentially lead to a technology rather than a process-driven ITSM tool deployment. Ultimately, SaaS-delivery should never be the primary reason for procuring a particular ITSM tool.

Butler Group recognises that SaaS-based ITSM tools will not be suitable for all organisations, for a variety of reasons, and that the difficulty of integration between a new ITSM tool and existing ITSM and IT Management tools is not confined to SaaS solutions; but there is another potential downside to consider. A SaaS subscription provides access to a wealth of ITSM functionality and capabilities. However, if viewed as an ‘all you can eat buffet’ it could prevent organisations limiting themselves, at least initially, to a few of the modules that address immediate business pain points, resulting in a ‘rushed’ approach to ITIL adoption that is potentially ill-fitting with the organisation’s level of ITSM maturity and capabilities.

In conclusion, Butler Group believes SaaS-delivery to be a good fit for ITSM tools; especially given that, with a phased implementation, it can be a relatively low risk environment for introducing both SaaS and ITSM into an organisation. Enterprises are now far more aware of the benefits and risks of SaaS and, with the continuing influx of SaaS-delivered solutions from SaaS-only vendors, traditionally on-premise ITSM vendors, and new dual-play vendors, Butler Group expects SaaS-delivered ITSM tools to continue to erode the market dominance of their on-premise siblings.

This article was previously published on http://www.ovumkc.com