Configuration Management How To (Part 2)

Following on from our previous article, this week we’ll take a look at Configuration Management baselining and control.

Configuration Baselining


First up we have the identification or baselining step in our Configuration Management process. This is a baselining process, taking a snapshot of our critical services and their key dependencies so that we know exactly what makes up the service. The purpose of a baseline is to take a measurable part of the service so that it can be added to a CMDB (Configuration Management Database) or CMS (Configuration Management System). As it’s a snapshot of the state of a service at a point in time, it can be used as part of Change Management as if the service has changed there will need to be a valid, authorised RFC against it as well as being a stable reference for future planned works.

So how do you carry out a baselining exercise in real life? My advice? Start with your most critical service. You know the one. The system that if there is even a hint of slowness or performance issues your Service Desk is inundated with calls and the angry mob are off out finding their flaming torches and pitchforks. That’s the one. Start by talking to everyone involved with the service from support teams to the business. If it requires third party support, consider asking your supplier for their guidance for what data should be captured in a CMS for example if you ever need to log a support call with them, what are the top ten things they will ask for?

Don’t try to capture too much data at first – you can always build things up later but if you try to go into too much detail when starting out you might run out of time and money. Also bear in mind, the more detail you capture, the more work it will be to maintain. As a starter for ten, here are some useful CI attributes to capture:

  • Unique Identifier
  • CI type eg server, network device, software package
  • Version Number
  • Support Details
  • Vendor Details
  • Licence Details
  • Purchase Date
  • Owner
  • Location
  • Warranty Details
  • Relationships to other CIs

You also don’t necessarily need an expensive tool – I used to work for a small bank during its UK start up and the IT budget was really tight. We desperately needed a CMS to support Incident and Change Management but didn’t have a tool. I went round to every support team and techie I could find and used a spreadsheet to build up a basic CMDB of our key services then created a business case over the following few months to demonstrate the benefits (I was able to demonstrate tangible reductions in Change failures and Incident resolution times) to secure funding for an ITSM tool that included a CMDB.

Remember any CMDB, no matter how basic, is better than nothing. If you are going down the spreadsheet route then talk to your techies. If discovery tools such as SMS or Alteris are in place then they could be used to help you build a basic CMDB.

Configuration Control


Configuration Control goes hand in hand with Configuration identification and baselining. Having control in place means that there is appropriate support in place to ensure that when a CI (Configuration Item) is updated, that the CMS is updated so that what you have in the CMS matches exactly what you have in your production environment. Nothing will make your Configuration Management process fail quicker than your CMS having incorrect or out of date information so control is a critical aspect of Configuration Management.

Work closely with Change Management to make sure your processes are aligned; for example you could put a process step in place where a Change can only be closed off as successful when the CMS is updated. Sounds basic I know but you would be amazed at how many times I’ve seen people forget to update documentation following Change activity so if you have it formally built in to the process, nothing can be missed or forgotten about. Also, if you’re not part of the CAB meeting, get yourself invited so you can add subject matter expertise around service relationships and dependencies during impact assessments.

Work with Change Management to consider putting Change freezes in place during key process points such as baselining or audit exercises so you’re not trying to hit a moving target. Believe me, there is nothing more stressful in an audit situation than having a last minute panic about the version information of a CI being up to date following a Release the previous night.

These are our top tips for Configuration baselining and control. What do you think? Let us know in the comments!


Image Credit

Image Credit

Trains, planes, giant inflatable elephants & Yoda – Service Manager Day 2016!

It’s Utrecht Baby! National Service Manager Day is an annual event hosted by the NGI-NGN organisation in Holland. The NGI-NGN are the Dutch professional association for ICT professionals and managers. It is an independent platform where more than 2,500 members deepen their knowledge and maintain their network. Here’s our take on the big day.

Opening Keynote: The Future Of ITSM – David Cannon, Forrester

David kicked off the day in style with his take on the future of ITSM. David started off by outlining some of the challenges the ITSM community currently face telling his audience: “our customers drive innovation and that innovation is growing. We need to look at new ways to enable our customers.”

He continued by explaining that as ITSM professionals, we need to innovate “customers expect us to know all about them without them having to tell us” whilst keeping the lights on.

David went on to explain the our customers will continue to expect innovation something I completely agree with. Lets face it, we live in the world of Amazon, Facebook and Google – shouldn’t everything be that easy?

The next part of David’s presentation focused on the innovation cycle. David explained this by using the Google Maps example “Remember the first version of Google Maps? Best practice was to follow the directions then walk around for a bit until you found your destination. Nowadays if Google Maps doesn’t deliver you to the front door of the address you entered you get mad at them; ie innovation has met operation and IT needs to move from innovation to commodisation”. David also spoke about the need to manage technical debt explaining “We need to manage our services so that we can cover services throughout their lifecycle not just the first eighteen months. We must ensure money spent on operational systems to the original value proposition because if we don’t, we will only ever be associated with costing the business money”.

The final part of the session focused on practical advice. David explained that the focus has changed “It doesn’t matter what you call it, build and run must happen at the same time. The support model has changed, with the advent of genius bars customers want to know how they can use the technology they’ve got to do something new.” David used an Apple example to explain this “Apple have used genius bars to transform the worst part of a user experience, a broken device, into a real selling point”.

David concluded on this note “We need to learn the language of return on investment as a service manager – everything else is irrelevant.”


Next up was Christian Tijsmans on how Service Management can change your life. As someone who’s been in ITSM since I moved to the UK in 2000 I was all ears. Christian opened his session by talking about the only metric that should really matter – the personal happiness index.

Christian’s take on CSI is Continual Personal Improvement taking the audience on his journey from baseline to getting there and keeping the momentum going.

One of Christian’s key word of wisdom? Take accountability; or as he put it “stop starting things and start finishing things.”

Christian gave practical examples of how using KanBan and COBIT can make us more effective as well as the importance of planning and remaining agile:

My favourite part of the presentation was Christians reminder that people are everything “keep people at the forefront of your journey; Peter Pan needed belief to fly”



Minds out of the gutter people! This was Claire’s fab take on all things cyber resilience. The first part of Claire’s session focused on current threats:

Claire talked about how easy it is to accidentally compromise security telling the audience “50% of users will click on links from phishing e-mails, sobering stuff. Claire went on to explain why everyone is responsible for cyber safety – poor old Dave though!

The main part of Claire’s session focused on sorting out our cyber resilience. She started by introducing #RESILIA. RESILIA is the new framework for cyber resilience. It’s aim is to build cyber resilience in an organisation from the boardroom down. The RESILA framework provides practical guidance on:

  • Organisation wide awareness training
  • Cyber pathway tool
  • Leadership engagement
  • A certification pathway

Claire talked about how important it is to integrate cyber resilience into IT Service Management explaining “we need to integrate security into every one of our ITSM processes”. As a starting point; “use your experts to get security going in your organisation – stop hiding them away!” Getting buy in is a critical part of any security policy and as Claire put it “make senior management walk the walk” I completely agree. Let’s face it – how are you going to get end users to follow security procedures if all they see is senior management breaching them left right and center.

Claire went on to talk about the importance of training that engages the audience telling us “E learning where the person goes away and has a cup of tea while it plays then ticks the box at the end doesn’t work”.

Claire’s final slide gave the audience some key takeaways to consider including:

  • Risk Management
  • Knowing your critical information assets
  • Making a plan

Claire finished by signposting everyone to the official RESILIA website where the Cyber Pathway will be available free of charge next month.

The radical impact of DevOps on IT Service Management – Charles Betz

Following a quick power break with the world’s most awesome cake selection Charles Betz was up as the afternoon keynote talking about the impact of DevOps on ITSM.

Charles opened by talking about digital transformation as a driver of Agile and DevOps “Agile is transformative and descending on our organisations at speed”.  He talked about the challenges that the ITSM world is currently facing:

He went on to talk about the substantial benefits a DevOps environment can bring, if done correctly.

He talked about what to do if you bump into a scaling problem:

As well as referencing the work done by Donald Reinertsen on product development flow.

Charles talked about the need to speed up feedback loops and reduce the cost of delay explaining “a nine month Release cycle won’t work in a digitised environment”. I’ve talked before about Amazon’s release cycle; deploying new code every 11.6 seconds – can you imagine telling the CEO of Amazon that he could only have one Release every nine months? No. Nope. Nopity Nope, No.

The final part of the session looked at finding leverage points to get buy in and support. Charles suggested automation, shared services, and challenging over-elaborated processes. In the words of organiser Dave van Herpen

It’s all about the services: Implementing a Service Portfolio – Nelli Serifovski, NNIT

The final session we attended was by Nelli Serifovski. Nelli’s session was all about using the Service Portfolio to drive value and was based on her practical experience of implementing Service Portfolio Management across NNIT; one of Denmark’s largest IT services providers.

Why a Service Portfolio instead of a Service Catalogue I hear you ask? Let me explain. A Service Catalogue is essentially a menu of all live services available to the business. It can have different views based on the role you’re in (e.g business and technical views) and gives you a view of all services. A Service portfolio is so much more. It’s made up of three components;

  • The Service Pipeline
  • The Service Catalogue
  • Retired Services

The Service Pipeline gives you a view of services that will be launched in the future; a sort of preview of coming attractions if you will. The Retired Services section keeps a log of all legacy services that you used to support and the Catalogue is your basic menu of what’s available now. So if your Service Catalogue is a menu, The Service Portfolio gives you the past, the present and the future.

Nelli’s session was full of practical advice on implementing Service Portfolio Management from the first attempt “no one wants to read a 600 page Service Catalogue” to the final version with an impressive benefit realisation.

Nelli talked about the need for governance explaining that  dedicated roles and responsibilities from service owners to solution architects  were key. Nelli outlined the cost model and planning involved sharing that every service delivery manager had to create a service plan replacing 20 odd services status with five across the company.

Nelli finished by sharing her key learnings and this final message “You need to keep working and improving. Service Portfolio Management never ends!”

For our money Service Manager Day was brilliant; informative, empowering and inspirational. This tweet summed up the day perfectly:

A huge thank you to the NGI-NGN for inviting us and we hope to be back next year.


Image Credit

Configuration Management How To (Part 1)

Overview Of Service Asset & Configuration Management

Service Asset & Configuration Management (SACM) is the process responsible for ensuring that the assets required to deliver services are properly controlled, and that accurate and reliable information about those assets is available when and where it is needed. This information includes details of how the assets have been configured and the relationships between assets.

Done correctly, Configuration Management is a key enabler for resolving Incidents, identifying the root cause of Problems, impact assessing Changes and building the technical layer of a Service Catalogue. It’s also the process that tends to make people panic because of all the databases, information systems and scary terminology; so here is our panic free guide to Configuration Management. Configuration Management is made up of the following steps and we will look at each one in turn:

  • Planning
  • Identification (Baselining)
  • Control
  • Status Accounting
  • Verification

Configuration Planning

7802754212_0fd2e22154_zLet’s start with the basics. Configuration Management is one of those processes where you really, really need to have a plan. I’m not talking any old plan either; I’m talking Hannibal from the A Team level planning. Why is planning so important? One of the biggest reasons Configuration Management fails is because people try to do too much so setting the process scope is a key activity.

Let’s start with the inventory layer. Inventory Management takes care of consumables; keyboard, mice, USB sticks and SecureID cards. Stuff that needs to be tracked for monetary value and to make sure it’s in stock but that’s about it. The next layer is Asset Management. Examples of assets include PC’s, Laptops and printers. Stuff that we need to keep track of for monetary reasons, to make sure they’re in stock when needed, locational info and how they are supported. The final layer is Configuration Management. Items under the control of Configuration Management (CIs) are the big chunky items that make up your critical services. Servers, network devices and software applications should all be under the control of Configuration Management to make sure they are managed, supported and subject to the appropriate Change control.

The plan should also explain any naming conventions or nomenclature. Confused? Every CI or item that is under the control of Configuration Management should have a unique name or identifier. When I’m tasked with implementing a Configuration Management process from scratch I try to use a naming model that will make it easy for the CI to be identified so I tend to use the following:

Type of Service – Location – Level of Complexity

So a WinTel server based in Dublin requiring third line support would be WinTel1234 – DUB – L3 and a business spreadsheet located in London requiring first line support would be Exl-LON-L1 and so on. In terms of naming conventions; it doesn’t matter what framework you use, as long as everything has a unique identifier. When I worked for an investment bank in London, the naming convention was food based so all WinTel servers were named after Italian food, all UNIX servers were named after Chinese food. Another example is from a firm that I worked for in Reading; all WinTel servers were named after characters from Terry Pratchett books and all Network devices were named after monsters from ancient Greek mythology. Both worked really well and as an Incident Manager it was pretty hard to get stressed during a Major Incident when someone shouted Rincewind’s fallen over again!

The plan should include a reference section. When you’re building a CMDB you will be talking to support teams, service architects and project managers. Ensure that you capture the source of the information whether it be from a Service Catalogue, support documentation or even from SLAs so that it can be verified before it’s placed in your CMDB.

Does your organisation have a Configuration plan? Let us know in the comments!


ConfigEnterprise Service Management Webinar Module 3: CONFIGURATION MANAGEMENT

Don’t forget to join us for our 3rd webinar of the series – Configuration Management on 31st March, 2pm GMT. Register here!


Image Credit

The Holy Trinity of IT Service Management


People, technology and process are the compounds that construct the IT Service Management triumvirate. Having already identified the technology trends, and in particular how predictive analytics will impact incident management, what can we say about the other two members of this very exclusive club?

While process tends to lead the way, it needs people to champion it, and technology to support it. Technology, in the grand scheme of things, tends to be the easiest part to implement as long as it exists and is fit for purpose.

Low level detection

The ability to detect and avoid incidents isn’t something that’s included in the ITIL manual. We could spin it into something to do with Continual Service Improvement, but activities in this area tend to be run on a project basis. They are in effect more likely to be elements of a change programme.

So what can be done when dealing with information relating to the future at such a granular level on a daily basis? The simplest thing would be to treat predictive events as actual incidents, pop them into a team’s queue and let them deal with them alongside everything else.

But what priority should they be given? The predicted incident can’t be high as nothing is broken, and nobody is screaming. On the other hand, if they are treated as a low priority, the issue may never be dealt with in a timeframe that permits the incident to be avoided. Medium, then? Perhaps not, as if the resolution requires additional spend then you need to conform to a purchasing timeframe and once again the benefit of being able to avoid a failure, may be lost.

The answer, unsurprisingly, is that it depends. It will depend on the organisation and how mature its processes are, how stable its services are, and its attitude to risk.

A stitch in time?

How many organisations will zealously fund proactive remedial work? Securing the budget to keep things in a current and supported state is difficult and at times impossible. I’m sure every organisation has a server somewhere that has effectively been shrink wrapped as it is no longer supportable and needs to be kept as protected from change as much as possible, as the service it supports provides good, perhaps even essential value to the business.

It is unlikely that an IT department will be given a blank cheque book to allow it to respond to predicted events. Does this mean that that things will knowingly be left to fail?

Therein lies another people aspect. How are IT Service Management staff rewarded?

Fire fighter or keeper of the peace?

If services operate without issue the IT department becomes the focus of cost cutting.

If on the other hand systems fail, all thanks are given to those that worked tirelessly through the night, surviving only on pizzas and vending machine coffee. Like or lump it, the reality is that in these types of scenarios, those that are seen to be doing are those that progress.

IT has a very real culture of martyrdom embedded within it that will be difficult to change.

Of course there will still be unexpected incidents that can’t be predicted but in a world where we can now identify and avoid incident there needs to be a balance that encourages and rewards the proactive as much as the reactive.

Different thinking is needed together with a different reward structure. Pavlov discovered long ago that you have to reward the behaviours you want.

Are your service team keeping the peace or fighting fires? I’d suggest you want people calmly going about their business to let business go about business. Avoiding the avoidable helps them to do just that.

Screen Shot 2016-03-11 at 11.42.51


This article was contributed by Stuart Higgins, Technical Evangelist at Sumerian


Image credit

BEYOND20 SIXTEEN: Automating Change Control

Ahead of the BEYOND20 SIXTEEN ITSM and DevOps conference in May, I was lucky enough to catch up with Sherry Chang of Intel to talk about her session; Automating Change Control.


Preview of forthcoming attractions:

Sherry’s session will look at how automation can transform a Change process from blocker to key enabler. During the presentation, Sherry will look at how automation can support the Standard Change model to enable more Changes to pass through the service pipeline without sacrificing effectiveness, quality or safety. For those of you who are new to the Standard Change model they are simply pre assessed, pre authorised activities that are low risk, relatively common and follow an agreed procedure or work instruction. So far so good right?

Sherry will give practical guidance on setting up your organisation to follow the Standard Change approach and will look at how these virtual quality gates can work as a more efficient approach to Change volumes over human scrutiny. As DevOps becomes the more preferred way of delivering value, Automated Governance will become more and more important in driving Continuous Delivery; Sherry’s aim is to empower attendees by sharing tips, tricks and case studies in making Change quick, effective and successful.

You should attend this session if:

You want an action packed, practitioner overview of how to move to a more Continuous Delivery stream using Standard Changes.

The official bit:

The conference overview of Sherry’s session is below:

‘Change Management and Continuous Delivery are commonly viewed as incompatible.   Gates imposed by Change Control Board often slows down any velocity gain achieved by Continuous Delivery.   However, control and velocity can be achieved by automation.  Attend this session to learn how you can achieve higher velocity, better scrutiny, and comprehensive audit trail with Automated Governance.’


Image Credit

Featured Image Credit

Release Management How To (Part 3)

Following on from our previous posts; here is our final article in the series of how to do Release Management in real life.

Distribution & Installation

Unfortunately actually deploying a Release is not as easy as this:

Releases should be deployed to the live environment in accordance with the existing Release Management policy. For software releases it’s a good idea to use automation where possible as it will lessen the impact on support teams, decrease the time of the release and reduce the likelihood of human error.

If the Release has to be deployed without automation, then the release implementation plan should contain detailed instructions for deployment, resources, timings, escalations and contact details. An example release plan could include the following details:

Example Release Timeline: Commercial Website Deployment

Pre-requisites that must be carried out the day before the release:

(1)   Development must provide the release notes to the Release Manager and all resources on the timeline by 17:00 the day before the release.

(2)   Development must provide the Release Manager with business sign off by 17:00 the day before the release.

(3)   Release Manager must raise a corresponding change record for the release and ensure that it has been approved at the CAB.

Reference Number 1234 – Commercial Website Release – Date
Time Action Resource
10:00 Divert all website traffic to the DR web servers.

**Communication checkpoint to Windows Team ***

Joe Bloggs – Network Team
10:30 Commercial Web amendments for Production web servers Jane Doe -Windows Team
11:30 Testing & Validation


**Communication checkpoint to Network resource**

A. N. Other -Web Team
12:00 Divert all traffic to the Production web servers & Stop DR web server traffic.

**Communication checkpoint to Windows Team.

Joe Bloggs – Network Team
12:30 Commercial Web amendments for DR web servers Jane Doe -Windows Team
13:30 Testing & Validation


**Communication checkpoint to Network resource**

A. N. Other -Web Team
14:00 Normalise network traffic to all web servers Joe Bloggs – Network Team
14:15 **Communication to Release & Change Management about the release status ** A. N. Other -Web Team

Escalation Point: IT Services Manager, IT Services Senior Manager

Contact details:

Name Desk Number Mobile Number Email Address

Early Life Support


It’s really important to make sure all Releases have the appropriate support in place immediately after implementation. In the words of Rob England at #PINK16 “we need to avoid dead cat syndrome; aka as the Dev guys chucking something over the fence into production and expecting the Ops guys to make it work seamlessly”.

It may be useful to introduce an “intensive care period” whereby extra support resources are available for a period after the Release to ensure that resources are in place to troubleshoot any issues immediately. Floor walkers made up of Service Desk and Support Staff could be used to support users on the morning of the Release. This intensive care period could be tracked via a short daily meeting or conference call and attendees should include:

  • Release Management
  • Change Management
  • Service Desk Management
  • Problem Management
  • Support Representatives
  • Business Representatives

Again, this isn’t about red tape, it’s about making sure everything is as it should be and that any issues are caught early and zapped rather than be allowed to spiral out of control.

A Warranty period could be built into the Release whereby the new functionality is supported by the development team until 2 weeks after the Release has been deployed, providing there are no outstanding Major Incidents or Problems associated with the Release. The Release Management policy should include provision for warranty periods and guidelines for transition into BAU activities.

Review & Close


A post implementation review  should be held after each release to track any outstanding actions and to document any lessons learned. Inputs to a post implementation review could include:

  • Incidents associated with the release
  • Problems and Known Errors associated with the release
  • Issues log (if using PRINCE2 as a project methodology to manage the release)
  • Change and Release Management feedback
  • Customer Satisfaction Ratings
  • Customer complaints and compliments

Outputs from the post implementation review will include:

  • Lessons learned log
  • Known Errors and workarounds
  • Confirmation that the CMDB / CMS / ancient spreadsheet that everyone acknowledges as the single source of the truth has been updated appropriately
  • Service improvement suggestions
  • Breaches to SLAs / OLAs / Underpinning Contracts
  • Required amendments to SLAs / OLAs / Underpinning Contracts
  • Updated work instructions

Keeping a lessons learned log to build on previous Releases and to keep a documented audit trail of all learnings, good and bad. The lessons learned log should be reviewed regularly; at least on a quarterly basis and before the implementation of major Releases to ensure past mistakes do not recur (because let’s face it, if we don’t learn from our mistakes thats just embarrassing). A sample lessons learned log could look like the following:

Example of a Lessons Learned Log

Change Number Date Title Issue Lesson Learned
RFC – 1234 Windows Patching – Office X Critical servers unavailable in Office X due to patching failure. Though testing of all Windows server patches prior to deployment into the production environment.

Revise the process as any issues arise or build any more significant improvements into a Service Improvement Plan (SIP).


That’s our take on Release Management; what do you think? Let us know in the comments!


Disk Image Credit

Early Life Support Image Credit

Review & Close Image Credit