Quick Guide to Knowledge Management

This quick guide has been contributed by Mike Simpson of CIH Solutions.

The guide discusses how Knowledge Management (KM) can be used to manage risk and control costs in an IT Service Management environment. The guide identifies four ‘hot spots’ based on the author’s experience and outlines common problems and suggests solutions using KM.

Introduction

Author: Mike Simpson, CIH Solutions
Author: Mike Simpson, CIH Solutions

As with most terms found in IT the term Knowledge Management means different things to different people. There is much available on the subject of KM and the term is often interchangeable with other terms such as intellectual capital, information management, data management and document management. In reality, KM embraces all of these.

So, what is my definition of KM in relation to an ITSM organisation?

First, this is not about scale. A KM system can operate just as effectively in a small organisation as a large enterprise. The principles remain the same – identifying, collating, storing and retrieving knowledge for use by all personnel in their day-to-day tasks. Also, this is not just about documents and data. When the experience of personnel is added into the mix we get Knowledge and this needs to be captured and stored for future use.

Second, from my experience the key feature of a KM system within an ITSM organisation is the understanding that different information has different values depending on circumstances. For me assigning value to information is vital and has priority over the capture of all available material.

At this point I should add that I do not differentiate between an MSP serving external clients and an internal IT service provider. The same KM principles apply. Also, the KM system described in this guide should be considered a ‘practical solution’ that can be implemented with limited resources and budget and extended over time.

I want to begin by briefly describing two KM systems that I have encountered in the course of my consultancy work.

Example One

I’ve seen only one truly outstanding example of an enterprise wide KM system and that was at a European pharmaceutical company. What struck me about this KM system was the sheer scale of the repository containing research papers, trials results and project documents covering decades of research amounting to many millions of pages and database entries. The success of this KM system was of course the strength of the underlying thesaurus that enabled scientists to discover (or perhaps re-discover) knowledge to support the design of a new R&D programme.

Example Two

My second example is at the other end of the scale. This is a local KM system that supports an IT organisation that provides hosting support for external SAP clients. This KM system also impressed me but for a different reason. Without any real top down sponsorship or funding the technical teams had created their own KM system based on a single central repository, but where all the content was created, published and maintained under very strict guidelines by a few key members of staff, but accessed by many. The rationale for using this approach was to bring discipline to the management of documents and data that were considered vital to the successful running of their IT organisation.

KM Model for ITSM

The rationale for the second example above sounds somewhat obvious, but the background problem as explained to me was one of long term ill-discipline in the day-to-day management of key information. Individuals, both staff and sub-contractors, would create multiple documents, held in isolated repositories or held on local drives, resulting in poor retrieval and inaccurate information.

The problem is a familiar one. Admittedly, this KM system is basically document management, plus some other information formats and a simple data classification system, but in my view this doesn’t matter as the problem of badly managed information was controlled by introducing a strong KM framework with a central repository to address a specific local need.

It is this model of KM that I want to discuss as the starting point for KM for ITSM, but first I need to say something about the concept of assigning value to information.

Defining Business Value

I mentioned above that assigning value to information is vital.

Screen Shot 2015-06-16 at 10.36.57

I call this category High Business Value information. So, what does it mean exactly? Essentially, this is a category of business information that covers all the vital and irreplaceable business records, documents, information and data that are associated with sensitive areas like customer data, compliance, security, personnel, finance and legal and commercial activities.

It is this category that has the potential to damage an ITSM organisation should this material be compromised by loss, breach of security, inaccuracy or the inability to locate and retrieve quickly when needed. It is the failure to identify, capture, publish and retrieve this category of knowledge that can have a significant impact on the management of risk and cost control.

Whilst all information is valuable, depending on circumstances, some information suddenly becomes more valuable.

KM Framework

Our first step is to build a KM Framework. This framework must define the KM life cycle to create, capture, review, release, amend, publish and retire content. In addition, the KM Framework must define a system of classification for the ITSM information. We have already identified a need to segregate high value information – I’m calling this Layer 1 information. All the remainder of the ITSM information and data is collected into Layer 2.

Basically, for Layer 1 we know what we want and where it is – hence we can find it quickly using a hierarchy with a controlled vocabulary where everything is tagged.

However, for Layer 2 the structure is more linear using a Thesaurus and non-controlled vocabulary. This allows for a more ‘search and discover’ approach.

Finally, the framework will identify the ITSM knowledge managers who will be responsible for implementing the framework, plus a KM Steering Committee.

Five Stages of the KM Framework

There are five stages within the KM Framework and these are shown in Figure 1 below. By following this five stage sequence all the information considered as High Business Value can be identified and either uploaded into the KM Database or retained in local repositories (known as source databases). This is the Integrate stage that is covered in detail later on under the Hot Spot scenarios.

Each stage should be followed for Layer 1 and then repeated for Layer 2.

Untitled

Figure 1 – Five Stages of KM Framework

  • Audit – once the categories within Layer 1 have been identified all the material to be included in each category needs to be identified. The audit will do this and will cover different media formats such as PDF, database tables, e-mails, webinars and HTML et al.
  • Map – during the audit the location of the material is identified. This is mapping and will be needed when the KM database is designed and built to identify what material should be transferred to the KMDB and what material should remain in local repositories.
  • Classify – once all the information has been identified for the categories of Layer 1, the documents and data can be classified according to the controlled vocabulary system and the hierarchy structure.
  • Assemble – once classified and physically located, the content for each category should be assembled as a schedule of descriptive metadata tables complete with information titles, document numbers, versions, data sets and physical location.
  • Integrate – once all the information has been assembled the metadata tables can be used to manage the population of the KMDB – either directly with content or connected to other repositories to extract the content. These are known as source databases.

 Classification

As mentioned above it is important to classify by value as well as classify by subject. For example, all customer data should always be considered high value, but the exact list will depend on the types of client and services that are supported by the ITSM organisation.

When it comes to the subject of classification there are many standards1 on taxonomy and debates about linear versus the hierarchy structure approach. I’m therefore suggesting that it makes sense to divide our total ITSM information into two distinct groups – the High Business Value information already discussed and a second group which is essentially everything else. I’m calling the first grouping Layer 1 and the second grouping Layer 2.

Once all the information has been divided into these two layers we must structure the information in two different ways. Figure 2 below shows this division.

Layer 1 should be structured using a taxonomy with a hierarchy and controlled vocabulary. This scheme will identify the information according to importance, sensitivity and security level, and will be used to control access to the information in Layer 1. The search tools that underpin our KM system will then be able to locate and retrieve any of the information in Layer 1 very quickly. Layer 1 will typically have the lowest volume.

Untitled2

 

Figure 2 – Grouping Information by Layers

For our second layer – Layer 2 – I suggest a thesaurus with a more linear structure that will allow more of a free form of search and retrieval based on a smaller number of the terms.

Not everything needs to be tagged in Layer 2, instead broader searches and cross searches can be adopted to allow a more ‘search and discovery’ approach even ‘looking inside’ some documents and files to locate content of interest.

This makes sense as the population of Layer 2 will cover all manner of archived project material, design documentation, presentations, non-critical business records et al. Layer 2 will typically have the highest volume.

Hierarchy of Layer 1

Given the relatively simple structure of our KM system I suggest a top down approach for Layer 1, based on a hierarchy of Categories and Sub-categories using a controlled vocabulary to tag documents and data sets. An example is shown in Figure 3 below. As Layer 1 is the primary focus of our initial KM design and build it’s not my intention to outline the structure of Layer 2.

Untitled3

Figure 3 – Classification Hierarchy

Once all the constituents of Layer 1 have been identified during our Audit stage all the information and data can be divided into Categories. These categories will be assembled under various functional headings, for example:

Category 1 – Customer Data
Category 2 – Compliance
Category 3 – Legal
Category 4 – Service Continuity
Category 5 – Finance
Category n – Security

Once all the Categories have been identified then the material should be further sub-divided into Sub-categories. I would suggest that these three drill-downs are sufficient to hold all the information in Layer 1. The Sub-categories will contain all the specific document and data sets that relate to a particular Category and this can be assigned by client or customer type or by any other specific grouping.

This hierarchy is not meant to be in any way prescriptive, just examples on the concept of Categories and Sub-categories.

Example ‘Hot Spots’

I’ve identified four possible ‘hot spots’ based on personal observations of real life events and these are shown in Figure 4. Clearly, there will be others depending on the set-up of a particular ITSM organisation and the types of client it supports.

The figure is based on a simplified ITSM organisation that could be either a MSP dedicated to external clients, or an ITSM organisation providing IT services to an internal client. The IT Operations can be either internal or external hosting with or without applications support. For the purpose of this guide it is assumed that the IT Operations is in-house and provides hosting, communications and applications support – within an overall governance framework.

There are four example ‘hot ‘spots’ shown in Figure 4.

  • Client Portal – Risk to reputation due to poor quality of customer information
  • Legal and Commercial – Cost of litigation due to incomplete contract audit trail
  • Compliance – Cost of compliance due to audit failure and forced re-work
  • Service Continuity – Risk to IT service continuity due to inadequate preparation

All of the above examples relate to the absence, inaccuracy or timely retrieval of information.

Untitled4

Figure 4 – Example Hot Spots

Risk to Reputation (Hot Spot 1)

In this scenario I’ve created a simple Service Operation (SO) organisation that has responsibility for managing the information available to customers via a Client Portal. I should state at this point that not all of the information available through the portal is the responsibility of the SO team. Some material will be supplied direct from the Client for uploading onto the portal – material from the Marketing Department such as prospectus and application forms.

The remainder of material will be service and technical support information produced within SO and cover such topics as service availability status, technical self-help and how-to-do-it video clips. The client portal also has a secure area for the client customer groups to access data on performance against SLAs.

The ‘Risk’ we are trying to mitigate here is out-of-date, missing and inaccurate information being posted to the client portal. The current arrangement within our SO is that information is currently held in separate repositories. Information is identified and collected and then manually or semi-automatically uploaded onto the Client Portal database using scripts. The risk here is that:

  • not all information is collected at the right time (like monthly SLA data updates)
  • incorrect information is selected for the right location
  • correct information is uploaded to the wrong location
  • not all information is collected

All the above risks can be minimised by the correct processes and checks in place and rigorously enforced. However, experience has shown that this manual and semi-automatic process can break down over time and quality – and reputation – can be impacted.

Untitled5

 

Figure 5 – KM Integration of Client Portal Information

All the client information that was previously managed manually has now been compiled into metadata tables from the AuditMap ClassifyAssemble stages. We can now move to the Integrate stage. The metadata tables will hold the locations of all the information and data needed to be accessed by the client portal and the KMDB will use distributed queries to collect all the information and data from these locations. In practice these will be permitted areas within local repositories (or tool set databases) – known as source databases. See Figure 5.

For example, the Known Error database (KEDB) could supply diagnostic help and work-arounds for self-service customers for the most common errors. The KEDB will also collect Event and Incident Management data in support of the SLA reporting that is provided to the client business units via the portal. The Configuration Management database (CMDB) will also be another source database for the supply of data to the client on service configuration.

Cost of Litigation (Hot Spot 2)

My second scenario relates to the threat of litigation as a result of a breach of contract. Whilst this sounds dramatic it is important not to underestimate the legal and commercial requirements to hold and maintain all contractual material and associated business records.

Most service based agreements come with some form of service credit arrangement. However, a decrease in payment may not fully compensate a client for poor service particularly when a number of service failures occur in quick succession or a major outage lasting several days hits not just the client but the client’s customers. Such a scenario could be considered a breach of contract resulting in litigation to seek damages and a termination of the service contract.

Any move to litigation will result in a demand from the client’s legal team for all relevant information to be handed over. This is known as e-discovery2 and the Service Operation team along with the organisation’s legal department will need to respond very quickly in a short time frame.

Untitled6

 

Figure 6 – KM Integration of Legal Information

This is another example of how the KMDB can be used to store high business value information. Figure 6 shows how the KMDB can contain a Legal DB segment that is used to store in one location all contractual and historical SLA information relating to an individual client. As with Scenario 1, the metadata tables will hold the locations of all the information and data needed to be accessed by the Legal KMDB segment. Again, distributed queries are used to collect all the information and data from these source DB locations.

The information will include all versions of contracts, contract amendments, SLAs including email trails between the client and the IT Service Provider. This latter point of email capture is increasingly used to highlight any communication that might indicate an implied contract variation by either party. I would suggest the inclusion of a Message Record Management (MRM) system as part of the KM solution.

Screen Shot 2015-06-16 at 10.37.56

Also, it will be necessary to install an activity monitor to log and track activity of users of the KMDB segment. In reality, this would be good practice across all of the KMDB segments but essential in this instance.

One final point. Where the service provider is internal to an organisation, for example the public sector, the risk of litigation is negligible. However, be aware that a consistent under performance against SLA targets could be a fast track to IT outsourcing.
Here is another example of the importance of a KM sub-set of material that can be assembled on the basis of a specific demand. During a compliance audit, ISO27001 for example, there will be a specific document set that will need to be made available to the auditors for the certification process.

Cost of Compliance (Hot Spot 3)

I’ve seen this happen on a number of occasions. Although this is usually presented as an exercise in cost saving, invariably it is driven by a long term dissatisfaction in the performance of the internal service provider.

Without a rigorous KM approach there is the risk of auditors finding a shortfall in the control objectives and controls. This will result in low auditor marking and possible non-compliance. There is now a real cost involved with the remedial work needed for a re-run of the audit, particularly with the high daily rates charged by external auditors.

The material can range from Information Security Policies to Physical and Environmental Security. There is a wide range of different types of information and data and the Audit and Map stages of the KM Framework will require a lot of research and agreement from the KM Stakeholders on what should be included in this KMDB Compliance segment. It is likely that some of the lower level information may be located in Layer 2. If this is the case then it might make sense to leave it where it is and simply connect between the two layers. It is also true that the scope of ISO270013 is such that the KM will need to connect to a wider range of tools and assets.

One particular example is software asset management (ISO 27001 – Clause A8: Asset Management). Under this heading auditors will check the number and validity of software contracts held and check that the licences cover all the users who actually use the software. This could be addressed by setting up a source DB within a SAM tool and extracting all the data needed for the audit (as a controlled set) and then sending it to the KMDB. This is actually a very common failure point.

Risk to Service Continuity (Hot Spot 4)

In this final scenario I want to look at how the KMDB can be used to support Service Continuity. This has a much broader scope than just KM and I’m not intending to cover the whole subject of Business Continuity Management (BCM). Again, there are multiple terms involved here – like Disaster Recovery, Business Recovery and Service Recovery. In the case of ITSM and KM, I’m going to describe how KM can be used in support of Service Recovery within the broader BCM that covers the end-to-end business of a client.

The dilemma facing an ITSM organisation is no one can really identify all the situations likely to occur. Certainly, the evacuation of a data centre due to fire and flood is an obvious scenario, but thankfully not one that occurs very often. Clearly you can’t prepare for every instance but it is possible to target some common ‘knowns’.

So, here is a possible starting point. In our Layer 1 (High Business Value) under the Service Continuity category, the sub-categories should be constructed to reflect various ‘threat scenarios’ – one per sub-category, such as cyber threat, data theft and denial of service to name a few. We could also add major software outages that can and do occur from time to time.

Each ‘threat scenario’ can then be structured along the scope and guidelines of ISO223014. This will create a consistent framework for compiling all the recovery procedures, communication escalations and fall back plans for each scenario. Clearly, there is much more to discuss here but there is a future article that will address all of these aspects of service recovery which is planned for publication later in 2015.

Conclusion

What this guide attempts to outline is a number of possible solutions to common issues around both risk and cost control in an ITSM organisation. It is not intended to be prescriptive. The KM system described here should be considered an ‘entry level’ system, but with the capability of extension as time and budget permit. This KM system is also predicated on content being held within existing repositories, as well as a central KMDB, but extracted on demand. The success of implementing a KM system will always reside with the management and staff of an ITSM organisation and not the technology. Hence the emphasis must always be on developing a KM Framework as the starting point.

This quick guide has been contributed by Mike Simpson of CIH Solutions.

Industry News Roundup Incl The Project Management Rap

13050063965_7a64771344_zNo time to read all the interesting industry news and info floating around social media and appearing in your inbox? Read our round up of what we’ve found interesting this week.

  • When The Hell Are You Going To Patch? – Rex McMillan writes for LANDESK on why sometimes you just need to patch the hole. Read more here
  • Project Management Rap– Making us laugh, learn and, if we’re honest, cringe a little in the office this week is this Project Management Rap from Chris Croft. Watch/Listen here (Via Vladimir Ivanov on LinkedIn)
  • Changing Jobs in Your Twenties Could Lead To A More Fulfilling Career – Thinking those applicants who’ve moved jobs several times are a hiring risk? Think again. Read more here
  • Why You Should Never Swear On Your LinkedIn Profile – With 93% of recruiters using LinkedIn to vet candidates the reasons are obvious. If you ask us the pussycats and fluffy bunnies should also be reserved for Facebook. Read more here
  • Lack Of BYOD Policies Put Mobile Business Data At Risk – BT warns that UK businesses are not taking adequate measures against mobile security breaches. Read more here
  • Culture: The One Thing A Bank Can’t Buy – Matt Pancino of Suncorp explains how culture makes the difference between those that disrupt and those that are disrupted. Read more here
  • Find A Career Wingman To Help Navigate The Career Ladder – No longer just for trying to find a suitable…um…partner, a wingman could help you with your job! Read more here

Vendor News

Got some interesting news to share – say hello via @gobbymidget 

Image Credit

Scrum vs Kanban

Is this an Alligator or Crocodile? Read this article to find out (Oh... and you might learn about Kanban and Scrum too!)
Is this an Alligator or Crocodile? Read this article to find out (Oh… and you might learn about Kanban and Scrum too!)

What are the differences between Scrum and Kanban anyway?

When you’re studying two similar animals from different species – I don’t know, lets use crocodiles and alligators – it’s easier to spot the similarities than the differences. I’ll give you one now and reward you with another difference for reading all the way to the end of my article.

Crocs can lift their bodies off of the ground, gators can’t. Did you know that?

This is a similar problem for those of us that are beginning to explore the world of Agile, Scrum and Kanban. Are they the same? From the same species? What are the differences?

It’s so easy to see the commonality, because the distinctions are nuanced and harder to spot. If you’re not careful you’re unable to spot one from another.

Let me help you explore some of the diversity between Agile/Scrum and Kanban

Back to the beginning…

Before examining Agile/Scrum and Kanban it is worth pointing out that there are many distinctions to be drawn between Agile and Scrum. They aren’t one and the same thing and there is probably a whole other article for a whole other day to write them up.

For the purposes of this article I want to draw your attention to the suitability of Kanban in IT Operations and to achieve that I can leave Agile and Scrum lumped together.

The first place to understand the contrast between Scrum and Kanban is to look back at the roots of each method.

Scrum was born out of a line of iterative software development methodologies stretching back to the 1960’s and ‘70’s but coming into prominence in the 1990s as a pushback against the heavyweight Waterfall project management practices. In the ‘90’s methods such as Scrum and Extreme Programming became popular and in 2001 the Agile Manifesto was written to bind these disparate practices under a common banner.

But remember that Agile/Scrum was initially formulated to solve a Software Development Lifecycle problem.

Kanban incorporates a number of practices codified by the automobile manufacturer Toyota as part of TPS – The Toyota Production System – a precursor to the wider Lean movement which emerged in 1990.

These roots are based in business process, in manufacturing, in the process of refining raw materials into a valuable product through manual and automated labour. In converting chunks of rubber, steel and glass into gleaming, shiny cars rolling off of the production line.

Whereas Agile/Scrum was formed to provide an alternative to heavyweight Software Development Lifecycle methodologies, Lean has been more aligned to core business processes – seeking efficiency gains and quality improvements.

My objective here is to speak to you as IT Professionals considering adopting a Lean or Agile approach to IT Operations. It’s worth pointing you towards the works of David J Anderson who in 2010 wrote “Kanban: Successful evolutionary change for your technology business”, informally known as “The blue book”. This is the specific variant of Kanban that you want to study and learn more about.

So wait.. Kanban is not Agile?

If we are following strict definitions and examining Agile/Scrum and Kanban as if they were two separate animals… no, Kanban is not an Agile practice. It is a Lean practice.

But Kanban delivers a lot of the same benefits into an organisation that Agile promises to. And, as we’ll discover later in this post, does it in an evolutionary way rather than throwing the rule book out and introducing strange, new practices.

You could say that Agile, if done correctly introduces Agility into an organisation. Notice the capital “A” there. Kanban introduces business agility with a small “a”

More importantly where Agile/Scrum promotes product development agility, Kanban is positioned to make the whole organisation more agile.

Kanban practices can be used across the organisation from marketing, sales, product development and customer support and value chains can be found stretching between these organisations. Best of all heavyweight processes such as Waterfall, change and release management can happily exist with the wider Kanban framework.

This is the “evolutionary” part of the description in Davids book. Taking existing business processes, defining them as part of a value stream and finding ways to optimise the work.

OK – tell me more about Scrum

Scrum is a lightweight framework that defines roles (like Product Owner and ScrumMaster), artifacts (like Product Backlog, Release Backlog and Sprint Backlog) and practices (like Daily Standups, Sprint planning and Sprint review meetings).

Teams following Scrum take a body of work – typically a list of features that are required to build a software product – and break them down into discrete units of work (called User Stories) that can be re-prioritised according to business needs.

By taking a small section of those units of work and committing to finishing them before a short-term deadline (known as a sprint – often 10 working days) the team can focus on building the next small increment of the product before stopping, replanning and committing again.

Scrum is great! I’ve been successful with teams that have used Scrum to build products. But it is a fairly disruptive method and you won’t get 50% of the benefits by putting in 50% of the effort.

To be successful at Scrum you have to allocate people roles, train them and arrange your work according to the methodology. Expect to have backlog grooming sessions, to measure your work in story points and so on.

Scrum is a fairly prescriptive method that requires the team to bend around the rules in order to follow it correctly.

Much of the work in IT Operations is driven by external factors – servers experiencing hardware issues, ISP’s having intermittent connectivity issues. Although it’s nice to plan around the stability that Scrum promises – with a fixed sprint backlog of work – the reality is that teams have to deal with interrupt driven work and absorbing this isn’t a strong characteristic of Scrum.

There is another characteristic of Scrum that appears to make this activity very similar to Kanban… that is if you didn’t understand the difference between crocodiles and alligators.

The last thing to mention is that Scrum teams often maintain a “Scrum board” visualising their work on cards into lanes.

Scrum Board

OK! Tell me more about Kanban

Well, the last thing to mention is that Kanban teams often maintain a “Kanban board” visualising their work on cards into lanes.

Kanban Board
Kanban Board

Herein lies the difficulty in distinguishing between Scrum and Kanban when the most visible artifact for either method is exactly the same.

But there are significant differences with Kanban. Firstly it is an evolutionary method to introduce change in an organisation. Meaning that no additional roles or practices are introduced by organisations that adopt the method.

Existing roles and processes are kept but are wrapped into Kanban. Workflows are investigated and visualised to provide control around the work but we don’t change how people do their jobs or interact.

Scrum deals with the problems associated with Product Development and introduces methods to increase Agility.

Kanban examines the value stream upstream (perhaps into the sales and marketing departments where leads are generated) through the manufacturing/development/technical departments down to the point where value is released to the customer – how products are shipped or released.

It’s similar to the same way that a manufacturing process for a Toyota car is defined all the way from the raw steel arriving at one end of the factory through the refinement process until a car rolls off the other end. Kanban maps and provides controls throughout the whole value stream.

Imagine you are in control of new laptop builds in an IT department. Surely you have a value stream which starts with a request from HR notifying you of a new employee. Actions are taken – laptops ordered, imaged, configured, added to the various management systems. At some point later (much later??) the laptop is delivered to the employee. You’ve just described a value stream that can be visualised, managed and incrementally improved with Kanban.

Here is a visual outlining the differences between the two animals.

Scrum versus Kanban
Scrum versus Kanban

In summary

I promised to reward you with the last difference between crocodiles and alligators. Look at the snout – but presumably from a distance. Crocs have a longer, sharper “V shaped” snout. There you go!

But this isn’t the action that I want you to take away from this article. Your IT organisation should be investigating new ways of working and building a culture of high performance and continuous improvement.

Agile/Scrum and Kanban are all worth investigating. My call to action in this blog post – if you are in a position to suggest work improvements in your department – is to buy David J Andersons Kanban book and see how evolutionary change is possible in your corner of the world. (Amazon Link)

Most successful Kanban adoptions are lead from the “middle out”. That is junior managers taking the initiative and adopting Lean practices influencing those that carry out the work. Their successes often influence upwards as senior managers identify the resulting service improvements.

Who knows – buy the book today and in a few months you could be blogging your IT transformation using Kanban on the ITSM Review. I’m looking forward to that!

Image Credit

…It’s a Crocodile

Advice for Building Your House of Change Management

Winston Churchill
“To improve is to change; to be perfect is to change often” – Winston Churchill

It’s inevitable that we will encounter change throughout our personal and professional lives. New products are launched by businesses; people move house and football teams get promoted (but sadly not my beloved Derby County this season).

Many organisations will have some sort of Change process, but in my experience, that process is often applied rigidly to police implementations to the production environment; constrained by our ITSM tool; and is mired in bureaucracy leaving people to get bogged down – and sadly – miss its true value.

As IT professionals, we must be able to understand, plan for, adapt to, and deliver our customers’ needs whilst balancing quality, control, and conduct effective operation of our services. This is no mean feat.

What I want to share with you in this article is how you can build on your existing change process or processes and bring them together to help develop an end-to-end solution that works for you.

Meet the people

When I started looking at our existing change process, I quickly became concerned (and bored) reading a lot of documents ranging from lengthy procedural documents to copious meeting minutes.  As a Change Manager, if you struggle to make it most of the way through the documentation, you can’t expect everyone to follow and appreciate it.

I quickly realised that the best way to learn about – and gauge opinion on – the subject was to meet the people that carried it out – the IT professionals of the organisation. The easiest way to meet vast majority of people was by arranging informal 1:1 meetings; have impromptu chats over the water cooler and buying the odd coffee or two.

Additionally, be sure to meet your customers to understand their perception of how the IT department delivered their change-related needs.

Very quickly, you can get different pictures and interpretations of how a process works in practice just by talking to people. Equally, I was able to draw some common themes by getting responses along the lines of:

  • “We’re good at big projects but not at the smaller stuff”
  • “There is little or no documentation or communication”
  • “It’s quicker to code a solution than get anything done in our tool”
  • “There’s so many obstacles and bits paper to fill in”
  • “We only hear about a change when it’s about to go live or after the event”
  • “It’s just a box ticking exercise”

Quick Wins – Work with what you have

Against a backdrop of varied opinions, unwieldy documentation and difficulties with the tool, it’s easy to think there’s a mountain to climb!

So I looked at what low hanging fruit we could work on and developed a short term plan focusing on what small improvements I could make with the tools I had. Quick wins included:

  • Developing a few “Standard Change Templates” with a couple of teams for changes that were routine, repeatable and had known risk and impact.
  • Introducing a series of questions on the change records for people to complete – effectively giving them a script to follow covering the risk, impact and implementation surrounding the change.
  • Attending team meetings to demonstrate how to raise a change in the tool.
  • Sending out a fortnightly newsletter giving advice on how to complete change tickets, inviting people to make suggestions and so on.

Get Everyone Involved – Revolution by Evolution

As much as the quick wins helped, for the longer term, it was apparent we needed to not only improve on our Change Control Process but push the understanding that change starts a lot earlier than being simply ready to ‘go-live’.

In order to achieve this, I needed resource and senior management support to make it happen. That is when I developed the idea for a “Change Away Day” which included:

  • Representatives of all teams within the IT department with a variety of experience in the change process
  • A proposal to Senior Management outlining the issues, setting objectives for workshop and providing a timeline of not only the day – but the next 3-6 months.
  • A basic introduction to Change Management replacing the jargon with a theme people can relate to. We used the idea of building or moving house:
    • “What” (are my requirements) i.e. where do I want to live?
    • “How” (am I going to design it) i.e. architects will to design it with me before any trenches are dug by the builders
    • “Why” (do I want to live there) i.e. assess and evaluate things that you like and dislike; the local schools; getting a mortgage and so on
    • “When” (is it going to happen) and “Who” (is involved in delivering it) i.e. you can’t move overnight and will need some help to do it
    • “Quality” (is it fit for purpose) i.e. do we have a safety certificate, are the utilities working and so on?
    • “Approval” i.e. those final checks like exchanging contracts, moving van ready and packing your bags
    • Guest speakers from department covering other processes and how they interact with Change Management – in this case, Testing and Solution Design Assurance.
    • Lunch!
    • A range of activities that:
      • helped with the learning;
      • reviewed the current change control process
      • developed principles to incorporate Change Management into the earlier lifecycle of development and projects

As away-days can be expensive from a time, resource and cost perspective, a series of follow up meetings – lasting no more than an hour -were held over the next couple of months to review, improve and ratify specific changes to the process.

From Change Control to Change Governance

After the workshops were complete, the main principle was that Change had a start point, a delivery mechanism and an end point. From this, we developed a Framework to incorporate processes that were involved with these principles, namely:

The Start Point

  • RFC Review – a mechanism to initially capture customer demand and suggest its feasibility, size and so on

Change Delivery

  • For large changes requiring effort this could become a formal project following the established Project Management process
  • For smaller changes, we would look to group these together as releases.
  • It is possible for projects and releases to overlap for delivery – but this is a subject for another time

The End Point

  • Before implementation of any change to the live environment, the existing Change Control process had to be followed to obtain final approval.
  • We also use the opportunity to realise the following improvements including:A new CAB structure with specifically invited attendees and a new agenda format
  • A Risk & Impact Calculator to help score changes in terms of “Technical Risk” and “Service Impact”
  • The increased use of Standard Change Templates

Underpinning Strategies & Processes

  • A broad summary of the areas that need to be engaged or considered as part of any Change-related delivery.

framework

Sealing (and documenting) the Deal

This is arguably the most important point, without engaging people; the re-launch was never going to get out of the starting blocks. The key points and activities to consider were:

  • Presenting back to Senior and Middle Management the key points and what they have gotten for committing time and resource
  • It’s important to treat changes to processes like any other change – I took this to CAB for review and approval before implementing and communicating the framework. After all, you cannot expect people to follow processes if you do not lead by example!
  • Tailor the communication to your audience – for me, I identified three types and the level of information they needed:
    • Partnering and Project Management – a group consisting of Business Relationship people – received a strategic overview of the Framework that incorporated their processes
    • Implementers – typically technical staff involved in developing, raising, assessing and implementing changes –  received an overview the framework, their responsibilities within the process and the changes to Change Control
    • Impacted teams – (teams impacted by change implementation e.g. Service Desk) –received a high level overview of the framework, how/where to find information about upcoming changes and why it matters
    • Documentation needs to be succinct and will have varying levels of detail, specifically for us, we produced:
      • Change Policy – the overarching document covering the Framework, the processes and the “rules of engagement”
      • Processes that were straightforward documents combining the high level process flows with simple procedures for each step required. Areas included:
        • RFC Review – an initiation process owned by the IT Business Partners to bring customer’s request for change to receive a quick review or ‘first pass’ by Technology experts in terms of strategy, estimates and being worthwhile.
        • Project Management – the formal methodology for delivering projects
        • Release Management – for combining and scheduling the build, test and deployment of changes
        • Change Control – to implement a change to the production environment.
  • Training Guide – short and to the point – these were given as small A5 hand-outs to staff involved at different levels of the process.

Summing up

  • Don’t let Change Management become restricted to ONLY the production environment. It’s important to protect it, but it’s even more important to help plan and facilitate change at the beginning rather than the end.
  • There is more than one “CAB” – keep in mind that throughout the lifecycle of a change it will be reviewed, rejected and approved many times at the Business, Project and Technology levels before it is ready for implementation.
  • Play the game – as a Change Manager, you will be expecting people to follow the rules for technology, and it’s only fair you do the same for process.
  • Make sure you baseline – be pragmatic about what you can achieve and be transparent about what is in scope. For example, we started off with formal Change Control for a couple of years, then brought in the Framework and are now working on linking it to Release Management.
  • Get everyone involved – by engaging people at the beginning, it makes the improvement process a lot easier – especially when’s “for them, by them”

Image Credit

Transforming the IT service experience

Left to right: Lori Krikorian, Dana Swanstrom, and Sally Shane accepted the Project of the Year award in Las Vegas in February.
Left to right: Lori Krikorian, Dana Swanstrom, and Sally Shane accepted the Project of the Year award in Las Vegas in February.

EMC Corporation’s IT organization (EMC IT) has been on a multiyear transformational journey, transitioning to a virtual and private cloud infrastructure and modifying its operating model to be one of a competitive service provider. They have also been working to unlock the capabilities to deliver more agility to its business customer through optimized service delivery and modern application development aligned to IT trends of cloud, mobile, social, and Big Data. But, the company’s IT service management (ITSM) processes lacked agility to meet the evolving needs of its internal customers. Couple this obstacle with unstable, obsolete, and unintegrated technologies that lacked mobility, community, and self-help functionality.  EMC IT launched its UnITy program to address this significant challenge.

UnITy Program

The UnITy program began in July 2012 to optimize ITSM processes, replace its previous ITSM technology platforms, and transform IT into a customer-focused organization committed to consistently delivering collaborative support.

To start, the team conducted more than 100 interviews and numerous workshops to collectively understand the challenges IT faced and secure leadership support for the problem, business drivers, critical success factors, and solutions. From these sessions, the team defined the program’s vision as: “To delight EMC IT’s clients by transforming their IT service experience through optimized service management processes and technologies.”

The program then set out to address four key points in EMC IT.

  1. Enhance the customer experience for EMC’s 60,000 users by evolving IT’s to be service-focused and allow the customer experience to drive prioritization and responsiveness.
  2. Enable IT to operate as a business by optimizing processes and improving transparency through service metrics and better service quality.
  3. Align IT’s resources with customer expectations and improve capabilities such as self-service and the availability of better decision making data.
  4. Optimize IT support so the company will, in time, realize millions in annual savings by reducing the use of in-house production support and managed service providers, decommissioning redundant IT systems, and using self-service to reduce calls to the service desk.

Program Phases

In Phase I, the program released the new ITSM platform along with three processes – incident management, request fulfillment, and knowledge management. In Phase II, the program rolled out an improved configuration management database, a new service taxonomy, and three more processes – problem management, change management and service asset and configuration management.

At the core of UnITy was a mountain of change for EMC IT to adapt. To usher in the necessary cultural changes we created three workstreams – process optimization, technology, and transformation. While the workstreams focused on their respective topics, the entire team worked cohesively to evangelize the program by sharing a common understanding of the capabilities and benefits being delivered by UnITy. Perhaps most importantly, the transformation workstream led the organizational change in EMC IT, providing training, communication, and engagement at all levels in IT to drive the cultural evolution toward one of customer focus.

On the training side, the team built its own custom, instructor-led and computer-based training and enlisted 100 global users who went through week-long training on the new platform, processes, and way of thinking. In turn, these users held day-long training sessions with more than 1,000 users across our global EMC IT sites. As program champions, these individuals evangelized the program and provided support in the field before and after. Additionally, another 1,500+ users received computer-based training.

On the communications side, the UnITy program engaged a multi-channel campaign to provide information in a number of accessible and easily digestible ways. This included:

  • An intranet site that consistently ranked among the most-visited EMC IT sites
  • A regularly published email newsletter
  • Regularly scheduled global town hall meetings
  • A user engagement network that met weekly, championed the program, and provided feedback
  • A series of videos that featured IT leaders and program members delivering key messages

The UnITy team also used its leadership steering committee to validate decisions, in some cases make decisions, clear hurdles, and champion the program throughout IT. This was vital to pushing change through an organization and program sponsors helped communicate expectations to EMC IT through video messages, personal emails, and even shared goals for training and adoption.

So, what did EMC IT learn from this complex and culture-changing program?

  1. Engagement at all levels of the EMC IT organization was vital. Having leadership support made it easier to push changes through, but having employee understanding of why the changes were happening and how they would benefit the individual and organization accelerated adoption.
  2. No customizations! Sticking with the out-of-the-box ITSM functionality kept the program on course using best practices and ITIL processes, instead of bending the technology to match the way IT operated in the past.
  3. Listen to the pros. We brought in experts to guide us in process adoption and tool deployment. When in doubt, we turned to the experts on best practices and moved ahead with their guidance.

EMC IT are currently in Phase III of the UnITy program to expand the service management platform and processes to businesses outside of IT. They remain focused on the metrics and reporting analysis to identify areas for continuous improvement. While it was a tremendous initiative for the whole EMC IT organization, they now have the technology and processes in place to continue to evolve the organization and to continue to provide the highest quality services for the future.

In February this year, EMC IT won the Project of the Year Award at the Pink Elephant Annual Conference in Las Vegas. If you would like to learn more about the UnITy program’s journey, you can read this blog post by program lead Dana Swanstrom.


 

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

Pink14 Preview: What’s the big idea?

"Sometimes you're so busy putting out fires that you don't have time to improve fire-fighting or fire-safety"
“Sometimes you’re so busy putting out fires that you don’t have time to improve fire-fighting or fire-safety”

Do you ever get a Big Idea?  You’ll be talking or reading about ITSM and the proverbial light bulb comes on.  You see a connection or an underpinning concept that you hadn’t seen before.  Sometimes it appears to be an original insight, one you haven’t heard expressed exactly that way before.  And very occasionally it really is novel and it really is right: you subject it to the scrutiny of others and it stands up.

It happens to me.  Because I’m privileged to spend so much time interacting with some of the best minds in ITSM worldwide – and thinking and writing about what I learned in those discussions, and applying that knowledge as a consultant – it happens to me quite often, about once a year. In fact I will be presenting on some of these big ideas at the upcoming Pink Elephant IT Service Management Conference and Exhibition (PINK14).

Standard+Case

A couple of years ago my Big idea was Standard+Case, a topic which I will be running a half-day workshop on at PINK14.

Standard+Case is a synthesis of our conventional “Standard” process-centric approach to responding, with Case management, a discipline well-known in industry sectors such as health, social work, law and policing.

The combination of Standard and Case concepts gives a complete description of ticket handling, for any sort of activity from Incidents to Changes.

  • Standard tickets are predefined because they deal with a known situation. They use a standard process to deal with that situation. They can be modelled by BPM, controlled by workflow, and improved by the likes of Lean IT and ITIL.

  • Case tickets present an unknown or unfamiliar situation. They rely on the knowledge, skills and professionalism of the person dealing with them. They are best dealt with by experts, being knowledge-driven and empowering the operator to decide on suitable approaches, tools, procedures and process fragments.

ITIL and Lean do fit this S+C paradigm, if you use them in the right situation: Standard responses. S+C extends them with better tools for non-Standard cases: Adaptive Case Management, Kanban, Knowledge Centered Support(KCS)… Better still, this S+C approach might let the ITIL and anti-ITIL camps live in peace and harmony at last.

Slow IT

Last year it was Slow IT.  Slow IT is a provocative name.  It doesn’t mean IT on a go-slow.    It means slowing down the pace of business demands on IT so as to focus better on what matters, and to reduce the risk to what already exists.  Think Slow Food, and more recently Slow Business and mindfulness etc.

The intent of Slow IT is to allow IT to deliver important results more quickly.  It does this by concentrating on the interfaces between business executives and CIOs.  Slow IT highlights the importance of Governance of IT and of Service Portfolio in order to make the right decisions to do the right things in the right way at the right time, to maximise benefit and minimise risk.

Right now the pace of change in IT is approaching human limits.  Many IT shops are overwhelmed by change, drowning in projects.  More are overheating: working at lunatic pace because the IT community convinces us we have to.  Slow IT challenges the hysterias and fads of IT to ensure that these results are really needed as quickly as we think they are.  Slow IT is about trying to introduce more measured responses, to bring some sanity to the current dangerous madness that is organisational IT (you can read more on this here).

I’ll be presenting on Slow IT at PINK14.  In addition we’ll talk about my Meet-In-The-Middle strategy to address the Slow IT issues by offering a quid pro quo: Fast IT.   If the organisation will slow down the demands on IT, IT will have the breathing space to implement approaches to respond faster, such as Lean, Agile, DevOps, and good old CSI.  Right now too many IT teams are so flat out serving the business they don’t have the bandwidth to introduce better methods properly.  It’s the old catch-22 of being so busy putting out fires that you can’t improve fire-fighting or fire-safety.  Slow IT takes off a bit of pressure, giving the team some headroom, to make improvements.

I hope to see you at the Pink Elephant ITSM conference.  I’m honoured to be assembling some of those great ITSM minds at the Pink Think Tank, to address one of the biggest issues facing IT today: how to manage a multi-sourced IT value chain.  We’ll be looking to produce tangible actionable advice, so look out for the results.  I have a feeling it may be the catalyst for my next Big Idea.

What do YOU think the next “big idea” will be?


Find me at PINK14:

Pink Elephant 18th Annual International IT Service Management Conference & Exhibition

Fatima Cabral and George Spalding delivered the opening keynote at PINK 2013
Fatima Cabral, CEO and George Spalding, Executive Vice Preseident at Pink Elephant delivered the opening keynote at PINK 2013

We are excited to announce that we will be a Media Partner for Pink Elephant’s 18th Annual International IT Service Management Conference & Exhibition (aka Pink14), 16-19 February 2014, at the Bellagio Hotel in Las Vegas.

The event brings together 1,500 like-minded IT professionals, with over 160 sessions spread over 14 tracks – covering a vast array of subjects from all across the ITSM spectrum.

What you can expect

  • 14 tracks of educational, strategic, tactical and operational content. Tracks include: The 3 I’s of Leadership; CIO Forum; ITSM Winner’s Circle; ITSM Project Management; Service Support and Operations; How-to ITIL Clinics and Workshops; CSI – There Is No Finish Line; Using Frameworks and Standards to Achieve Business Value; Pink Think Tank; Tools and Technology; Breakfast Clubs; Discussion Forums; Half-day Workshops; Platinum Sponsor Stream – BMC Software. You can find out more information about all of these tracks here.
  • A various array of pre-conference courses covering ITIL and Lean IT Certifications; and post-conference workshops covering COBIT and ‘how-to’ instructional workshops.
  • Presentation of Pink’s IT Excellence Awards, with awards for: Project of the Year; Practitioner of the Year; Case Study of the Year; Innovation of the Year; and IT Leader of the Year.

Both Rebecca Beach and I will also be in attendance. If you would like to schedule a meeting with either of us at the conference please email me. We are interested in hearing from all attendees whether you are a vendor, practitioner, consultant or other!

We hope to see you there!


Event Summary

WHAT

Pink Elephant Annual International IT Service Management Conference & Exhibition (aka Pink14)

WHERE

Bellagio Hotel

WHEN

The conference runs from Sunday 16th – Wednesday 19th February, with pre-conference courses running from Wednesday 12th – Sunday 16th February, and post-conference courses from Thursday 20th February to Saturday 22nd.

BOOKING

Booking rates are available online

Assessment Criteria – Change, Config and Release

Today we begin our competitive analysis of Change, Config and Release.  As with previous reviews our goal will be to highlight the key strengths, competitive differentiators and innovation in the industry.

Widely recognised as key to the successful preservation of production systems, the ITSM processes of Change, Config and Release are perceived as pivotal to maintaining the integrity and stability of the IT environment.

Flow diagram showing the five areas of Change, Config and Release.  These will not always be used in order and Auditing and Reporting should be ongoing.
Flow diagram showing the five areas of Change, Config and Release. These will not always be used in order and Auditing and Reporting should be ongoing.

In a nutshell:

Change Management is the process used to track and communicate any changes in service that may impact the customer such as when systems are taken offline for updates.

Configuration Management is the process used to track individual CI’s (Configuration Items) and the way in which they interact with one another.

Release Management is the process of managing software releases from development right through to release.

Each process can be used individually but more often than not you will find these processes intertwined.  When considering either a Change or Release you will need to know the CI’s that will be affected before you begin.

E.g: Your organisation needs to upgrade your in-house software package to all of its desktop pc’s, tablet devices and kiosks.

Release Management is used to track the in-house development of the software in question, Config management is used to scope the number of devices, number of people and types of people affected while Change Management is used to ensure the changes take place on a date that will cause the least disruption and that the why, how and when the changes will take place are communicated to the relevant people.

The criteria we will be using for our assessment is published below.


Identification

  • Ability to maintain a detailed record of each system’s configuration
  • Ability to interface with all internal Management Data Repositories (MDR) allowing the tool to compare reported configuration with actual configuration stored in the MDR
  • Ability to define dependency relationships between CIs
  • Ability to assign maintenance windows to CIs
  • Ability to auto discover CIs
  • Ability to interface with Inventory Control tools (to automate gathering of asset and inventory information) and barcode scanners
  • Ability to create automated alerts when a CI is found to be in an unauthorised state
  • Ability to link Release records to Change records
  • Ability to provide a Change/Release calendar with scheduled change viewing by group, and to customize the sorting and filtering of calendar views and link to existing calendar products

 Assessment/Approval

  • Calculate an objective risk assessment considering business impact and affected services
  • Show logical links between components included in a service in order to carry out business impact analysis
  • Ability to automatically create a Change Request when unauthorised changes are made to CI’s
  • Ability to schedule recurring events and maintenance
  • Ability to create and select pre-approved Change/Release from a pre-defined list
  • Pre-determined fields to auto-populate when Standard Change/Release from list used
  • Ability to capture the Change/Release date and time and who will be responsible for implementation
  • Ability to automatically send approval requests to the appropriate approvers
  • Ability to notify the assignee of the task and due date
  • Ability to link resources/approvers to Changes/Releases
  • Ability to assign tasks to individuals to be accomplished within specific time frames
  • Ability to alert Change/Release managers when approvals are past due
  • Ability to change status of Change/Release approvals
  • Ability to easily identify scheduling conflicts and reschedule appropriately

 Implementation

  • Ability to attach and store documentation with a Change/Release record
  • Ability to authorize and schedule Release deployments in conjunction with Change Management processes
  • Ability to change status of Release and linked Changes
  • Automatic notification for scheduled start/end and when the status of a Change associated with a Release changes
  • Ability to build, bundle and schedule different types of release packages for deployment
  • Ability to change status of Change/Release documentation
  • Ability to create sub activities or tasks for separate assignment to an individual, group or vendor
  • Ability to version release components and packages
  • Ability to assign tasks to teams/resolver groups

Accountability

  • Ability to track the physical location of contracts and agreements, and identify the individuals responsible for them
  • Ability to define Change and Release Windows (including freeze windows)
  • Ability to document back-out procedures
  • Ability to ensure that Release deployments are subject to scheduling and approval requirements managed by the Change management process
  • Ability to provide proactive notification to stakeholders and Change Advisory Board (CAB) members for Changes with critical business impact and provide fully configurable filtered views of scheduled changes to multiple stakeholders
  • Ability to designate back up approvers
  • Ability to set thresholds for automated approval process
  • History of approval requests logged

Auditing/Reporting

  • Ability to easily identify affected CIs whenever a change is made
  • Ability to maintain an audit trail of changes made to a CI
  • Ability to track Asset status and lifecycle management
  • Support of multiple software audit options
  • Ability to perform software license management including automated notification of license expiration and non-compliance
  • Ability to create and publish a Master Release Schedule
  • Ability to associate the Master Release Schedule with Service Level Agreement information
  • Ability to store approver comments with the approval, and store approval history for a Release
  • Ability to track and trace post deployment activities
  • Ability to trace implementation to the authorized version in the Document Management Library (DML)
  • Bulk import of licensing data
  • Ability to track costs of CI’s

General/Other Criteria

  • Alignment with industry frameworks
  • Ability to support a “virtual” CAB (i.e. approvals/issues stored electronically)
  • User-configurable forms, tables, workflows, dashboards
  • Role-based access for approvals, retracting or rescheduling RFC’s/Release
  • Open system for real-time integration with financial management and other monitoring tools
  • Provision of templates and pre-filled forms and structure to act as basic starting point
  • Vendors should provide expertise and guidance in the implementation of the tool and relevant processes

If you would like to comment on the above criteria or if you are a vendor and would like to be included in this review please comment below or contact me via email.

Is Darth Vadar in your ITSM project?

darthWhen I started my current role of Total Quality Manager, my CIO lovingly dubbed me “Darth Vader”.

In his view, Darth is the ultimate project manager and the CIO wanted the same qualities in me.

The CIO needed me to brutally prioritize tasks, make decisions based on data, honor commitments, manage risk, be persuasive, take on the big problems, and not be afraid to get my hands dirty.

Recently, the CIO asked me to morph out of Vader mode, so I thought I would take opportunity to reflect back on Vader moments in an ITSM project.

Don’t be too proud of this technological terror you’ve constructed

A lesson early on, an ITSM project is not about technology. The technology will only be as good as the process constructed. If your incident management process does not work when you execute it on paper, adding any technology is just going to accelerate the pain. Remember to include your stakeholder in the design and to put people first. Even if the process does not work, the people, if you have gained their trust, will quickly find a good workaround and help improve the next iteration.

Lesson Learned: Involve stakeholders and communicate intent. Use technology to accelerate good processes

Don’t underestimate the Force

As with any project, you will have your Jedi and Sith plus a lot of people simply trying to get through the rebellion. Dealing with Jedi and Sith is the easy part. The “political” alignment is easy to spot and understand. For me, the Jedi are teammates who help lead the “we’re not changing” attitude (i.e. the ITSM rebellion). While my Sith brethren actively and proudly helped build the “Death Star” (i.e ITSM processes).

The difficulty in my ITSM project was dealing with the “just trying to get through” crowd. We had:

  • Uncle Owen – wanted nothing to do with the rebellion (“just leave things alone”)
  • Greedo and Boba Fett (bounty hunters) –  worked to “take out” new process and changes
  • Droids (but not C-3PO or R2-D2) – folks you really could not communicate with and simply seemed to be focused on doing the next programmed task
  • Lando Calrissian – people who seemed to be on your side but you still are unsure of their motives
  • Admiral Ackbar – people who kept reminding others the project is “a trap”

This group is easily swayed by the Force and Jedi mind tricks from the Jedi and Sith. As we all know, the Force in our organizations is culture, and this is what binds everything together. Small shifts in the Force can lead to misunderstandings and misinterpretations.

Need an example? Ever brought up an idea, just as a concept, with no intent of doing anything more than creating a discussion and suddenly you are fielding questions/comments/concerns about this idea? “When are we doing this?” “Nobody discussed this with me!” “You just can’t decide on your own to change my job” If you dig a little, you find members of the Jedi used the Force and Jedi mind tricks to build FUD and sometimes to derail the work.

Lesson Learned: There is a fine balance of culture in an organization. Little things (changes, ideas) may not upset the balance but a buildup of little things can cause a great disturbance. A lot of change can happen, sometimes quickly. Keep communication channels open. Let people express their concerns and take each concern seriously. Work to displace FUD.

And now, your highness, we will discuss the location of your hidden rebel base…

I knew we had “shadow systems” running in our support environment. Proving it, along with the issues caused, was difficult. We got to a point where we started asking, “If a shadow system works (really) well, should you disrupt it just because you are adopting a service management framework?”

We tackled this issue by talking to our Service Owners and finding out why the system was in place. In several cases, it was simply old design and the system worked so well, nobody felt there was an issue to address. We used the ISO/IEC 20000 standards to help determine if the system met the level of quality we desired. If it did, we worked to formalize the process. If not, we worked to transition to an appropriate process. Along the way, we continued to build trust and fight Jedi.

Lesson Learned: If something works well, meets your goals, and satisfies customers, stick with it.

You are part of the Rebel Alliance and a traitor!

Confronting those who actively worked to disrupt the project is one of the most difficult and challenging aspects of the job. In any project, you must understand the FUD statements. Determine why your colleague(s) feel this way. It is important to listen carefully. Find out why they perceive the project as a “threat” to their job/career/lifestyle. Make sure you address why they feel they way they do.

Lesson Learned: LISTEN. Use crucial conversations. Remember, we’re all in this together.

What is thy bidding, my master?

You will receive many opinions while managing an ITSM adoption project. Keep in mind two things:

  • You are charged with getting the project to completion
  • Know who charged you to get this done.

Comedian Jerry Clower tells a story where he was hired to perform at a show. When Jerry walked into the theater, the lighting director walked up and asked “Mr. Clower, how would you like the lights tonight?” Jerry thinks for a moment and then responds, “Son, I don’t know. You’re a professional. Just make everything look as good as you can.”

Next, the makeup artist asks Jerry, “How would you like your makeup done?” Jerry responds with “You know, you ain’t got a lot to work with…just make me look as good as possible. I trust you”.

Finally, the manager of the theater asks, “Mr. Clower, would you mind coming through the audience and shaking hands as you come on stage?” Jerry responds with “Sir, it would be my pleasure to do so!” The manager pauses for a moment and then says “Mr. Clower, I’ve been talking with my staff. All of them tell me you are so friendly and trusting of their abilities. We get a lot of artists in here who just are not that way. Why are you so different?”

Jerry looks the manger dead in the eye and responds, “Son, did you forget? You hired me.”

The point of the story – don’t forget who you work for. The CIO wants this project done. Know the reasons why. Also, know and understand the level of support from the executive team, the service owners, and process owners. Everyone has to be on the same page for this to work.

Lesson Learned: It takes a village to adopt ITSM. Know the key reasons for the project. Know the stakeholders and their expectations. Remember who you work for. 

May the Force be with you

Finally, here are some additional thoughts:

  • You may be Darth Vader in your project. Just remember to stay true to people first then the project. Don’t give into the Dark Side.
  • Search your feelings – Always use as much data as you can but don’t forget to use intuition and the counsel of others to help make decisions.
  • “I’m altering the deal. Pray I don’t alter it any further” – Remember, it’s a project. It’s not a recipe, cookbook or set of instructions. Know the scope of your efforts and be flexible as possible without compromising the quality of the project.

Can you relate to this? Which Star Wars character are you when it comes to your ITSM project?

Image Credit

Applying Agile principles to Service Management

rabbits
“A man who chases two rabbits catches none.”

Regular readers of my blog on The ITSM Review, or over at ScrumProUK know that I enjoy exploring the gap between the worlds of IT Service Management and Agile development methodologies.

Today I wanted to go back to basics, back to square one and start over by explaining why you – as a reader from the world of Service Management or corporate IT – should care about Agile principles and what it can bring to your organisation.

I’m glad to see one commonly held misconception being broken down and disproven recently. The assumption that an organisation cannot be both Agile and IT Service Management orientated.

Even the oldest, most stubborn and most skeptical of Agile critics (his words!!) are coming around to the idea that an organisation that can excel at both disciplines. Hurrah. There is a growing Google+ community dedicated to it – Kamu: Uniting DevOps and ITSM.

To introduce principles to those that are unfamiliar, I’m taking inspiration from Tobias Mayer who identified 5 benefits of Agile (in this particular case Scrum) that will help me orientate you.

Focus

“A man who chases two rabbits catches none.” ~ Roman Proverb

A core principle of popular Agile methodologies such as Scrum and Kanban is to limit Work in progress. Scrum teams, for example, will agree to take on a small subset of work from the overall backlog within a timeboxed period, normally between 2 and 4 weeks.

By limiting the teams focus and attention on what is most important you enable them to complete work to the appropriate quality standards; and by limiting work in progress we train teams to finish work, rather than start additional work. With focus comes attention to detail and less mistakes, a higher level of quality and ultimately happier customers.

Look around your IT department today as you read this article. Do you see teams that have more work than they can handle? (Probably). Do those teams have a clear understanding of what is most important (probably not)?

How can Service Management teams adopt the Agile principle of providing focus for their teams?

Start by understanding your work. Where does it come from? How does work arrive in your department. Visualise your work by using a tool like LeanKit, Trello or Kanbanize (all have free editions for you to try). Use one of these tools to identify which work items are the most important and challenge the team to finish those items.

By reducing the scope of work that a team is paying attention to you’ll see a change in behaviour, delivery time and quality.

Alignment

“What if we found ourselves building something that nobody wanted? In that case what did it matter if we built it on time and on budget….” ~ Eric Ries, The Lean Startup

Agile teams work with the principle that plans will change; that we will understand more about the work once we near completion and that no amount of planning really prepares us for the road ahead.

This is true for software development projects where Agile is accepted but of course it’s also true for IT maintenance and operational projects too. How many of your projects delivered exactly as predicted on day one?

Knowing that business requirements will change frequently and that the assumptions made before work begins are normally wrong, Agile teams handle this by working in iterations.

By planning months into the future with “just enough” detail and by focusing in granular detail on only the next 2 week sprint, a team can easily absorb changing business requirements.

By meeting with the business on a frequent basis, by examining the overall plan (in coarse detail) and by re-prioritising against the current business requirements Agile teams achieve alignment with the business. They can plan for the next iteration in detail knowing they are working on the most important thing based on todays knowledge.

It’s no use being perfectly aligned at the start of the project and not having a system to cope with the ever changing demands. Changing requirements in a project are a good thing – it means we will have a better solution in the end.

Do your IT project teams try and control changing requirements… do you welcome them?

How can Service Management teams achieve alignment with the business?

By structuring work so that teams can focus in the short term but change direction to react to business demands. For Service Management teams this might mean short term focus on a set of metric goals to solve a particular business problem. Just having the routine of sitting with the business and reviewing priorities is a great first step.

Artful making

“I don’t test my code often but when I do I do it in production” ~ Internet meme

Earlier I mentioned Focus as a principle of Agile teams and that by concentrating on a small subset of work that is most important to the business we can train teams to deliver. Rather than having lots of work open and diluting the teams attention.

There’s another benefit in limiting Work In Progress with regards to quality engineering. Imagine a team that has no control over its work and everything is urgent. The team has no Focus and no Alignment with the business – no understanding of what is truly important.

That team is likely to produce low quality work. By trying to complete everything at once they’ll often do just enough to call it done. This results in risk lurking in your infrastructure; the worst kind of work that will leap out on you when you aren’t expecting it. Work you thought was done… but isn’t. Rework!!

Agile teams use the system of limited WIP as well as technical practices and standards to get work done once so they can move on to the next task.

Could you improve the quality of work by defining standards and shielding your team by limiting work in progress?

How can Service Management team promote artful making?

Have a “Definition of Done” for common activities. Not a huge, heavy operations manual that no-one will ever read but a collection of one-page definitions of what it means to be done with a server build, a software installation, a Problem ticket.

Make the definition of done visible and easy to use, your engineers will know when they are finished with a piece of work before moving on.

Self-organization

“None of us is as smart as all of us.” ~ Kenneth H. Blanchard

The best architectures, requirements, and designs emerge from self-organizing teams. Teams that are not controlled but enabled. Teams that stay together long enough to form an esprit-de-corps and that trust each other enough to have passionate debate and disagreement without destroying the teams culture.

The worst experience that an engineer can have is to be presented work that was designed by someone else, work that has no scope for flexibility or creativity, and worst of all to be told how long it will take.

Have you ever worked on a project where the scope, implementation and deadline were predetermined by those that aren’t actually going to do the work? How does that even happen??

Agile teams are self-organising within the constraints of the organisation in which they operate. They receive requirements that describe the business need (The “WHY”) and acceptance criteria (“The WHAT”) and they, as a team, determine the solution (The “HOW”).

Self-organising teams scale much better than command-and-control style teams, where a manager delegates and defines the work.

Why would you want to have your expensive managers involved in assigning tasks and resource levelling? Members of a self-organising team know when they have spare capacity for more work and they pull work into their queue.

How can Service Management teams become more self-organising?

I think this is a simple one – do you have managers that delegate work or leaders that coach teams to success? If you have the former is that the best use of their time and skills? Give the team an opportunity to own their work and determine their own destiny, within the constraints of your organisation.

This loss of control by managers might result in a team more invested in its success, more motivated and higher performing.

Rhythm

“Rhythm is something you either have or don’t have, but when you have it, you have it all over.” ~ Elvis Presley

Agile teams are focused on the regular delivery of value into the businesses they serve. By limiting work to sprints, usually between 2 and 4 weeks long, they are able to continuously deliver work building a partnership based on trust.

elvisBecause they focus on a subset of all possible work and they have quality standards they can deliver work of a high quality which deepens that trust.

Short time-boxes focus teams on an objective they have to meet – by self-organising they control the scope of work that is achievable within that sprint. When I started delivering work to a company using Scrum I asked my stakeholders which attribute of the work they valued most.

Was it the speed or the volume of work, or the number of features we delivered? No – organisations rely on predictability and working in set time-boxes, or sprints, makes your team predictable.

Compare this to projects that defer the delivery of value until the end of the project. Rather than release early and often they buffer the features and aim to deliver all in one large batch.

If that deadline is delayed two unfortunate things happen – firstly trust between the team and the business is eroded. And secondly the value represented in the features that are done but not released cannot be realised until all work is delivered.

Do you have a trust between the IT organisation and the business which is built upon a rhythm of regularly delivered work?

How can Service Management teams get that sense of rhythm?

I love the idea of working within constraints. It focuses the mind and makes people be creative. Even if you don’t work in software engineering define a series of 2 week “sprints” for your Service Management team.

Declare an objective for the two week sprint – “we are going to reduce the incident backlog to under 50”. Let the team self-organise and think about your teams objective for the next sprint.

In summary

Thanks for Tobias for his 5 attributes of Agile teams that I’ve expanded and commented upon. My aim here was to outline the benefits of Agile to teams outside of the world of software development. I hope that readers that work in IT Operations and engineering can compare the way they work currently against these ideals – all of which are simple and cheap to implement and realise.

Ultimately the ideas of focus, alignment, artful making, self-organisation and rhythm promotes a culture of learning – about the work you handle, about how the team performs and how you interact with the business.

Combine these 5 principles with the idea of regular, structured retrospection and I think you are well on the way to having a highly performing team.

I would love to have a discussion with you in the comments or on Twitter. Or come to the Kamu Google+ group and discuss with your peers there.

Image Credit 1

Image Credit 2