Event Listing: BCS CMSG Conference 2016

The BCS Configuration Management Special Interest Group are holding their annual conference in London on the 7th of June.


The theme of the conference is transitioning the future and the event will have three streams:

  • DevOps
  • Change Configuration & Release Management
  • SAM  Licensing & Strategy

This is the 11th conference run by the BCS CMG. The main conference objectives are to share experiences in how Configuration Management supports and enables Change Management in software development and ITIL Service Management. Software Asset Management (SAM) and licensing are critical to today’s organizations and the conference will detail new approaches and strategies to aid today’s practitioners. Best practices in adopting an integrated approach, and communicating and selling this to the rest of the organisation are essential elements.

The Conference will bring together managers and practitioners working across the service lifecycle (which incorporates the application lifecycle) together in an open forum.


Event Breakdown

What: The BCS CMSG Conference; Transitioning The Future

When: 7th June 2016 08:30 – 20:00

Where:  BCS, 1st Floor, The Davidson Building, 5 Southampton Street, London, WC2E 7HA.

How To Book: Click Here


I’ll be one of the speakers at the conference (check out my session overview here) so if you’re attending the conference, come and say hi!

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

Change vs Release Management

One of the things that I got asked about most as a consultant was about what the difference was between Change and Release Management. It should be simple right? We’ve had 3.5 versions of ITIL, the itSMF, even special interest groups dedicated to Service Transition yet there is near universal confusion at the sharp end about WHAT the difference is between Change and Release Management so let’s sort this out once and for all!

For my money; Change Management are guardians – they protect the live environment.


The primary objective of Change Management is to enable beneficial Changes to be made, with minimum disruption to IT Services.

Release Management are like air traffic controllers; they package together bundles of Change into a single Release to reduce periods of downtime and inconvenience to the rest of the business.


The primary objective of Release Management is to ensure that the integrity of the live environment is protected and that the correct components are released.

Bringing out the big guns

Let’s get back to basics and talk ITIL for a second. Both Change and Release Management sit in the Service Transition stage of the ITIL lifecycle so are part of the value stream that delivers effective business change;

Change; The addition, modification or removal of anything that could have an impact on IT services.

Release; Collection of hardware, software, documentation, processes or other components required to implement one or more approved changes to IT Services. The contents of each release are managed, tested and deployed as a single entity.

In other words, Change is about installing, modifying or retiring things safely without setting anything on fire. Release Management is a holistic process that bundles together multiple Changes into a single deployment. So now that we’ve got that sorted; let’s talk about how to make sure Change and Release Management play nicely together.

Have a way of highlighting Releases in your Change Management tool

This ensures that Releases should up in the Change Schedule (CS) and that everyone is aware of any major deployments. This will make sure there are no conflicts or scheduling clashes. Take it from someone who knows there is nothing more uncomfortable than being on site in central London explaining to several different technical teams why a site power down and a major code deployment at the same site can’t go ahead at the same time. #awkward

Separate the roles of Change Manager and Release Manager

Change Management is a governance process, the role of the Change Manager is to review, authorise and schedule the Change. Release Management is an installation process. It works with the support of Change Management to builds, tests and deploy new or updated services into the live environment. Both are equally important so you need subject matter experts for both.

Agree the level of documentation required

A Change is a single record containing:

  • Dates
  • Change description
  • Approval details & audit trail

Release documentation is much more involved and as a starter for ten will contain:

  • Scope
  • Release details
  • Implementation plan
  • Back out plan
  • Contact details
  • Release note

Ensure the Release Manager is present at CAB

If your Release Manager isn’t attending CAB invite them immediately! It’s really important that the Release Manager is there to explain the Release content and any dependencies, communicate business approval and advise the Service Desk and Problem Management of any defects; working with them to ensure any known errors with any workaround details are raised where appropriate.

By having Change and Release Management working closely together, your effectiveness rates should improve and unforeseen incidents, problems and defects should be reduced. How do you manage Change and Release Management? Let us know in the comments!

Image Credit 1

Image Credit 2

*Yes; that’s an Aer Lingus plane; they are the best airline in the world because when the flight attendants  clock that you’re a single mum with three over excited kids that are about to go feral at any moment and stress levels that are about to hit DEFCON1 they give you free vodka and cokes throughout the flight.

How to assess Changes

One of the things that I wish was covered in more detail during the ITIL intermediate training is how to properly impact assess Changes. Change Managers are the guardians of the production environment so making sure that all changes are properly assessed and sanity checked is a key part of service delivery. Asses too low and high risk rangers go through unchallenged, assess too high and you block up the process by examining every change no matter how small as if they could kill your organisation.

Here are the things that I look for when assessing a Change:

The Basics:

Title Does it highlight the affected services so that it’s easy to identify in any reports?
Description Is it clear and does it make sense? Sounds basic I know but let’s make it easier for the other people assessing and authorising the Change.
Benefits Why are we doing the Change? Remember, this isn’t just about technology, what about business and financial benefits?
Risk What are the risks in carrying out this Change? Has a risk matrix been used to give it a tangible risk score or is it a case of “reboot that critical server in the middle of the day? Be grand”. Imagine explaining to senior management what went wrong if the Change implodes – have you looked at risk mitigation? Using a formal risk categorisation matrix is key here.  Don’t just assume technicians know what makes a change low risk.  One of the key complaints from the business is that IT does not understand their pain. Creating a change assessment risk matrix IN A REPEATABLE FORMAT should be your first priority as a Change Manager.  If you can’t assess the risk of a change in the same way each time, learning from any mistakes, then you’re not doing Change Management. Period.


Scheduling Does the proposed timing work with the approved Changes already on the Change Schedule (CS)? Has the Change been clash checked so there are no potential conflicts over services or resources?
Implementation windows Look at the proposed start and end times. Are they sensible (i.e. not rebooting a business critical server at 9 o’clock on Monday morning)? Does the implementation window leave time for anything going wrong or needing to roll back the Change?
Special considerations Are there any special circumstances that need to be considered? I used to work for Virgin Media; we had Change restrictions and freezes on our TV platforms during key times like the Olympics or World Cup to protect our customer’s experience. If you don’t know when your business critical times are then ask! The business will thank you for it.

The Technical Details:

Service Affected Have all affected services been identified? What about supporting services? Has someone checked the CMS to ensure all dependencies have been accounted for? Have we referenced the Service Catalogue so that business approvers know what they’re authorising?
Technical Teams Affected Who will support the Change throughout testing and implementation? Will additional support be needed? What about outside support from external suppliers? Has someone checked the contract to ensure any additional costs have been approved?
User Base Affected Check and check again. The last thing you want to do is deploy a Change to the wrong area of the business.
Environments Covered What do you mean what environments are we covering? Surely the only environment we need to worry out is our production environment right? Let me share the story of my worst day at work, ever. A long time ago and pre-kids, I worked for a large investment bank in London. A so called routine code change to one of the most business critical systems (the market data feed to our trade floors) took longer than expected so instead of updating both the production and DR environments, only the production environment was updated. The implementation team planned on updating the DR environment but got distracted with other operational priorities (i.e. doing the bidding of whichever senior manager shouted the loudest). Fast forward to 6 weeks later, a crisis hits the trading floor, the call is made to invoke DR but we couldn’t because our market data services were out of sync. Cue a hugely stressful 2 hours where the whole IT organisation and its mum desperately scrambled to find a fix and an estimated cost to the business of over $8 million. Moral of the story? If you have a DR environment; keep it in sync with production.
Licencing Are there any licensing implications? Don’t forget, changes in the number of people accessing a system, number of CPUs, or (especially) the way in which people work (moving from dev to prod) have huge impacts on licences.


Pre Implementation Testing How do we make sure the Change will go as planned? Has the Change been properly tested in an appropriate environment? Has the testing been signed off and have all quality requirements been met?
Post Implementation Verification OK; the Change has gone in, how do we make sure everything is as it should be? Is there any smoke testing we can carry out? This is particularly important in transactional services; I once saw a Change that went in, everything looked grand but when customers tried to log in the next day, they couldn’t make any changes in their online banking session. I’ll spare you the details of the very shouty senior management feedback; let’s just say fun was most definitely not had that day. If at all possible; test that everything is working; the last thing you need is a total inability to support usual processes following a Change.


Implementation Plan Does it make sense and does everyone involved know what they are meant to be doing and when.  If other teams are involved are they aware and do we have contact details for them? Are there any dodgy areas where we might need check point calls? Do we need additional support in place such as additional on call / shift resource on duty senior manager to mitigate risk? The plan doesn’t have to be fancy; if you need some inspiration I can share some template implementation plans in our members / subscribers area.
Back Out Plan What happens if something goes wrong during the Change? Do we fix on fail or roll back? Are the Change implementers empowered to make a decision or is escalation needed? In that case; are senior management aware of the Change and will a designated manager / decision maker be available? Can the Change be backed out in the agreed implementation window or do we need more time? If it looks like restoration work will cause the Change to overrun; warn the business sooner rather than later so that they can put any mitigation plans / workarounds in place.


What Early Life Support Is Planned? What early Life support is planned? Are floorwalkers needed? Are extra team members needed that day to cope with any questions? Have we got defined exit criteria in place?
Is The Service Desk Aware? Has someone made the Service Desk aware? Have they been given any training if needed? I know it sounds basic but only a couple of months ago; I had to sit down and explain to an engineer why it was a good idea to let the Service Desk know before any Changes went live. Let’s face it; if something goes wrong the Service Desk are going to be at the sharp end of things. And speaking as an ex Service Desk manager (a very long time ago when they were still called Help Desks) there is nothing worse than having to deal with customers suffering from the fallout of a Change that you know nothing about.
Communication Has the Change been comm’ed out properly? Do we have nice templates so Change notification have a consistent look and feel?
SLAs If the business are pushing for a Change to be fast tracked with minimum testing can you ask them to formally acknowledge the risk by relaxing any SLA?

The above list isn’t exhaustive but it’s a sensible starting point. There’s lots of guidance out there; ITIL has the 7 R’s of Change Management and COBIT has advice on governance. What do you look for when assessing Changes? Let me know in the comments!

Image Credit

The 7 habits of highly effective CABs

As a former Change Manager I can honestly say that the Change Advisory Board (or CAB) is one of the most important and useful meetings a service orientated organisation can have. It sets out a view of what’s happening to key services over the next week, reviews previous Change activity and looks at CSI so what’s not to like? CAB meetings are all about the people attending them and handled badly your CAB meeting will have all the power of a chocolate teapot so here are our top tips for running them effectively.

Step 1: TCB Power!

A colleague of mine once told me that TCB or tea, coffee and biscuits was one of the most important acronyms in IT. When I worked for a large investment bank in London, one of my first tasks was to roll out a sensible Change Management process across one of our service families. Trying to persuade grumpy techies who saw Change Management as red tape rather than an important part of service delivery was not going well until I brought out the big guns; Krispy Kreme doughnuts and chocolate biscuits. In all seriousness, a CAB meeting is where you want people to feel comfortable representing Changes or asking questions so anything that makes your meeting easier, nicer or makes people feel more relaxed can only be a good thing.

What not to do! 

Step 2: Get organised

Make sure that your CAB has a terms of reference document so that everyone knows what they’re doing and why. The Change manager should send out the CAB agenda, including the Changes to be discussed, the Change Schedule (CS) and any Changes that caused Incidents well in advance of the CAB meeting.  Service Delivery teams and Project Managers need time to read and consider the Changes as well as identify any potential issues or questions.

Step 3: Look for the big hitters

One of the biggest mistakes people make is insisting all Changes should go to CAB.  Not a good idea unless you want your CAB meeting to be overrun with server reboots or patching requests. Use automation where possible so that the CAB meeting can focus on the major, high category Changes that need to be sanity checked and talked through.

 Step 4: Play nicely with your attendees

Some members of the CAB will be needed for their opinion on every Change; for example the Service Desk, Network Services and Server support and will make up the core CAB attendee list. Other attendees such a Project Managers, Service Delivery Managers and external suppliers might only be needed to discuss a couple of Changes on the list. If this is the case then be kind. Move those Changes to the beginning of the CAB so that these temporary or “flex” CAB attendees can discuss the relevant Changes and then leave.

Step 5: Ask the horrible questions

You know the ones, what everyone in the room is thinking but no one wants to actually ask. Some examples could include:

  • “What’s the remediation plan? Do we fix on fail or roll back?”
  • “What happens if rolling back doesn’t fix the issue?”
  • “Is the person doing the Change empowered to make that decision or do we need to arrange for extra support to be on call?”
  • Or even; “is this really a good idea?”

It’s better coming from the Change Manager than from an angry customer or senior manager following a failed Change right? Make sure the Service Desk feel comfortable asking questions as well; they’ll be the ones at the sharp end of customer complaints if anything goes wrong so make sure they’re happy with the Change content and plan.

Step 6: Keep it pacey

There is nothing worse than a two hour CAB meeting. I guarantee you; if you are regularly putting your CAB attendees through marathon meetings then people will run short of both patience and good will. There’s also a very real chance that someone may fall asleep. Keep things moving. If someone has launched into a long winded, uber waffley technical explanation and you get the sense that it’s adding no value as well as making everyone in the room lose the will to live then break in with a question so that you can get things back on track. Do it nicely though obvs.

Step 7: CSI

Don’t forget to review your list of previously implemented Changes. If something’s gone well then brilliant! Let’s template it or add it to any Change models to share the love. If something hasn’t been successful or worse, has broken something generating a load of Incidents then look at what happened, figure out the root cause and look at ways of preventing recurrence. If your Problem Manager isn’t attending CAB then invite them – they are the subject matter experts in this area.

What do you think? What are your top tips for effective CAB meetings? Tell me in the comments!

Image Credit

Webinar: Change Management – 28th January 2016

Enterprise Service Management events

Happy January everyone! We are pleased to announce our new program of ITSM training modules; Bite Sized ITSM. The training is a year long educational course based on Service Management best practice and will balance practitioner experience against industry frameworks including ITIL, COBIT and Lean Sigma.

The programme enables worldwide ITSM professionals to attend monthly, one hour, webinar sessions to learn about key elements of ITSM from the comfort of their own workspace. Each session is free and the first module will be on Change Management.

We also have a sparkly new partnership with our friends at Pink Elephant; if you would like to learn more about a subject covered on our webinars; you can qualify for an exclusive 15% discount on their extensive ITIL training program.

Module 1 – Change Management

Change Management

About This Event

This is the 1st module in the series covering an Introduction to Change Management. This webinar was presented live by Vawns Murphy on 28th January 2016. If you missed the live session or enrolled late… No problem, all sessions are recorded for future playback. Register below to view the recording of this session.

Learning Objectives

1. Goal and objective

2. Types of Change, CAB meetings, and implementation planning

3.  Change Management process; a practitioners guide

Who should attend? 

  • Change Managers
  • Change Analysts
  • Project Managers
  • Service Delivery Managers
Why you should attend
  • Cost – The Webinar is FREE. Convenience – You can participate in the webinar from a location of your choosing.
  • No travelling/ travel costs involved.
  • Interaction – You have the opportunity to communicate and ask questions with the presenter and peers.



For details of the full Enterprise Service Management Training Programme, click here.

Surviving the end of a Change Freeze

Happy New Year to all our readers and especially to all the Change Managers out there. Why especially Change Managers? Well this week is “back to work” week for most people following the end of the Christmas break as well as the end of any Change freeze / restrictions. This means that not only are our poor Change Managers dealing with the January blues; they’re dealing with the floodgates opening and a deluge of Change activity. With the best will in the world, we try to ensure Changes are transitioned seamlessly into our live environment but the reality is, more Changes equal an increase in Incidents so here’s our guide to surviving the end of the Change freeze whilst keeping your sanity in check.


Step 1: Stick the kettle on

I know, I know, I’m a caffeine addict but in all seriousness, you’re facing a busy week, might as well rock it powered by Starbucks.


Step 2: Have a look at your Change Schedule

Look at your FSC and see if you can identify any bottlenecks or pain points. You know the ones, that business critical service that needs a software update but the rest of the business will be after you with flaming torches and pitchforks if there’s any unforeseen downtime, the server that takes forever to come back up again following a maintenance reboot or that router that’s so twitchy it falls over if someone even looks at it the wrong way. Look at your areas of highest risk and give them an extra sanity check to make sure all the due diligence has been done, the implementation windows are at sensible times and that everyone is happy with the action plan.

Step 3: Get Proactive

As the late, great Bob Hoskins once said, “it’s good to talk”. Now is the time to pre-warn your Service Desk, support teams, Service Delivery Managers and management teams that Change activity will be returning to normal and that it will be an extra busy week or so while the backlog that will have invariably have built up during the Christmas break is dealt with.

Step 4: Turn on the charm

Talk to your Relationship Managers and Service Delivery Managers so that they’re pre warned of any additional risks. By making them aware, you’re enabling them to pre warn customers of any potential blips and if you’re really lucky they may even be able to negotiate a relaxation of any SLAs during busy periods – yay teamwork!

Final Thoughts

Keep smiling, it will be fine, all will be well because you’ve got this. If all else fails – at least you’re not this cat:


Image Credit

Enterprise Release Management Tools: Plutora


image3Enterprise Release Management is an increasingly prominent discipline, occupying the intersection of technical release management, project delivery and change management. Its focus is on understanding and governing the full portfolio of multi-stream changes, be they quarterly ERP releases, one-off project deliveries or monthly patching.

The demands on enterprise level release managers are many: governing and managing individual releases, maintaining the forward schedule as far as 12 months ahead, making sure non-production environments are efficiently used and more. Most release managers will have built and refined an array of spreadsheets and calendars to manage everything from release scope, defect lists, release gateway checklists, cutover plans and forward schedules.

Spreadsheets and calendars can work perfectly well when there are only half a dozen releases to track across 2-3 test environments, but once this starts scaling up – especially with multiple release managers – keeping these spreadsheets up to date becomes an administrative challenge and resource drain, letting inevitable errors creep into manual processes.

This is the tipping point where dedicated Enterprise Release Management tools make their case. The initial benefits are obvious: moving spreadsheets online to offer a single version of the truth slashes administrative waste and allows for pivoted views of the same data. Common tasks or release governance structures can be defined and re-used.

Clever reporting can replace hours of spread sheet and Powerpoint wrangling with the click of a button, and this is only scraping the surface. In this review, we’ll see what else leading vendor, Plutora, has built into their tool to add some real intelligence into the process far beyond simply lifting and shifting a spreadsheet online.

Quick facts & review highlights

Version Reviewed

Plutora V 3.5
October 2014

Market focus & customer counts

Large/very large IT organisations with a strong or dedicated project delivery arm who are presently struggling with visibility of their forward release schedule, environment utilisation or quality of repeatable release activity.


  • USA: 18
  • EUROPE: 8
  • ASIA PAC: 15

License Options

SaaS licenses available in packs of 25 or unlimited enterprise option.

Competitive Differentiators

  1. Purpose-Built and Comprehensive: Plutora Enterprise Release Manager enables all of your end-to-end release management processes out of the box. Plutora is differentiated with its capability to combine release management, test environment management, deployment management and self-service reporting in a single comprehensive tool.
  2. Enterprise SaaS: Plutora is 100% SaaS to ensure rapid implementation and adoption of the solution within your organization. Plutora scales in the cloud to meet the growing complexity of your organization as teams become increasingly distributed.
  3. Vendor-neutral integrations: To provide a unified view across all your releases, Plutora integrates seamlessly into your landscape with an open API and adapters to your existing Project Portfolio Management, Application Lifecycle, Quality Management and IT Service Management tools.


  • Plutora Enterprise Release Manager
  • Plutora Test Environment Manager
  • Plutora Deployment Manager

We think Plutora is stronger in…

Conversion of simple, powerful & common tools frequently used (and easily recognised) by release managers into a web application and expanded to make the most of pivotable underpinning data.

Strong & flexible presentation of critical information, both from pre-configured views & reports, and user-built reporting.

Powerful deployment management command & control function.

Clever system impact matrix with regression-test flagging.

We think Plutora is weaker in…

As a release-focused tool, less emphasis on non- transition related IT Service Management information may mean release decisions are taken in isolation and solved problems are not learned. Plutora offers the ability to add customized data fields and comments for non-transition related information.

Not aggregating change/feature resource cost into release-level capacity monitoring (and instead doing this manually) feels like a missed opportunity.

Some medium-sized IT organisations do not have 25 users, Plutora’s minimum license. Less focus on technical release aspects such as build/integration tooling, though this is on the feature roadmap.

In their own words…

Plutora’s purpose-built SaaS solution for Enterprise Release Management, Test Environment Management and Deployment Management enable you to manage complex application releases with transparency and control. Using Plutora, organizations can deliver higher quality software more frequently to meet customer demand with no impact on downtime.

Plutora ensures high-quality, on-schedule releases by driving enhanced enterprise collaboration and coordination for all key elements of a successful release: timing, composition, status, and stakeholders across their lifecycle – with ease. Real-time dashboards show release schedules and how they are tracking according to governance gates within the release framework.

Plutora provides a unified repository for all release information where users can source data, including project dependencies, without needing to piece together the shape of a release from multiple sources. Plutora integrates with your existing IT management tools to ensure that no data needs to be manually re-entered by users.


Over 30 enterprises across the globe as of March 2015, including Telstra, ING Direct, Boots UK, News Corporation, and GSK, manage $5 billion of releases using Plutora.

About this review

This was an unusual review, since Enterprise Release Management is an emergent discipline, combining both technical release management and project-delivery capabilities, but with an operational focus.

As an emergent discipline, there are no standard ways of dealing with the inherent challenges in this field, so the assessment of quality comes both from a mixture of judgements made during the review, in-depth use* and trusted industry awards. In this last category, Plutora has pedigree: named by Gartner as ‘Cool Vendor of the Year’ in 2014.

This review was written on the basis of a maximum 2 hour demonstration of the 5 key capabilities by each of the vendors. It is not exhaustive, and some capabilities which you especially require may be present in the tools but not covered in this review. As such, if you believe that Enterprise Release Management tooling is appropriate for your organisation, it is worth speaking to Plutora to ascertain best fit for your specific objectives.

*and thus not part of this review

Assessment Criteria

  • Tracking and managing a release with repeatable & templated processes
  • Tracking the entire release portfolio and presenting this information to diverse stakeholders
  • Managing resource and environment usage
  • Using data inside or connected to the tool and built-in intelligence to help inform release activities.
  • A single tool to remove reliance on spread sheets, calendars or manual processes.

Functional Review

Plutora is purpose built to enable end-to-end release tracking in a single solution. It comprises 3 modules: Enterprise Release Manager, Test Environment Manager and Deployment Manager.

A release in Plutora comprises a number of customer-specified phases that focus on their respective exit gates, and each has a checklist of activities or exit criteria a release manager would need to have completed before moving to the next. For example, a ‘QA’ phase exit gate would be reliant on, say, Completion of Functional Testing, Completion of Performance Testing and Signed Off Test Completion Report as activities required to move to the next phase.

Once a release ‘model’ has been built using these phases and checklists, it is then very easy to clone this to a new release. According to Plutora, many of its customers prefer using this cloning approach to template their releases rather than building dedicated theoretical templates which may themselves require overhead to manage and keep up to date. The cloning approach allows a maturing release management organisation to learn and adapt quickly to changing situations – taking only the elements they know work and evolving them organically.

Additionally, some customers of Plutora also use this cloning feature and general checklist features to build operational maintenance checklists – so, although the tool is heavily targeted at the change delivery side of the organisation, it can also be of significant benefit to operational and technical maintenance functions.

The templating and checklist functionality doesn’t stop there. Implementing a release is another area often devolved to shared spreadsheets, but Plutora delivers not just a single-source-of-truth replacement for these spreadsheets, but in Deployment Manager a clever, real-time command and control capability to let a single release manager monitor, trigger and track deployment steps in multiple releases simultaneously with internal or external delivery teams.

Once the work has been put into ensuring that the individual releases are accurate, the aggregate view starts to take shape and provide value. The Plutora Enterprise Release Schedule provides a tailored view of all releases. The schedule can be detailed, showing all phases, gateways and environments, or quickly summarised into a powerful senior stakeholder view. The schedule also supports diverse delivery approaches, whether agile, continuous delivery or more traditional waterfall as well as the simple operational checklists mentioned earlier.

However release management tooling is not just about visibility of the release schedule or implementing releases effectively. Plutora has two additional features, the release capacity planner and the systems impact matrix which add data-driven intelligence to release management.

The systems impact matrix is a simple-seeming view of dependencies between systems and releases. This on its own is a useful tool, giving a summary of which releases touch which applications. But the really clever bit is how Plutora not only identifies which systems are being touched by the release, but which linked systems are also impacted thus needing a regression test. This feature alone could make the business case to purchase Plutora.

The release capacity planner is also a useful feature. It allows release resource ‘containers’ (eg. number of test cases) to be specified and tracked in an accessible and easily summarised view, letting release managers clearly articulate release capacity. However my only major criticism of Plutora is that this capacity specification is manual and performed by the release manager. Since many ALM tools with which Plutora can share data (eg. Jira) can contain the development & test effort within their own records, it would seem logical for Plutora to take in this change-level data and aggregate it into a total release effort measure (adding extra overhead as necessary for release-level activities). The overall size of the release container can still be defined by the release manager, but the usage of each container could, and in fact should come from the individual change/feature records, and Plutora doesn’t do this. Despite this, the capacity tool is still incredibly useful for discussions with the business about setting realistic delivery expectations and customized fields can be added to incorporate additional information relevant to the release management process.

The last core area of functionality is test environment management. Test Environment Management in Plutora is fairly tightly coupled with the rest of the release functionality in planning and executing releases, but there are a couple of additional features worth noting.

Plutora contains an environment request and approval tracking system to allow projects or releases to book time in specific environments. Combined with the system impact matrix described above, Plutora’s ability to ingest data from external configuration/discovery tools and the ability to define complex environment groups of related systems makes for a powerful management suite to make better use of non-production environments.

The Test Environment Manager also has its own version of the release schedule (but from an environment-centric view) and likewise can be used to easily identify & articulate over or under utilisation at a glance. In addition, by specifying those stakeholders within the tool and enabling message broadcasts, clashing stakeholders can be made aware of contentions and work to resolve the issue.

This feature actually extends throughout all of Plutora. Stakeholders, systems, organisations and more are specified when initially configuring the tool and message broadcasting can be selectively activated at release or environment level.

Finally, reporting. Plutora has obviously invested considerable time and effort in getting reporting right, with pre-configured single-page overview reports providing real value to release managers as well as keeping senior stakeholders happy. The reporting dashboard is also configurable, allowing release managers to build graphs and displays from data within the system and then combining these into a personalised dashboard. This isn’t revolutionary functionality, but it is solid and well executed in Plutora.


Enterprise Release Management tooling is ostensibly about removing the array of spreadsheets that proliferate to manage scope, timelines, environment usage and cutover plans. Plutora not only does this exceedingly well, its also used the opportunity to add some intelligence and polish to the tool to make people’s lives easier and improve the quality of the release passing through it.

Plutora is the tool one release manager would build for another. Plutora has taken existing practices, made them collaborative, structured and business-ready, then extended them to both pre-empt and answer the most common questions asked of release managers or that release managers ask of themselves.

Feature by Feature Summary Scoring

Tracking and managing a release with repeatable & template processes ★★★★
Tracking the entire release portfolio and presenting this information to diverse stakeholders


Managing resource and environment usage ★★★★★
Using data inside or connected to the tool and built in intelligence to help inform release activities.


A single tool to remove reliance on spreadsheets, calendars or manual processes.


Scoring Key

★★★★★ – Advanced features well developed

★★★★ – Advanced features present

★★★ – Solid coverage of basic requirements with some additional/advanced features

★★ – Basic requirements covered, some less thoroughly than expected or with minor gaps

★ – Not all basic requirements, significant gaps

Last words

Plutora is the tool which, in the reviewer’s opinion, embodies the term ‘Enterprise Release Management’.

It will work well in busy, large IT organisations and whilst it has a place in supporting operations, it feels targeted firmly at the development/delivery side of the IT organisation where teams of project managers, release & environment managers and more can collaborate with tooling they already instinctively know how to use.

Appendix – Screenshots


The information contained in this review is based on sources and information believed to be accurate as of the time it was created. Therefore, the completeness and current accuracy of the information provided cannot be guaranteed. Readers should therefore use the contents of this review as a general guideline and not as the ultimate source of truth. Similarly, this review is not based on rigorous and exhaustive technical study. This is a paid review. That is, suppliers included in this review paid to participate in exchange for all results and analysis being published free of charge. The ITSM Review © 2015.

Change Management: Responding to a Crisis

Keep Calm...
Keep Calm…

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

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


Step 1

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

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

Step 2

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

Step 3

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

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

(1) Angry customers

(2) Angry stakeholders within your business

(3) The press

(4) Regulatory bodies.

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

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

Step 4

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

• The nature of the work

• Who is carrying it out

• How it’d been tested

• Linked Incidents

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

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

• Any customer communications

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

 Step 5

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

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

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

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

Step 6

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


Frazzled people require pizza
Frazzled people require pizza

Step 7

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

Step 8

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

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

Step 9

Lessons learned...
Lessons learned…

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


Step 10

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


Final thoughts

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

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

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

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

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


Project success with Organizational Change Management (OCR)

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

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

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

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

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

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

Organizational Assessment

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

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

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

The Three Camps

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

Assess the Change

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

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

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

Create the Messages

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

The Champions

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

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

Top Down and Bottom Up

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

Communication and Training

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

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

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

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

Get Assistance

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


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

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

Image Credit