2-Speed ITSM

5837174879_ce6a5e647c_z-2IT and ITSM are at a crossroads, where they are being pulled in several directions. On the one hand there is high demand to speed up, be innovative and engaging, yet they must also ‘keep the lights on’ and protect the IT assets of their organisations and customers.

With the spread and complexity of technology and searing the pace of change, most IT organisations need to wake up to the fact that they can’t do both of these things. They really can’t do it all, certainly not with old legacy organisations based around 80s and 90s technologies and structures.

So, how do we manage to solve the ‘2-speed’ dilemma? How can we deliver new innovations and speed up our delivery times, whilst still delivering value through accountable, sustainable and robust systems and processes? We need to respond more quickly and with ‘agility’, yet we also need to do the basics of e.g. ITSM well – and better than they ‘ve been done before.

How can IT departments re-invent themselves? Its difficult for many IT people in large or heavily process driven organisation to appreciate some of the ‘new’ concepts like ‘DevOps’ – since this has been effective and valuable to new thrusting and entrepreneurial companies – particularly in the technology sector. It’s a far cry from a cool Cloud start-up in the Bay area to a local council in Sheffield, or a long established insurance company in Merseyside.  Of course all organisations differ in terms of focus and maturity but at some point all companies and enterprises will face the challenge – that many are already facing – of how to balance safety and security with energy and speed. Those that don’t face the challenge will lose competitiveness, or cost effectiveness, or both. The 2-speed dilemma is here to stay.

Whilst there are many current challenges – there are also several opportunities that can tune 2-speed ITSM into win-win ITSM.

So what do we need to do? Here are some key points:

  • Focus has to be on business outcomes and customer experience, which can then help to define key IT elements and services that are needed to support these. In order to do this properly we need to engage with our customers and define and map our services in terms of supply chain and value chain – ie who does what, where are the costs and real ‘nuggets’ of IT value.
  • The discovery work required in defining these ‘services’ will also identify areas where there is the opportunity for cost reduction, automation and improved speed of service, via removal of administrative tasks – e.g. things like request management, equipment ordering , provisioning and procurement.
  • The key is how to prioritise – if we can’t do everything ourselves (and most IT organisations can’t) then we need to use automation, delegation and multi-sourcing to take care of commodity and time-consuming work in order to be able to focus on strategic and high-value work.
  • There are now many excellent tools that can provide this and which also meet the millennial generation’s requirements for more self-determination and automated interaction – e.g. self logging, self-healing. Many outdated, slow and costly processes and bottlenecks can be replaced with slick, automated ordering, approval and provisioning tools that run quickly and efficiently at a fraction of the current cost.
  • Also, many traditional ITSM tools have been transformed as collaboration tools using ‘social’ type interfaces. As a result there has been a significant increase in the use of these tools in back-office service areas beyond IT – e.g. HR, Finance, Marketing, Legal. There has been a consolidation of portals and catalogues for all of these areas into a single functional interface – which has been made possible by the improvement in User Interface and simple configurability of these tools.
  • Significantly this is enabling IT departments to become positive ‘can-do’ enablers and solution providers, rather than the isolated and non-communicative ‘guys in the basement’ from the past. The challenge to engage and the opportunity of new technology have combined to offer IT the change to re-invent itself…
  • Finally there is also a more mature and ‘joined up approach’ to managing the various lelves of outsourced or multi-sourced services that IT departments (and other teams through shadow IT) have evolved into managing. Multiple Service Integration and SIAM (Service Integration and Management) are emerging as new mantras for IT organisations to use to finally get control and also deliver business value.
  • This requires some re-thinking and refreshing os skills and roles – with more commercial focus and relationship management required.

IT is now effectively a supply chain business and part of its evolution involves growing pains – this is a great time of opportunity for IT and those that grasp this and see the future will definitely cement their place in it.

Image Credit 

Transforming User Experience – 6th March, London

The ITSM Review are holding a free seminar in central London this March entitled Transforming User Experience – Enterprise Service Management and Self Service, which will help to address this subject. For more information click here

Renovating Your House of Change Management

No Laurence Llewellyn-Bowen probably won’t be paying your change process a visit, but he certainly won’t “thwart the juices and desires of the great interior design public (or change managers) at large” whilst undertaking your change renovation project
No Laurence Llewellyn-Bowen probably won’t be paying your change process a visit, but he certainly won’t “thwart the juices and desires of the great interior design public (or change managers) at large” whilst undertaking your change renovation project

In my inaugural article, I talked about how aligning the change management processes – from capturing customer demand at the beginning; through project delivery; and implementation to the production environment – is important for us to be able to understand, plan for, adapt to, and deliver our customers’ needs whilst balancing quality, control, and conduct effective operation of our services.

Quite a heavy opening paragraph especially given that doing all these things can be a challenge!

I also, suggested you might want to work with what you have, which in many cases, might be “change control” i.e. assessing, reviewing, approving and implementing changes to the production environment.

It is on this basis, that I would like to share with you my thoughts and experience surrounding production-related change including things like CAB (Change Advisory Board) and assessing and risk and impact.

If you recall, we undertook a complete re-launch of process to become the “change governance framework” which included significant alterations to the way change control worked in practice.

Using Your Existing Tools – No need to knock down the walls!

Our Service Management tool – like many I’ve heard anecdotally before – wasn’t fit for purpose and was the “bane of everyone’s existence” according to many people I spoke to.

The first thing I did was undertake the entire journey of raising, assessing and approving a change ticket in the tool. Using the Systems Thinking (Vanguard) check model approach to “flow” was particularly helpful for focusing on the end-to-end process objectively as well.

In all honesty, there were not many screens to follow and completing a ticket was reasonably quick and trivial to do. However, the challenges I discovered were

  • that the level of detail in the assessments ranged from copious text to practically nothing
  • it took ages to get approval from the relevant person
  • a copious amount of change tickets were open – in many cases for several months

As part of the workshop activities I mentioned in the previous article, we utilised the wider Systems Thinking (Vanguard) check model to identify a considerable amount of confusion, waste work and failure demand (the ability to do things right the first time).

What we identified was that the process and lack of understanding of the tool were largely to blame rather than tool itself. Sure, it wasn’t perfect but it was what we had.

Succinctly, the changes that took place involving the tool included:

  • introducing a series of questions for people to complete when creating a change request rather than guessing what to put down for their assessments
  • the agreement with all change approvers that the change manager would have day to day approval for minor i.e. non-CAB changes in order to speed up the approval process
  • publishing the change schedule via the existing digital signage and making it available to all IT staff on large plasma screens so they were aware of what was occurring on a given day
  • integration of a “risk and impact” calculator that scored the risk, impact and change category – particularly helpful when knowing whether a change needed to go to CAB or not – by popular demand, a template is below

Risk & Impact Calculator to download from OneDrive

FSC fsc1

Questions to consider – pick a colour!

One of the biggest requests I had from people in response to their queries about how to improve their risk and impact assessment, was what questions did we expect people to complete. Whilst I can’t provide an exhaustive list, you might want to consider developing a script based upon the following question set:

  • What is this change?
  • What are the high level implementation steps and back out plan for this change?
  • When do you plan to implement this change?
  • What is/are the benefit(s) of doing this change?
  • Has this change been tested both technically and by the customer?
  • What resources are involved in the change?
  • Has this change been implemented previously?
  • Have you sought the relevant technical, service and customer authority for this change?
  • Has the relevant documentation been created or updated and handed over to the relevant support team?
  • Have you communicated the details of this change to the relevant people?

CAB – what do you mean it’s not a taxi?!

As glib as the section title sounds, in some cases a Change Advisory Board in my experience has ranged from being a thorough, technically detailed meeting for several hours to a mere minutes ‘tick box exercise’. From either extreme, I’ve seen people have their changes needlessly rejected for trivial details or have simply bypassed the process altogether as they feel it adds no value.

My tips for having an effective CAB include:

  • Make sure you have the right stakeholders (including your customers, if appropriate) in the meeting to make effective decisions
  • Consider having senior managerial presence in the meeting to give it credence – if management do not respect the meeting, you can’t expect others to.
  • Have a clear and precise agenda and stick to it. Getting bogged down in every detail suggests the change isn’t ready to be approved or that the meeting isn’t working effectively.
  • Consider having a companion technical authority meeting or process for change to be reviewed before CAB. It can help with the above point.
  • The Change Manager needs to be an effective chair to ensure process is being followed but more importantly keeps the meeting moving without becoming a “talking shop”
  • Ensure the right changes come to CAB – this is perhaps the most important point as adding additional bureaucracy and process will likely be counterproductive and you may miss the critical change that ends up causing a major incident!

Summing Up

The best way to renovate your existing change management process, is fundamentally to

  • Not be afraid to look at your process from a fresh/external perspective but not to simply ‘paper over the cracks’
  • Use what you can with your existing tool – remember, it’s cheaper to apply a new coat of paint than to knock down walls.
  • Make sure CAB is delivering and adding value
  • Make sure there is a change schedule available and people can see it – think of this as your “feature wall”


Image Credit – “Laurence Llewelyn Bowen” by Andy G from Hazlemere, United Kingdom

Enterprise Service Management – Enabling Value Delivery Outside IT

The lines between departments are often blurred and requests can be passed around or come to a complete standstill

Enterprise Service Management – Enabling Value Delivery Outside IT is a guest post by Darroll Buytenhuys, Chief Operating Officer at Samanage


In IT we often forget this, but we aren’t the only department that provides internal services within an organization.

HR, facilities, legal, finance, purchasing, sales, marketing, administration and other departments all deliver services to other areas of the business outside IT. Business processes flow across these services, so anything that can be done to make the flow smoother can benefit business productivity. Anything that hinders these processes hinders business.

So what prevents people in the business from getting the help they need from other departments? It’s often quite simple. It’s in not knowing where to find the help they need.

Is it always clear who does what in the business? The lines between departments are often blurred and requests can be passed around for a while before they land on the right desk. The process stalls.

The second common problem is the “black hole”. You call Tony in facilities to request assistance with an office move. He says he’ll get back to you in the next hour. Nothing happens. The process stops dead.

We’ve all been there and it’s very frustrating. Having more clarity on which departments perform which specific functions (e.g. internal enterprise services) helps to optimize productivity.

Most departments are aware that they need to operate more efficiently, but few are aware that they also need to interact more efficiently (mainly because their internal metrics don’t tell the full story of their performance in the broader context of the business). No matter how well a department operates internally, there is usually plenty of room to improve the way it handles demand from other business units. Most departments don’t think of themselves as an enterprise service domain.


The Enterprise Service Challenge

The IT end user community is not exclusive to IT. They’re also the end users of other departments’ services. It’s one big enterprise community, so from the end user’s perspective, it doesn’t make sense for each service department to have a different web portal. When you have a number of departments providing internal services to the same end user community, it makes more sense to create a centralized digital portal that exposes the services of all of these business units. A one-stop-shop for all of your enterprise service domains will reduce time spent looking for help and increase business productivity across the board.  

Think about the end user’s perspective. In a day, a member of your enterprise community might:

  • Request a password reset from IT.
  • Ask HR how many vacation days they have left, and book a day off for the following week.
  • Report an issue with the office air conditioning to Facilities.
  • Request the company’s annual accounts from Finance.
  • Ask Administration for help with booking a flight and hotel for a customer visit.

In most organizations, these requests will happen via phone or email, and the responses are probably dealt with on an ad-hoc basis, with no defined process, supporting automation or approval workflow. Even if the request doesn’t get lost, it certainly won’t happen efficiently and within a predictable timescale. Successful outcomes in these situations are underpinned by the work of a few individuals. By contrast, IT has a web-based request system, well defined execution processes and software tools to automate them. Everything is logged. Nothing gets lost. Responses are of a consistently high quality and happen within a predictable timeframe. Successful outcomes are underpinned by the quality of the system (a combination of people, processes and technology).


An Opportunity to Enable Value Outside IT

The IT department has an opportunity to show other service domains the way to a higher level of maturity – from ad-hoc manual processes that deliver “minimum viable service” to a streamlined service management system that communicates and operates in a more efficient manner.  In organizations where IT has got service provision right (implementing processes that actually get results for IT customers and creating a digital interface to streamline response to day-to-day demand), employees may be wondering why they can’t interact so easily with enterprise service domains outside IT. As a department that has been there and done that, there’s an opportunity for IT to help other departments by implementing the same principles that have worked for IT.  Unfortunately and all too often, IT is handicapped in its ability to assist in the enablement of improved service management by their legacy service desk technology.

The vast majority of service desk software products in use today date back 2-3 decades and require a heavy dose of professional services and IT support to build and maintain the required processes.  IT is reluctant to take on these additional responsibilities, knowing that all other departments will require substantial support to deliver benefits to their constituents.  IT also knows that if the support is not excellent, they will hurt rather than help these departments — and IT will be left with egg on their face.

The recent entry into the market of fleet-footed, agile SaaS companies, delivering service management solutions that are implemented in days, if not hours, by non-IT people, is allowing IT to become true champions of the service management cause.  This frees IT up to support these departments by sharing service best practices:

  • Thinking in a more customer-oriented and service-oriented manner.
  • Managing what the department does as a portfolio of services.
  • Monitoring changes in demand from the business – and responding accordingly with new solutions.
  • Focusing on the service user experience and how services generate optimized value with minimal friction for end users.
  • Defining and automating good processes which deliver the right outcomes efficiently and consistently.
  • Making it transparent: articulating what they do and how they do it. Keeping service consumers informed about progress.
  • Setting service-level agreements and providing feedback on performance.

IT has both the know-how and potentially the technology to support the implementation of service management best practices in other enterprise service domains within the business. By applying what they know about managing service portfolios, process automation and support outside IT they can help streamline the way other business units operate and interact. By improving operation internally, the business unit becomes more efficient. By improving interaction with other departments, business operations become more efficient.  And, with today’s SaaS applications, all of this can be built and maintained by the business units without costly professional services.


Darroll Buytenhuys is Chief Operating Officer of Samanage.  Darroll has over 30 years experience in sales, marketing and general management in the software industry. Most recently Darroll was a Senior Vice President and Officer of BMC Software (NYSE BMC). Darroll joined BMC as a result of the acquisition of New Dimension Software where he was the president of the North American operation and was also the company’s worldwide COO. New Dimension Software was an Israeli company (listed on NASDAQ) and its $800M acquisition by BMC was at the time the largest ever acquisition of an Israeli software company.

The ITSM Review are holding a series of seminars this year headed by ITSM superstar Barclay Rae. We will be starting in March with Transforming User Experience – Enterprise Service Management & Self Service. For more information click here

Image Credit

Practical Ways to Eliminate Alert Fatigue

Tips to avoid Alert Fatigue

In March 2014, US Retailer, Target revealed that its security software had detected its now infamous data breach five

months earlier, and that at least eight IT employees had seen the threat alert but decided not to act on it.  Some commentators jumped on the firm for its apparent incompetence, but security experts say its reaction was pretty normal.

So how and why do data breaches, equipment failures and disasters go undetected by humans when the monitoring systems are doing their jobs? The constant stream of alerts can cause engineers to check out, a syndrome that some refer to as ‘alert fatigue’.

Reacting to this influx of alerts uses your engineers’ time and resources, costs money, and can prevent your IT department from playing a more strategic role at your company.  This article will explore four actions that you can perform now to address alert fatigue.

Here are the four recommended actions.

Action One: Plan

You could think of a notification model in four levels of maturity, listed here from least to most mature:

  • Level 1 – reactive
  • Level 2 – tactical
  • Level 3 – integrated
  • Level 4 – strategic

IT is complicated enough.  Your IT tech people and engineers receive a stream of notifications that range from innocuous (someone has accessed an asset or logged into a system) to important but only to certain people (a project has achieved a milestone) to urgent (a server is down or security has been breached). Responding – or even reacting – every time a notification comes up can be time-consuming and irritating.

Do the work on the front end: Plan for alerts, escalations and automated processes for different scenarios to make sure your intelligent communications work well.  The system must have every stakeholder’s contact information, device preference, schedule and commitment to be available. You must build this in advance of an emergency.


Action Two: Automate

Suppose your business experiences a power outage.  A full-scale emergency will require a series of manual instructions and emails to the IT team, engineering and everyone whose business and safety may be affected.  However, you can still automate some important features, alerting first responders, letting purchasing know you need new servers, and even cutting off power to the server room.

What about more limited incidents, such as an employee laptop failure? Once the incident is recorded, the engineering tech replacing laptops receives an alert, a step that can be automated, and the employee can receive an automated notification that a fix is in progress. What if the employee reports the issue after hours?  Do you alert the tech on a mobile device, or can it wait until morning? If you plan your processes well, you can automate every step based on the urgency of the incident.

Time is critical, especially if you are servicing employees in global offices, as some employees are losing valuable work time. That could mean sales opportunities missed or incomplete timesheets.  Based on urgency, location, time, each person’s preferred device and work schedule, you can automate whether to alert engineers right away or wait until the morning. Depending on the rules in place, the message can be sent two ways: automatically triggered by the event, or at the push of a button, usually by the IT lead.


Action Three: Be Proactive

Another important function for efficiency is the enablement of easy status updates. IT techs frequently experience disruptions from answering queries on the status of an open ticket. Whilst it’s understandable that customers want to know the status of outstanding events, IT techs would rather be resolving issues than answering enquiries. Status updates send automatic messages to clients with expected time to resolution.

Proactive communications don’t have to be just for incidents. They can let employees know of impending software updates, let customers know of enhancements, or let an employee know a new laptop has been ordered and is on its way. The proactive alerts can ease the minds of the recipients, whilst freeing IT leaders from such enquiries.


Action Four: Target

A good way to enable your engineers to avoid alert fatigue is through targeted alerts, as alerts go to the subset of employees who need to know either to take action or to simply be in the know.  You should also target alerts by preferred device, so IT techs receive notifications where they’ll see them and respond. A good way of doing this is with subscriptions, enabling stakeholders to subscribe to relevant alerts and unsubscribe from others. When you combine automation, targeted alerts and subscriptions, you create more efficient alerting processes to help support IT Service Managers and IT departments.


With these recommended actions you should be able to drastically reduce the number of alerts received and help to restore some energy into your alerting.


Image Credit

Keeping Up in an On-Demand World

Fostering good relations with business counterparts is a good place to start

It’s a fact that business user expectations of IT continue to grow in today’s tech-heavy consumer culture. In a world where we can get access to new capabilities and services quickly in our personal lives, it’s no wonder that business leaders are seeking the same continuous delivery of new capabilities in their work lives.

Here are five tips that will help you adjust your culture and tooling for this era of on-demand IT.


Tip 1: Take notice of the level of collaboration between your company’s business unit managers and the IT department

Ask yourself, is either side pleased with the situation at present? I’ve seen companies invest in roles within IT to foster improved collaboration with the business (e.g. what ITIL calls Service Managers or what Gartner and others call Business Relationship Managers). This is a useful investment for IT organizations to make because it gives a focal point to work with the business, someone who can sit in executive meetings to understand what needs they have and problems they are trying to solve. In a lot of companies the CIO still tries to act as the “relationship manager” for every business unit and sometimes also the head of development tries to do so – these approaches just don’t scale effectively.


Tip 2: Do something every quarter to improve communication and collaboration between non-IT managers and the IT department

Standing still in this area means that communication and collaboration is likely eroding. Both the business and IT sides of the house are moving so fast that it requires a proactive communication and collaboration to maintain alignment. I hear a lot of CIOs talk about the need for an “open line of communication” with other departments and that’s a good mindset, but it’s not enough. We have to move beyond appealing to better communications and the need to align with the business. The question you should be asking is “what are some concrete actions I can take now to improve communication and collaboration between non-IT managers and IT?” One idea is the creation of relationship manager roles as mentioned above. Investing in good quality IT relationship managers and aligning up front on project scope is critical.

But even with that in place, challenges for communication and collaboration will persist. For example, if you’re relying on the relationship manager to translate and explain the business needs to those in IT who need to know about what the business is trying to achieve, the priorities, etc. there can be some big communication gaps because not everyone who needs to know gets the information, or, the business needs are changing so rapidly and people in IT are working with outdated information about business requirements. What’s needed is an ongoing dialog between not just the business and IT relationship managers, but also with project managers, developers, and even those in operations that need to deploy and run the applications.

There’s a lot IT can learn here from enterprise collaboration projects in the business (with products like Jive) and apply that to how IT works with the business. Imagine if the people working on the project in IT could “follow” and collaborate on business requirements with the business like you follow someone on Twitter or have a friend on Facebook. Followers could get updated as things change and engage with the business if there are questions or concerns. Maybe the development manager draws a cut line for the release and the business knows about that in advance and can give feedback on features that need to be added or confirm which others can wait. Perhaps there’s a policy that governs an app but operations isn’t aware of it and is going to deploy it in such a way that they would violate the policy – instead the enterprise governance team can know about it and weigh in before the deployment happens.


Tip 3: Revisit the tools and approaches you use for IT collaboration work today. Be intentional about your go-forward tools strategy

The challenge I see here (a lot) is that IT is still using the same techniques they’ve always been using for collaboration – meetings, emails, conference calls, sharepoint sites, spreadsheets. There is no substitute for meetings and face-to-face interactions and even conference calls are important, however, the challenge is how do we capture and disseminate that information so those in the meeting can refer back to it but ensure others that weren’t in the meeting can still have access to it? What about someone new joining the organization, how can they get up to speed faster without having to go to lots and lots of meetings?

IT needs a new way to think about how we capture knowledge and make it available to people in the context of the work they’re doing so they don’t have to go hunting for it on sharepoint sites, send out lots of emails, search knowledge bases etc. In effect looking for the needle in the proverbial haystack.

What we need in IT, and which we have been lacking, are cross-team workspaces. An area you could bring together the right people with the right tools and information in a workspace that was defined around the context of the activity that needs to get done – whether that’s a development project, an infrastructure upgrade, an incident that needs to be resolved, etc. And then help facilitate the team making the necessary decisions and documenting the actions that will be taken – while also notifying everyone who needs to know.


Tip 4: Accept that complexity is increasing and that your people are key to managing it not just automations

IT environment complexity is a major issue for many companies because their systems have now been linked together so that the user community can move from one system to the next easily and so that data is quickly passed between systems. So now when change comes in it can affect how multiple systems work together. As IT practitioners, we’ve been working so hard to support the business all these years and we now have a collection of lots of legacy stuff and new technologies and it’s all been woven together in a way to help the business as fast as possible.

There’s a lot we’d change if we could go back and do things over, but that’s just not practical, and so for the most part we need to work with the environments we have. The challenge is how do you understand all these integrations, relationships and dependencies, all the tribal knowledge that’s been built up in the IT organization over the years?

There have been several approaches to address this like Configuration Management Databases (CMDBs) and discovery tools, and they help, but they raise their own issues. First, there’s only so much that discovery tools can discover off the wire. They do a decent job of telling you how things are configured and relationships between them but they still miss a lot because they have to be programmed to find “patterns” and there’s no way they can discover things like policies and how those govern your assets.

The other big challenge for discovery tools is that they don’t capture intent – i.e. why things are the way they are. That’s tribal knowledge that’s in your people’s heads. Someone at sometime knew why SAP was configured that way or why a certain port was opened on that server or switch. The problem is that tribal knowledge isn’t well documented, it gets lost as people forget it or leave.

The complexity problem is really a tribal knowledge problem. What we need is a living, breathing CMDB, think of it like a “social CMDB” that leverages discovery tools but then uses crowd-sourcing and peer review, like Wikipedia, to validate what’s been discovered and fill in gaps on an ongoing continuous basis. Until we have this, IT is going to be very resistant to the pace of change the business wants, because we’ll be concerned something might break that we weren’t expecting.

This is another area where you can apply the cross-team workspace concept. The idea of not only capturing the tribal knowledge and continually validating the CMDB but then pushing that information forward in the context of planning a change or resolving an incident. So if people are following the things in the IT environment that they care about, when it comes time to work on a change, the right people can be brought together in a shared workspace (instead of guessing who to involve like in traditional change process management) and arm them with the right information and tools to provide their risk assessment. That way, when the change board goes to review the planned change, they know who’s been involved and what information they had access to and can feel a lot more confident about their decision and approve the change a lot faster to keep the business moving forward.


In summary

The fundamental business-IT challenge in a lot of companies is that the business is simply frustrated with the pace at which IT moves. Fostering good relations with business counterparts and investing in relationship managers as mentioned above is a good start. But having the business engaged in a shared workspace for projects they care about, giving them more transparency into the project and decisions being made about cut lines for releases or the like, will give them a greater sense of ownership and appreciation for the work we do in IT and how it’s not just ‘there’s an app for that’ in an on-demand world.

Image Credit

The ITSM Review are holding a series of seminars this year headed by ITSM superstar Barclay Rae. We will be starting in March with Transforming User Experience – Enterprise Service Management & Self Service. For more information click here

ITSM Evolution – Practical Steps to Stay Current

Using ITSM Tools can be like rummaging through a garage full of old tools that you rarely use in order to find one or two tools that you do
Using ITSM solutions can be like rummaging through a garage full of old tools that you rarely use in order to find one or two tools that you do

ITSM Evolution – Practical Steps to Stay Current is a guest post contributed by Dirk Anderson, Head of Product at RedPixie


With the growth in BYOD and the consumerisation of devices, more and more enterprises are adapting the way that they use technology to service the business effectively.   However, many ITSM tools have been designed to give traditional IT teams a way to manage traditional services and processes at a component level only, whether that’s processing tickets or responding to an individual end-user request.  The challenge, however, is whether or not ITSM evolution is possible and demands of the business can be met using the current tools at our disposal.

Today, firms need to ask themselves if this type of service level approach, using legacy methods, can flourish, or even survive in the future. This article will look at the practical steps that we’d recommend IT Service Managers consider, to deliver services that address the needs of the internal ‘business customers’ in a dynamic business environment, where user expectations are more demanding than ever.


Step 1: Know your customers

As a matter of course, you should already be undergoing customer satisfaction surveys or have appropriate forums for regular dialogue with your internal business customers. Use these forums to gain an appreciation of how your customers do business today, what IT services they use and what may change in the future. It is likely that:

  • Your business will be using more personal devices and business customers will expect to access corporate applications and data securely from those devices
  • Your business customers will be embarrassed if their business partners and guests cannot easily use your enterprise guest wireless whilst they’re visiting
  • Your business customers will expect to work effectively from wherever they are
  • They will expect to walk to another desk or meeting room and instantly access the IT services, applications and data at those locations

Expectations are changing. It’s important to explore these areas, and never shy away from hearing frustrations. Canvas their views on new service capabilities that would improve their experience and help them be more productive.


Step 2: Pay attention to your IT service portfolio

Look at the IT consumer services that you provide, and break them into categories. There is high chance that you will have one category (and call it what you prefer), has a large percentage helpdesk tickets that are similar. This means that “your consumers” repeatedly need to consume these same critical services. These include: resetting passwords or removing software on end user devices. It is important that you automate these services and allow the business to self-serve. This will free your team up to focus on the emerging services that need to become part of your service portfolio. As you add those new services, some may fall into this same category. Consider how automation and self-service capability is applied to those emerging services.


Step 3: Evolve ITSM Toolkit to Meet IT Service Goals

As you evolve your service portfolio, how well does your current ITSM toolset fit your strategic needs? It is important to evolve your ITSM toolkit to meet your longer term IT service objectives. Can you easily add common cloud services and can you automate and allow your consumers to self-serve?

In larger enterprises, you should think like a public cloud provider. You provide the capacity and the technologies and your customers help themselves to the most common services, without the IT team’s involvement. You should focus on managing areas such as, overall service capacity, the software license position and the development of your service portfolio. Commonly used or repeatable IT services should be available to your customers to help themselves, in the way customers consume Microsoft cloud services, for example, without the need to involve Microsoft’s Cloud IT support team. If your ITSM toolkit does not support that strategy, then you need to consider replacing or adding to those tools, to support a more strategic focus. That may mean looking at new ITSM capabilities that augment existing processes and tools to deliver “new world” capability within your service portfolio.


Step 4: Review and measure

As your service evolves, make sure that you have a continuous review cycle in place with an internal business customer group.  It’s important to measure not only how the service portfolio fits the changing needs of the business but also whether your ITSM “toolkit” allows you to shape your service around your changing business. The following are critical:

  • Know your service portfolio – To measure the services that you provide as an enterprise IT team, be clear on the portfolio of services provided. It starts with a list of those services, typically on a web portal explaining clearly what the services are (and are not). The portfolio needs an overall owner, typically a senior IT head, and the individual services require service owners, such as IT line managers. This list of the services requires ongoing maintenance.
  • Manage the service portfolio – Work with business representatives and senior IT stakeholder to ensure that the portfolio remains manageable. As new services are used, you need to be able to remove other services, unless the business is willing to fund you to support an ever-growing and unsustainable portfolio.
  • Measure the service portfolio – Develop a way to measure your portfolio. This needs to include which services are used by whom, and the level of consumption. Undertake a Service Review, and work with the business to get feedback on the quality of those services. Understand the cost of providing those services, relative to their business value.
  • Build a Governance Function – Be open and discuss the importance of not creating a technical debt because of a “bloated” portfolio. You only have so much capacity as an IT function. Consider building a senior governance function to support the integration of new technology capabilities whilst removing non-strategic services and technologies.

In summary do everything you can to know your customers, understand your changing service portfolio, be aware of current limitations in your ITSM toolkit and evolve it for emerging demands, and lastly, proactively review and measure.


Image Credit

Change Management: Responding to a Crisis

Keep Calm...
Keep Calm…

One of the things that isn’t covered as much as it should be is how to respond to a crisis directly linked to Change activity. This is one of those things where despite your Change process, despite your sparkly toolset and fab policies & work instructions, something has gone pear-shaped on a massive scale and you’re staring down the barrel of a Change Management related crisis.

Here is my guide to dealing with the fallout, without having to resort to mainlining chocolate or vodka.


Step 1

Keep calm! Easier said than done I know (and believe me, I know) but panicking or making reactive, snap decisions won’t help things and might actually make them worse. Take a deep breath, roll up your sleeves and get stuck in.

Don’t believe me about how panicking can make things worse? A couple of years ago, I was working on a client site in Milton Keynes. This client had a financial system for each EU country that was accessed by a command line interface. One fateful Wednesday, the German financial system experienced an issue and the tech support guy had to run a fix script and restart the system. The Service Delivery Manager for Germany, in her infinite wisdom, thought that standing over the poor techie (we’ll call him Bob) and shouting at him would speed thing up. It didn’t. What actually happened was poor Bob typed the command for rebooting the UK system rather than the German system onto his console, taking out all transactions for the UK and doubling the impact of the Incident. Not our finest hour I think you’ll agree.

Step 2

Get a handle on where you’re at. Is the Incident still on-going? First and foremost, look after your people. Is the environment safe? Are there any imminent hazards? Chances are Incident Management or Problem Management are running with the drama, or if it’s really serious, a Crisis Manager or IT Service Continuity management. Regardless of who is running with the fallout, you need to play a supporting role in helping them understand what the Change was meant to do and what went wrong. Hopefully, you already have a documented process for invoking the help of Incident Management if a Change fails with documented roles and responsibilities. If there’s nothing in the process for what happens if a Change fails spectacularly, then step up and help co-ordinate the fix effort. You can look at lessons learned, the chain of command and who sorts out what later on, once the immediate danger has been contained.

Step 3

Figure out who’s going to handle comms. Not just the generic Service Desk e-mail but depending on the magnitude of the issue, you may well have to communicate with:

Don't let things go from bad to worse
Don’t let things go from bad to worse

(1) Angry customers

(2) Angry stakeholders within your business

(3) The press

(4) Regulatory bodies.

Make sure only authorised people speak to the relevant parties so that you don’t make an already bad situation worse.

As a general rule, I think that for internal reporting, the more detail the better. This will help you understand what went wrong, how we fixed it, could we have done anything differently and what we can do to stop it from happening again. Internal reporting will cover exactly what happened, the technical details and if there was any human error. For external customers; all we need to cover is what went wrong, how we fixed the issue as quickly as possible, were there any opportunities for Continual Service Improvement (CSI) and that we have taken the appropriate action to prevent recurrence. Basically, saying that the engineer booted in daft mode isn’t something that will every look acceptable in the eyes of most customers.

Step 4

Have we got a fix? Test, test and test again. Check and double check anything that goes out to your customers. First things first, have we got the right people working on the fix and do they have enough support? If not then work with your peers to get agreement that as it’s a crisis situation, break – fix work must be prioritised. Support your technical teams by helping them get the Emergency Change raised and if appropriate, setting up an E-CAB. Every organisation is different and for some, the paperwork can be raised retrospectively so there is no delay to implementing the fix. Either way, to save time, your Emergency Change probably won’t be as detailed or nicely formatted as a BAU Change request but should at least have:

• The nature of the work

• Who is carrying it out

• How it’d been tested

• Linked Incidents

• How it has been verified and how we can prove it has fixed the issue

• Who’s authorised it (even if it’s a senior manager shouting JFDI make a note of it on the Change)

• Any customer communications

Let your customers & stakeholders know when the Change is due to be implemented then send out a second communication once the Change has gone in, the Incident has been resolved and all is well.

 Step 5

Ensure safety and security...do not let the post mortem meeting turn into a witch hunt
Ensure safety and security…do not let the post mortem meeting turn into a witch hunt

The post mortem; aka the Incident Review, Change Review or drains up session. This is not, I repeat, not a witch hunt. Co-ordinate your review activities with Incident & Problem Management. The last thing you want is for your guys to be stuck in 3 separate meetings, answering the same questions just being asked in slightly different ways. Set ground rules and reassure everyone in the room that the meeting is to look at what happened and how it can be prevented from recurring, not to assign blame, At this point I use something called my umbrella speech to get everyone in the room to relax. I won’t bore you with a big wafflely speech but the gist is something like the following:

“ I just want to understand what happened. Think of me as your umbrella. I ask all the difficult/ horrible/controversial questions so that you’re not getting interrogated by senior managers or irate customers. You can trust me because you know me, we’re all in the same team plus we’ll all be going down the pub together for a stiff drink once this is over.”

Getting people to understand that they’re in a safe environment is hugely important. If your guys feel supported, then an honest, constructive conversation can take place to understand the root cause, short term fix actions, long term fix actions and anything else that could prevent recurrence.

Step 6

Follow up with customers and stakeholders. This isn’t a one off activity, on the day of the crisis; you may find yourself in hourly meetings to keep senior management or customers updated. Once the issue has been resolved, you can issue a short holding statement that explains what happened and the actions being taken to stop a repeat performance. The next step is important. If there are lots of post Change / Incident / Crisis actions, commit to regular updates in an agreed format. These updates could be in the form of updating a Problem record or a weekly update e-mail or a Service Improvement Plan depending on the magnitude of the failure.


Frazzled people require pizza
Frazzled people require pizza

Step 7

Look after your people. Chances are, they’re tired, stressed out and frazzled from working all hours to put things right. Now is the time for that trip to the pub or a morale boast in the form of caffeine, chocolate or pizza.

Step 8

Look at your FSC. Are there any similar pieces of work planned that need to be cancelled, reworked or rescheduled? How are you going to reassure your customers that lessons have been learned and the same mistakes will not happen again? As a Change Manager, you need to ensure, that if a similar piece of work is planned in the future, it has actions present in all stages of the implementation plan to ensure the issues you’ve just sorted out don’t come back to haunt you.

Sometimes, the most appropriate action to take is to delay the Change as a good will gesture to give the customer additional time to communicate to any of their onward customers or to take additional steps externally to mitigate risks. I’m not saying it’s always the right thing to do, or the easiest thing to do but sometimes a little time and breathing space can work wonders.

Step 9

Lessons learned...
Lessons learned…

Remember your lessons learned. When you had your post mortem you will have come away with a lovely long list of actions to make this better. I know it’s easier said than done but don’t just file them away under “ugh horrible day – glad it’s over” add them to your lessons learned log so that those actions are documented, reviewed and acted on. If you don’t have a lessons learned log then start one up. You need to be able to refer back to it, to read your actions and to share them. Examples of sharing lessons learned could be Availability Management for downtime issues or Capacity Management for performance glitches.


Step 10

If you don’t have the Service Desk and Incident Management on your CAB, invite them immediately. One of the things that never fails to surprise me out on consultancy gigs is how many organisations simply deploy Changes into the production environment without thinking to mention it to the people who have to pick up the pieces if it all goes horribly wrong. Ditto Problem Management and IT Service Continuity Management, as simply assuming that they will be able to swoop in and save the day should the Change fail is taking blind optimism a step too far.


Final thoughts

As someone who has seen and managed her fair share of own goals and Change related failures here are some things I find it helpful to refer back to.

(1) This too shall pass/Nothing endures. This quote and its connected story was recently referenced in “The Big Bang Theory”. The fable goes that there was once a king who assembled a group of wise men to create something that would make sad men happy and happy men sad. The result was a ring inscribed with the phrase, This Too Shall Pass. Take a deep breath…nothing lasts forever!

(2) It helps to have a sense of humour when dealing with the bad stuff. This is one of my favourite quotes from the author Terry Pratchett:

“Some humans would do anything to see if it was possible to do it. If you put a large switch in some cave somewhere, with a sign on it saying ‘End-of-the-World Switch. PLEASE DO NOT TOUCH’, the paint wouldn’t even have time to dry.”

In short, no matter how good your process is, and no matter how hard you try, things will go wrong sometimes. You can’t stop all problems; what matters is how you deal with it. So keep calm, take a deep breath and let’s sort things out.


Project success with Organizational Change Management (OCR)

Prepare for three camps in your communications
Prepare for three camps in your communications

This article has been contributed by Mike DePolis, ITSM Practice Lead at Fruition Partners

Organizations that are undertaking an ITSM initiative all too often leave out the centerpiece of success, or merely give lip service to it. Whether your organization is undertaking improvement of a single process, an entire transformational change, or even an ITSM tool replacement, Organizational Change Management (OCM) is that centerpiece to success.

In this article I will lay out some of the most important aspects and actions to consider for an OCM effort in your organization. These high level topic areas will be further expounded up in later articles.

Every project I’ve seen where OCM is a dedicated work stream, with thoughtful attention paid to it, has been extremely successful. Most of the failed projects I’ve encountered have either had no OCM component, or gave it a superficial nod in the beginning of the project, then quickly put such activities on the back burner.

At a high level, communication, training, and marketing are at the core of OCM, but there are other very important activities that should be considered.

Organizational Assessment

Even though you know your organization, interesting details can emerge that can be of benefit to your initiative by completing an organizational assessment. Such assessments can determine your organization’s propensity for change on a detailed level. Also revealed will be the largest barriers that should be addressed through the OCM program.

The assessment will reveal how the people in your organization view the current state, the proposed future state as well as many measures to help you understand where issues could occur.

There is another very important output of the assessment, and that is to understand which changes you should make now, and which changes should wait for subsequent efforts. Change can only happen at a certain pace for a given organization and attempting too much change for the culture and current level of maturity will likely doom an effort to failure, regardless of how much care is put into OCM activities.

The Three Camps

In any change there will be three camps of people, two minority camps and one majority camp. The first minority camp will actively embrace the change and can be used to further the cause in the organization. The second minority camp will very much be against the camp, and some will likely even actively attempt to undermine the change. The majority camp (generally about half the population) will wait and watch to see what camp will win out. Target the majority camp with appropriate communications and marketing. The minority camp against the change is very unlikely to change their minds.

Assess the Change

A detailed assessment of the change should be completed to provide a rich understanding of how the change will affect the organization. Start by listing how the new state differs from current state. Then evaluate the following:

  • Who will have to be involved who wasn’t before?
  • Who was involved before and will not be now?
  • Who is more empowered or less empowered then before?
  • Which changes make things easier for people?
  • Which changes will be perceived to make things harder (for example, process or procedure where they didn’t exist before?

For each item listed determine a high, medium or low level of impact. All items on the high list will be called the “Major Shifts”.

Create the Messages

The information provided from “Assess the Change” will be an input into creating the messages. The messages are the communication bullet points to the organization about what is changing, why it is changing and the benefit of the change to the organization. Creating this list of messages will be the basis of several forms of communications in the OCM communication plan. The focus here needs to be on the Major shifts for broad communication, and on a smaller scale addressing the more minor points.

The Champions

Identify a list of champions that will actively embrace the change and can help with the project, and organizational change itself. The champions should be very interested, involved parties which will clearly fall into the minority camp that embraces the change. From spreading the word in the halls to providing team based versions of broader communications the champions are the voice for supporting the change.

Strongly consider some incentive and reward for your champions for their efforts in helping to sell and realize the change. This will help them stay engaged for longer running projects.

Top Down and Bottom Up

Everyone is aware how important it is to have executive support for ITSM improvement programs, however, organizational change efforts should be targeted to the different audiences. In addition to messages from the executive team defining the vision and providing support for the program (top down) there should also be bottom up efforts. The champions can play a key part in this messaging. As an example, think about doing lunch and learns hosted by the champions, with their peers, addressing what changes will be coming up, and explaining the benefits to them and to the organization.

Communication and Training

The very first piece of a communication and training plan should be a stakeholder analysis. Every level of the organization should be mapped (CIO, VP Level, Director Level, Mid Manager Level, Heavy Process Participant Level, Casual Process Participant Level, Customer Level).

Each of these levels should have specific training and communication plans tailored to them. These plans should include messaging to address the following areas:

  • The major shifts discussed above
  • Benefits of the change
  • What they do not need to do anymore
  • What they need to do in the future
  • How they should communicate upward, downward, and to peers

It is most beneficial to structure training to include the OCM messaging, process training, and if applicable, tool training together in a single session. Using this approach allows for the elements to be pulled together so major shifts can be related to process, and process elements can be related to any tool changes.

Get Assistance

Good Organizational Change Management relies upon well-crafted messaging that delivers the right information in precisely the right way for the organization. Utilize your organization’s existing marketing and training departments, when available, as they have the needed expertise in these areas to provide the right experience. Consider looking outside for assistance on planning and execution of a complete organizational change program that is directly tied into your ITSM program.


I like to say that ITSM (and any other) initiatives are made up of at most 20% process and 20% tool components. The carbon based units involved represent the remaining 60% of the equation. This should highlight why initiatives with a strong OCM component are so much more successful than those where OCM becomes an afterthought.

Mike DePolis is a seasoned IT leader with a strong focus on business alignment and ITIL V3 Expert certification. As the ITSM Practice Lead at Fruition Partners, Mike has vast experience heading large segments of IT departments, and helping clients improve their operations.

Image Credit

Too much Shadow IT? Sunlight is the best disinfectant

"Sunlight is the best disinfectant”  U.S. Supreme Court Justice Louis Brandeis.
“Sunlight is the best disinfectant” U.S. Supreme Court Justice Louis Brandeis. Could issues with Shadow IT be addressed by openness and communications?

A lot of people confuse the term Shadow IT for something more sinister, something straight out of a Tom Clancy cyber-espionage thriller.

If it were so, it’d be so much more cooler, of course, but on the contrary, Shadow IT is something far less sinister, something we have all been probably guilty of at some point in our careers. The act of purchasing or using technology for the workplace without the approval or knowledge of the IT department is called Shadow IT.

This could mean something as simple as someone using Dropbox to share company data or the DevOps team purchasing an instance of a caching server to increase performance of the website, all without the IT department’s knowledge or approval.

This phenomenon is commonplace thanks to a clear paradigm shift in enterprise buying patterns. Any manager armed with a credit card and access to the Internet can buy software thanks to vendors adopting the SaaS model, as long as it falls within the budget allocated to his department. With the consumerization of technology, it has only made things easier for credit card toting users. It is not only software that is gradually going beyond the scope of Shadow IT, but also hardware and gadgets. We live in an era where we can get a tablet delivered overnight from Amazon if the mobile testing team needs one immediately.

Gartner predicts that

By 2015, 35 percent of enterprise IT expenditures for most organizations will be managed outside the IT department’s budget.

Like any innovation or trend that emerges fast, there are two sides to this. The purchase of that SaaS marketing automation tool by the marketing department would definitely help the marketing team work efficiently towards the business goal of generating more leads, but that also means that there is an increased responsibility towards the IT department in making sure that there are no risks involved.

Some risks associated with Shadow IT

  • Acquisition of software from dubious sources – download sites, cloud services with poor security
  • Ill-researched information leading to bad tech choices
  • Bug infested software
  • Obvious data security risks
  • Risk of malware or virus infiltrating the corporate network

An important question is to be considered here is why do users bypass IT to make purchase decisions? A lot of people view the IT department as still stuck in the ‘80s or that the process of procurement is slow. With the market and competition moving at breakneck speed, businesses cannot afford to wait over a simple purchase that impacts business. With more and more businesses delegating decision making or opting for flat hierarchies, Shadow IT only makes more sense. In case of a sudden drop in performance, would the business rather have an engineer himself take the decision to purchase additional servers to balance load or an engineer who informs IT and waits for IT to supply the same, knowing it would take a few hours (or a few days?). IT would probably have to escalate to ask team leader, finance and a number of other stakeholders for approval resulting in unnecessary outage and hundreds and thousands of disgruntled customers. Phew!

Of course, such situations are not this black and white, but the challenge remains the same.

What can the IT department do to solve this deadlock?

  • Broad-minded CIO – The vision of the CEO is crucial in shaping the organisation; we know this. The same holds good for the IT department, for which the CIO needs to be open to innovation and new ideas. If that means getting rid of that legacy tool you have been using for the past decade, so be it.
  • Openness of the IT department – The IT department should not turn into a bureaucratic force in the organisation, slowing things down with a mindless adherence to the traditional way of doing things. It should act as a catalyst towards the ultimate goal of the organisation – to make more revenue and to be profitable. Understanding business needs and continuously reframing policies and processes is a given for a cutting edge IT department.
  • Communication – Business units must understand that it is good practice to keep the IT department involved in technology purchasing decisions, even ones which have to be taken fast. It becomes imperative for the IT department to reach out actively to business units and educate them about why they exist – not to slow them down, but to help them achieve their business goals. The IT department must use the announcements section of the service desk effectively, sending regular newsletters and engaging your users.
  • Protect and to serve – It is essential that business units and the IT department are on the same page when it comes to IT purchases. The IT team needs to be fully aware of the latest IT acquisition even if they are not directly involved in the purchase. At the end of the day, it is IT that are going to be firefighting if some security lapse arises. After all, you cannot really fight if you don’t know what exactly you are fighting. Step up on your internal training and empower your team to take decisions. Train your team on the latest IT technologies.

In conclusion…

Do not look at Shadow IT as something that will put the IT department out of a job – look at Shadow IT as a huge opportunity to take unnecessary burden off IT – why would you want to spend your time on a minor purchase when you can spend the same time thinking about the big picture – IT strategy?

Remember, Shadow IT is not a bad word. We cannot stop business units wanting to invest in new technology to grow the business. But what we can do is work with them to ensure a smooth and productive work environment.

 Image Credit

A five step framework for business oriented metrics

A practical look at why some metrics programs fail while others are successful, along with some tips you can use to kick your metrics up a notch.


I was math-challenged as a child and hatred of anything having to do with numbers followed me into adulthood. This hatred remained with me until I became a manager and needed to begin proving the work my team was doing or understanding where we were failing. Actually, the turning point may have been the now-overused adage “you can’t move what you don’t measure,” a powerful concept that has a lot to do with the metrics programs I’ve created over the years. I’ve worked hard at this, mainly because of my math aversion. While Excel certainly helps, it’s all still “funny math” and through practice I’ve learned how to justify any story I want to tell using the numbers available from the IT Management tools my organizations have used.

Ultimately, if you can a story with metrics, how do you decide what is the right story? That’s the focus of this blog: determining the story to tell and to whom. 

Building a Business Oriented Metrics Framework 

Ultimately, if you turn to ITIL for help with metrics, you can be led astray pretty easily unless you read all of the books (or at least Service Strategy (SS) and Continual Service Improvement (CSI)). This is because at the end of each process described, there is a list of Critical Success Factors (CSF’s) and Key Performance Indicators (KPI’s). These are great sample metrics for the process you might be implementing and are critical for measuring that process’ success, however providing them to business partners will have you producing the same type of metrics IT’s been producing for years, the type that are not of real interest to the business. You’ll also be led into a false set of security because they came from ITIL, didn’t they? YES!

While these process metrics are one of the three types of metrics ITIL recommends you produce (Process, Service and Technology) and while they are important metrics to produce, they’re of little or no interest to business partners outside of IT because they don’t tell you how well IT is doing at delivering on the key strategic initiatives of the business.

To craft a metrics program that is of interest to the business, you need to start with the business. To help you get started, you can use the informal framework for building business-based dashboards and scorecards presented here (If it seems familiar, it is. It’s based on ITIL’s Continual Service Improvement approach):


This framework is very simple:

  • Know the vision of the organization or line of business
  • Document the goals that support this vision
  • Discover those Critical Success Factors (CSF’s) the organization feels are needed to be successful
  • Create Key Performance Indicators (KPI’s) or measurable indicators of the Critical Success Factors. Include target levels for these, so success is clearly shown.
  • Organize them into dashboard views for each audience that may be viewed live (on-line).
  • Develop scorecards that may be used for trending, historical reporting.

Three Steps to Using this Framework

This framework can be delivered using five basic sets of activities or steps, which are described below.

In addition to these steps however, some of this can only be demonstrating using examples. For these, let’s use a sample organization that is expanding into web-based sales to demonstrate the concepts. In this organization, the new Web Sales department and the Audit/Control group are tasked with delivering on three goals that support the organization’s vision of “providing the best shopping experience on the web.”

These goals include:

  • Providing Customers with an Excellent Web Shopping Experience
  • Giving Customers the ability to do shop any time of day (or night)
  • Guaranteeing credit card security

With this in mind, let’s look at the five steps:

Step 1Create a Focus Group

To ensure alignment, create a focus group consisting of key stakeholders from several lines of business and a few IT Managers. For the organization in the example, this would include managers from Web Sales, Audit/Control and the IT teams tasked to develop and deliver the website.

Step 2: Understand the vision, goals of the organization

With the focus group, take a look at the organization’s strategic plan. Typically the strategic plan includes a set of initiatives designed to support the organization’s vision, similar to the web sales initiative. These are often stated as goals so review the business goals associated with the initiatives and define the ways in which IT supports these goals.  Think of the goals as the pillars that support the organization.  This will ensure your program aligns with these goals and the strategic initiatives.

To move to the next step you will need the vision and goals, similar to the ones provided for the sample organization.

Step 3: Identify your audiences and their contribution

Next, working with the focus group, create a matrix to document the goals and critical success factors for each of the organizations to which you’ll be reporting. This matrix will be used to plan the dashboards and scorecard measures you need. Using the sample organization, the matrix would look like the one that follows.





(with target)

Web Sales department (1) Excellent Web Experience(2) Ability to do shop anytime
Audit/Control (1) Confidence when using credit cards
IT (1)    Service Operations Excellence(2)    “Fort Knox” security

Step 4: Make the goals measurable

To quantify the goals, you’ll need to work with your focus group to determine the Critical Success Factors that will demonstrate the fulfillment of their goals. The best Critical Success Factors (CSF’s) will be: “SMART”: Specific, Measurable, Attainable, Realistic and Timely.

Once your and the focus group have agreed on the CSF’s, you’ll be able to develop Key Performance Indicators, or measures that support the CSF. It’s extremely beneficial to develop KPI’s along with targets, so you and your business partners are clear on whether you’re successful in delivering on each of the goals. The best part about this approach is that when IT and the business agree on measures and targets, it’s easy to tell when IT has delivered or when IT is not meeting the needs identified by the business.

The ITIL books demonstrate this process clearly at the end of each process documented. The last section of the process description includes a list of Critical Success Factors for the process and Key Performance Indicators that support them.

For example, the Incident Management process (ITIL Service Operation 2011, p. 109) has a Critical Success Factor to “minimize the impact to the business of incidents that cannot be prevented.”

This is not measurable by itself, but four Key Performance Indicators follow it:

  1. The number of known errors added to the Known Error Data Base (KEDB)
  2. The percentage of accuracy of the KEDB
  3. Percentage of incidents closed by the service desk without reference to other levels of support and
  4. Average incident resolution time for those incidents linked to problem records

At the end of this stage, your matrix will be complete, similar to the one which follows for the sample organization:





(with target)

Web Sales department (1) Excellent Web Experience(2) Ability to do shop anytime (1)    Customers are satisfied with the website design and functionality(2)    Web site is available 24×7 (1) 85% of customers give the site a 5-star rating on exit(2) Web site is 100% available
Audit/Control (1) Confidence when using credit cards (1)    Web site is PCI compliant(2)    Security patches are up to date (1) 100% PCI Audit pass rate(2) 90% of patches applied within 24 hours
IT (3)    Service Operations Excellence(4)    “Fort Knox” security (1)    Web site is available 24×7(2)    Web site is PCI compliant(3)    Security patches are up to date (1)    100% site availability SLA(2)    99% performance SLA(3)    100% PCI Audit SLA(4)    No Security Breach SLA(5)    90% on-time patch SLA

You might notice several things when reading this list:

  • A qualitative measure (5-star rating by customers) is used to determine the customer’s view of the website. This is a critical measure as the CSF points to the customer’s experience.
  • The quantitative measures that sound like IT performance measures are translated to SLA’s for reporting purposes under the IT list of KPI’s. When creating the dashboards and scorecards in the IT Service Management tool, these SLA’s may be configured to demonstrate IT’s achievements against the business KPI’s.
  • Most of them sound like technology metrics. While this is true, these are a short list of technology metrics that these audiences care about. Notice some frequently reported, but missing measures: average speed of answer at the service desk, mean time to restore service etc. These would be IT metrics that support teams would need, but not IT management or the business, unless IT is failing to deliver on the metrics listed in the matrix and management wants to dig down to discover the reasons.

Step 5: Build the dashboards and scorecards

Once the matrix is agreed on and the method of measuring each KPI is defined, documented and agreed on by the focus group, the final step is to design dashboards and scorecards that represent these KPI’s. These are both graphical views of the Key Performance Indicators listed above, showing the result in comparison to the target. The main difference between the two is in the delivery:

  • Dashboards are dynamic: live representations of the data, often provided via a web portal that is integrated either to a measurement tool or directly into an ITSM tool.
  • Scorecards are static: they provide a historical look at the data including trending over a period of time.

Sustaining Success 

There are two final aspects of using this framework:

  • Continual improvement
  • Measurement retirement

As these dashboards and scorecards are used by the business, it’s important to come back to the focus group to evaluate the results. This may lead to creating new KPI’s or tweaking the ways in which they are measured, depending upon the focus group’s satisfaction with performance. In the case of the sample organization, it’s possible that the business is not meeting their objectives and may initiate changes to their critical success factors that will drive a need to change the measures. The point here is that you should not build the dashboards and scorecards then forget about them. Rather, you should meet with the focus group quarterly to review the metrics programs and IT’s achievements. This is a great opportunity to talk about service improvements that the business might need to support the initiatives as well.

Knowing when to stop delivering a dashboard or scorecard report is the last critical piece to a successful program. Once IT is reliably meeting the targets set by the business for a particular goal, it’s a good idea to discuss this result with the focus group during the quarterly review.  In this case, you’re not looking at changing CSF’s and KPI’s to address a business need, but rather you’re reviewing the KPI’s to see if the business still needs to see them continually and if any of the targets need adjustment.

Bear in mind that once you are achieving targets reliably, the business might want to work with IT to “up the game.” So in the sample organization, once the security patches and PCI audit result SLA’s are being met consistently, the business might want an shorter SLA for deployments of new features to the website. Thus, the matrix would be adjusted and the appropriate changes made to the dashboards and scorecards.

Benefits of the program

Providing metrics that are responsive to your business’ needs rather than the same stale set of IT metrics they don’t really care about will have a significant impact on the relationship between you and the rest of the business. Looking back at the reasons to measure, you can expect the following results:

  1. Direct: Live dashboards also provide the ability to determine the activities needed to drive success of an initiative and whether these activities are providing the expected result,
  2. Validate: You and your stakeholders are able to use the metrics you provide to validate whether IT’s performance is contributing to the business’ ability to meet their goals and objectives,
  3. Justify: IT is able to produce metrics that support a business case for infrastructure or development projects related to the delivery of a service,
  4. Intervene: Live dashboards provide IT and the Business to know when there is a performance issue and they can intervene immediately to turn the problem around.

This helps an organization move from a purely reactive mode to a more proactive approach that is integrated with the success of the business’ initiatives in mind.

Linium’s 5 Box Model – You Cannot Manage What You Cannot Measure from Linium on Vimeo.