Release Management – How To (Part 2)   

Following on from Part 1 of our article on how to do Release Management – here are some tips on Release acceptance, rollout planning and communication & training.



Any development code that results in a change to the live environment should be under the control of Change Management and be managed by the Release Management process. If you are finding that a high number of Release RFC’s are being rejected at CAB meetings then you need to investigate the reason for this. All rejected Release RFC’s should be tracked and reported on by Change Management.

The Release should be tested in a controlled test environment with known hardware and software configurations. The current list of release acceptance criteria should be reviewed and updated if appropriate. Release acceptance criteria will differ widely for different organisations as different companies will have different requirements. Your list of release acceptance criteria could include the following:

  • Has the release performed as expected across all development and test environments?
  • Has the back out plan been tested successfully
  • Are the release deployment instructions correct?
  • Has all appropriate support documentation been updated?
  • Has a training schedule been created / have all relevant teams received adequate training?
  • Has the release undergone extensive User Acceptance Testing (UAT) with involvement from all impacted customer / user groups?
  • Is the release performing as expected in test environments and free from defects?
  • If testing has identified any defects with the release is it possible to deploy with a workaround or should the release be postponed?
  • Have all impacted support teams received training in any new support functionality resulting from the release?

I like to borrow the Quality Gate concept from Six Sigma to make Release acceptance as effective as possible.Put simply, quality gates are a way of enabling your Release to move through the process quickly and safely making sure that all the quality criteria have been met. Quality Gates are not, I repeat NOT, road blocks or red tape; if anything they speed up the process (some checks can be automated) and cycle time is reduced because we’re getting it right the first time. Quality Gates are a set of predefined quality criteria that a software development project must meet in order to proceed from one stage of its lifecycle to the next and ensure. Quality Gates ensure that  formal checklists are used throughout the life of a project so nothing can be lost, missed or ignored and that formal sign-off and acceptance occurs at each gate ie no nasty surprises.

Some examples of quality gates include:

  • Code review: The senior developer will look at acceptable coding techniques and adherence to IT standards and best practices. The software design will be verified against the coding to identify any coding errors. Upon successful completion of the code review, the reviewing party will highlight required changes and corrections to the Release Manager so the appropriate action can be taken..
  • Environment review; the test manager will look at the environments used for testing the Release to ensure they are fit for purpose, managed effectively and are being refreshed at pre agreed intervals.
  • Ops review: The project manager will work with the support teams to review all support tasks needed to support the development environment and ensure all appropriate work instructions are in place..
  • Sponsor review: The project manager will review the overall project performance with the project / release sponsor. This review will determine the status of project costs and schedule.
  • Test review: The test lead and representatives from the Quality team will attend the test review to see if all builds were tested correctly and make sure the appropriate test scripts and procedures were followed.
  • Deployment review: The Release Manager sits down with the relevant dev and support teams to run through the implementation plan and to ensure everyone is comfortable.
  • Defect review; The Release Manager meets with business representatives, the Service Desk and the Project Sponsor to make a decision on if in the event of any defects; the Release is delayed or installed with Known Errors and workarounds.



There are lots of ways to deploy a Release safely into your environment. There is no one size fits all, it depends on the size and complexity of your organisation as well as appetite for risk. In the immortal words of Optimus Prime: “Autobots roll out!”

  • Big Bang
  • Phased / Pilot approach
  • Parallel
  • Push
  • Pull

Review the Release plan to include the exact details of the Release and how it will be executed. The release approach should also be considered to ensure it is appropriate of the type of release; different approaches such as “Big Bang”, phased / pilot, or parallel approaches can all be useful for different types of releases. A big bang release is whereby the release is deployed to all recipients at the same time. Advantages and disadvantages of the big bang approach are summarised in the following table:


Advantages and disadvantages of the Big Bang deployment method:

Advantages Disadvantages
Release is deployed to all users at the same time More risky than other deployment methods because if the Release fails or causes a Major Incident the Release must be backed out for all users
Training is only required for the new system and not for running both the old and new systems in parallel Training must be scheduled for all stakeholders prior to the release adding additional pressure to key release personnel
There is one deployment date which has been communicated to all stakeholders preventing any confusion around release scheduling As there is only one deployment date, any delay to the release may cause adverse impact to certain departments


Phased or pilot releases can be used to introduce new functionality to the end user base in a scheduled approach ensuring that the release has been successful at each stage before moving on to the next. Advantages and disadvantages of the phased / pilot approach are summarised in the following:


Advantages and disadvantages of the Phased / Pilot deployment method:

Advantages Disadvantages
Less risky than “big bang” deployment as the release is deployed to a set group of users at a time, thereby if the release fails it is backed out from one or a small number of user groups rather than the whole organisation. Release implementation will take longer as it will be deployed in a staged manner rather all at once.
May enhance the relationship between IT and the selected pilot groups as the two will work very close together if a pilot approach is used. Support for the release could be more expensive due to longer implementation windows eg needing contractors / consultants for longer

A parallel approach can be used to reduce risk for business critical releases. A parallel release works by having both the old and new system run simultaneously for some period of time after which, if the criteria for the new system are met, the old system is disabled.  Advantages and disadvantages of the parallel approach are summarised in the following table:


Advantages and disadvantages of the Parallel deployment method:

Advantages Disadvantages
Less risky than “big bang” deployment as the release as the original configuration is still available to users Expensive as it involves running two versions of a system in parallel for a length of time requiring appropriate support personnel, licensing costs and system capacity.
Less risky than phased / pilot releases as you have an instant roll back in that your original service is still available Risk of confusion to the user base as both systems are available at the same time
Additional training may be required for running both the old and new systems in parallel

Push deployments are used where the service component is deployed from the centre and pushed out to target locations.


Advantages and disadvantages of the Push deployment method:

Advantages Disadvantages
IT are in control of when the Release is deployed and to which user groups End users could be inconvenienced if the update is pushed during an important task
Can be automated or built into a Microsoft group policy The network could experience performance issues if too big an update is pushed out
Ideal for critical security patches or antivirus updates

A Pull deployment approach is used for software releases where the software is made available in a central location but users are free to pull the software down to their own location at a time of their choosing. As some users will never pull a release it may be appropriate to allow a pull within a specified time limit and if this is exceeded a push will be forced, e.g. for an antivirus update.


Advantages and disadvantages of the Pull deployment method:

Advantages Disadvantages
Users can schedule updates at a time that best suits them Some users will never “get round” to installing the software so a combined Push / Pull approach should be considered eg users can pull at their convenience but If this hasn’t been done in x number of days the software is push out to the CI
IT doesn’t become a bottleneck; clients contact the server independently of each other, so the system as a whole is more scalable than a ‘push’ system Scalability can become a bottleneck; unless you deploy several master servers and keep them in sync, that one master will start getting swamped as you add more and more clients and thus will become your bottleneck
Follows the self service model – end users feel empowered


Communication & Training

Part of the By A Wall series.

It’s important to ensure that an appropriate level of governance is in place to support your Release Management is the introduction of governance. Setting up governance around a Release Management process will ensure the releases are implemented to a higher quality; it’s not just a case of channeling your inner Mr Burns (although that would be pretty cool).

A Release Board should be set up to control the formulation and implementation of Release strategy and in this way ensure the fusion of business and IT. The Release Board will also be responsible for managing risk, testing and formal senior management sign off in addition to the CAB approval discussed in the previous section. The Release Board will often make the final Go / No Go decision on whether or not the release can go ahead if a last minute defect is found.

The Release Board should meet frequently and should be made up of some of the following:

  • Release Manager
  • Change Manager
  • Configuration Manager
  • Project Office / Manager
  • IT Senior Management
  • Business Senior Management

Governance paths should be set up to underpin the Release Management process and establish guidelines, an example of which could be no first of type releases can be deployed by a big bang deployment and all impacted department should have additional floor walker support.

Regular release check point meetings should be held so that all stakeholders of the release are aware of the implementation details. Examples of meetings include:

  • Pre release implementation checkpoint meeting
  • Post implementation meeting
  • Monthly process review meetings with stakeholders in the Release process to review the Release schedule, any issues, SIP, etc.

A release / service readiness review should be carried out to ensure the production environment is ready for the release. Such a review could be carried out in conjunction with Capacity Management to ensure that all capacity issues are tracked and addressed in the Capacity Plan.

The release implementation plan, back out plan and any associated technical documentation should be distributed to all stakeholders well in advance of the go live date to prevent any confusion. A communication to end users / customers should be issued via the Service Desk if a Release will have a noticeable effect on end users; it is useful to build up a bank of template Release e-mails so Releases are communicated in a standardised way.

Regular meetings should be held with Problem Management so that any Known Errors can be distributed to impacted stakeholders prior to the Release going live. There should also be a documented procedure for providing the Service Desk with a list of Known Errors before go live so that they are able to log incidents appropriately and relate them to the correct Known Error. Before any release is implemented, the Service Desk should receive training on any key changes to existing functionality and should be provided with “quick fixes” from the support teams to ensure that simple issues can be fixed by at the first point of contact where possible. New codes and templates for the release should also be set up in the Service Desk tool.

Join us for our second live ITSM webinar on Release Management on Thursday 25th February at 2:00PM GMT. You can watch live, or on demand by registering here.

That’s all for now, come back soon for our final article in the series where we’ll look at go live, early life support and review & close.



Quality Gate Image Credit

Rollout Image Credit

Communication & Training Image Credit

Main Image Credit


Collaboration – The Unconquered Peaks

Philippa Hale of Open Limits Ltd
Philippa Hale of Open Limits Ltd

This article has been contributed by Philippa Hale, Director and Senior Consultant at Open Limits Ltd.


Collaboration, across diverse teams and between levels of the hierarchy remain the twin, unconquered peaks for many organisations. This is also true of collaboration internally, within IT functions. Poor collaboration is often revealed to be the fatal flaw in well publicised corporate disasters. Within IT and between IT and the internal functions IT supports, it is a silent, relentless drain on time, cash, productivity, motivation and talent during organisational projects and operational improvements.

The following shows how teams from three very different organisations identified and overcame barriers to collaboration. In one case the teams were specialists within the same large IT function – responsible for different steps in the service delivery process managed in different countries. The other teams were from different functions including: Finance, Legal, Sales, Marketing, HR and IT.



At its simplest: ‘To work with another person or group to achieve something’. Initially the teams thought of collaboration in terms of:

  • The tools: The technology and media for accessing and sharing documents and applications, tracking progress, gathering data for decision-making, following processes
  • The location: In some cases the teams worked remotely, across sites, countries and continents. In others they were on different floors of the same building

However all agreed that the real heart of collaboration was not just working alongside each other to deliver products and services; there was a creative, proactive element and more in-depth on-going knowledge sharing, learning and debate.

Examples of good collaboration included doing interesting, challenging work, discovering a whole new side to people, making a difference and being recognised for it. Poor collaboration led to deep frustrations and anger over what were seen as avoidable blocks by individuals, teams and management. Where these had been left unchecked, the stronger emotions had dulled to cynicism, small barbs of passive-aggressive behaviour such as not turning up to meetings or going against decisions made, indifference to new initiatives and doing the minimum.


What Stops Collaboration Happening?

Human beings, it seems from looking at any news media on any given day, are socially and psychologically programmed to stick to and to defend their own. Collaboration is also a natural human behaviour but which requires a degree of maturity, awareness of self and others, positive perseverance in the face of others’ reluctance and an environment where it is safe to explore the new and unfamiliar. Goffee & Jones’ ‘Why Should Anyone Be Led By You?’ (2006) and Kotter’s ‘Accelerate Change’ (2014), show there are inbuilt systemic loops that discourage collaboration. It takes a resilient individual or team to question their own and others’ habits, behaviours and thinking.

The danger, when senior management talk about collaboration, is that they refer to best practice principles and thinking which make perfect sense but do not connect with the day-to-day experienced of team members and managers ‘on the ground’. In each of these three examples, senior management encouraged teams to first get some perspective, then address the details that mattered to them.

Proceeding sensitively was important, as there would clearly be areas of rawness around attitudes and perceptions relating to behaviour and performance. The groups included speakers of English as a 1st and 2nd (or 3rd …) language from all continents.


Three Barriers Identified by the Groups + Solutions Explored

Among the many barriers identified, these three were the top priorities because

  1. a) everyone could take action and benefit immediately
  2. b) improving these basic communication areas would enable more in-depth collaboration in other areas

Barrier 1 – Emails

The phenomenon of email ‘flaming’ is commonly recognised. When stepping back and analysing the specific language in their emails, the groups were quite shocked. Both managers and team members commented that they had become immune. Comments included: ‘It’s not nice but they are always like this so we try not to let it get to us’.   Given that email was the only tool available for communication between some teams on a regular basis, this was critical. The language ranged from the unclear, incomplete and insensitive, to the frankly abusive. Plus, there was limited understanding of the damage that a frustrated ‘cc’ escalation could cause, particularly in cultures with more hierarchical relationships.

Solutions Explored

The groups focused initially on factors outside their control. These included frustrations around (perceived or real) poor planning and prioritisation passed down the hierarchy, skills gaps, bottlenecks, misaligned processes, managers using unhelpful language themselves. However, when the focus was directed at what practical steps were possible, the group started to feel less embattled, more positive and more willing to take on some responsibility for finding solutions. E.g.: Asking for a meeting, picking up the phone and asking questions.

Having discussed the 7 areas of waste identified in ‘Lean’ process reviews, one team identified ‘Waiting’ for action from those interdependent teams, as an area to work on. By using the ‘neutral’ vocabulary of the ‘Lean’ thinking, they could name their concerns and offer practical suggestions more comfortably.

Barrier 2 – International English

There were some good examples in all the groups of ‘false friends’ where 2nd/3rd language English speakers had done their best to articulate their needs, and the native speakers, perhaps having never experienced working in a second language, took the words used at face value. Some examples included the use of ‘You should …’ which sounds like a command to a British reader but in German translates as ‘May I suggest that you …’ .

Solutions Explored

Actually discussing these language aspects was extremely helpful in relationship building. All parties were keen to learn how they were perceived and what they could do to help understanding. For native speakers, slowing down – considerably – was key, and not using local expressions. Keeping sentences short. No waffle or ambiguous management jargon.   Plain English actually sounds more professional and authentic, but many people, native and non-native speakers believe otherwise.

Groups created their own ‘meetings from hell’ checklist – as a light-hearted way to highlight better practices for face-to-face meetings and video/audio conferencing.

Barrier 3 – Prejudice

Having never met in some cases, and with nothing but a few words in emails and general media images to inform their judgements, the teams had created surprisingly detailed pictures of the intentions, level of intelligence, technical competence, work ethic and values of the other groups.

Suggestions Explored

One team invited the other party to work with them on highlighting and addressing issues together, one at a time. ‘The whole solution in the room’ was a phrase used. Another turned process mapping into a shared, physical and visual activity, with giant post-its, a wall and marker pens. This filled many gaps in understanding and increased appreciation of each other’s knowledge, context and constraints.

In one team, where intercultural training was not an option, managers asked each team to research one of the countries they were working with and present their findings. This included contacting their local native speaker colleagues and asking for their input. The groups found this fun, fascinating and a great ice breaker.



The changes in mood, attitudes and behaviour in each of the teams, was quicker and more significant than expected. Within 3 months, there were multiple examples of small improvements in collaboration and significant improvements in delivery. Actively spending time reviewing successes and small improvements reinforced the shared sense of achievement. In all three cases, a senior manager got involved, either at the start, or when asked to support and the initiatives being taken.

Six months on, internal and customer relationships and delivery have improved in all cases.

Collaboration breeds more collaboration!


Philippa Hale has 25 years of experience in enabling collaboration and communication on international projects and programmes, particularly within and between the IT & Digital functions and colleagues from other business functions. She is Director & Senior Consultant at Open Limits Ltd and an Associate Faculty member at Henley Business School.

Contact for more information or join in the debate on 24th March where Philippa will be presenting on this subject at a special itSMF function.



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 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.


Tough Talk – Why Crucial Conversations are the heart of ITSM adoption


I started the day with great expectations.

We had a new process.

We had spent a lot of time designing and tweaking.

And so I went into my meeting excited to explain the new process. Alas, I was not ready for what was about to happen. Barely ten minutes into the explanation of the process, the first salvo was fired:

“This is not what we do. That will not work.”

The exchange over the process escalated from kind explanation, to defending work steps, to questioning professional ability, to name-calling, and it didn’t end there. Trust eroded and partnerships dissolved. After the meeting (and several antacids), I tried to regroup and figure out what went wrong.

I didn’t realise that I just had the opportunity for a “crucial conversation”.

What is a “crucial conversation”?

The entire meeting interaction bothered me so I did a little soul searching to determine why I felt so bad. In my search for answers, I came across the book “Crucial Conversations”. The liner notes quickly described my meeting. Intrigued, and somewhat skeptical, I bought a copy and started reading.

A crucial conversation (as defined by the book) is “a discussion between two or more people where (1) stakes are high, (2) opinions vary, and (3) emotions run strong.

Any journey undertaken to adopt ITSM has many perils. One of the toughest perils is communication. No matter how well you communicate, there always remains an opportunity for somebody to misinterpret, misunderstand, or change the information provided. When I discuss tough challenges of ITSM adoption with other practitioners, communication issues always rank in the top three. The truly toughest conversations not only exist when talking with the C-level, but in the day-to-day conversations with the teams who convert the vision to reality.

Why are they crucial? Simple, they are the day-to-day conversations that affect your life. Crucial conversations are crucial because a) opinions vary; b) stakes are high; and c) emotions run strong. Crucial conversations can be a service desk agent assisting a customer, a CAB discussing a change request, a service owner discussing a process with operation teams, or DevOps teams planning a release.

The Power of Dialogue

Di•a•logue (dìʹ ð-lôǵʹ)n – the free flow of meaning between two or more people.

We each have opinions, feelings, theories and experiences that shape how we view a topic. As we discuss a given topic, we do not necessarily share the same views as others. We do not have a “shared pool of meaning”. People who have mastered the skill of dialogue make it safe for others to add their meaning to the shared pool and having a shared pool of meaning is a key deliverable for any ITSM project. A shared pool of meeting leads to better discussions, better debate, and better decisions. If we position people to purposefully withhold meaning from the shared pool, individually smart people can do very stupid things. Shared meaning helps teams build synergy.

Time to look in the mirror

The key to good dialogue is heart, specifically your heart. We’ve all grown up with various forms of poor communication during crucial moments in life and/or work – debate, silent treatment, manipulation. Not the best role models or behaviors for important conversations, which is why you must work on your changing your own communication first. While we may want, wish, and desire others to change, the only person you can consistently inspire, prod, and shape is the person looking back at you in the mirror.

What do you want?

When I ask other practitioners what they most want in an ITSM relationship with a teammate, the answer is usually “good partnerships”. Successful ITSM adoption only occurs when everyone believes others are working to help improve the state of their situation (a shared pool of meaning).

In all likelihood, you are going to have moments (both in life and in ITSM) where someone completely disagrees with you. You present a change, like a new process for example, and the person counters with:

“We’ve been doing well for the past x years…this change will just confuse things and make it more difficult to do our jobs.”

You know the change is the right thing for the organization, but how do you make those reluctant to change understand this? In the past, when confronted with this type of situation, I have been defensive, offended, and even arrogant. Of course, those qualities led to failure in getting the change adopted and damaged any future efforts for collaborations with the person.

After reading the book “Crucial Conversations”, I changed how I approach these situations. I now take a step back and ask myself the following questions:

  • What do I really want?
  • What are my motives and are my motives changing as the conversation moves forward?
  • What do I really want for others?
  • What do I really want for the relationship?
  • How do I behave if I really want my desired results?

By asking these questions, we affect our psychology and physiology. We can think differently, look teammates in the eyes, and become genuinely interested in what others have to say. We get away from the old (bad?) habits, which we have been exposed to over the years and instead ask ourselves questions that remind us of our goal(s). This helps our brains stay on a path to focus on achieving said goal(s).

Winning and Losing

We often talk ourselves into the idea that we must win or lose, choose between peace and honesty, or try to find a way to make “everyone happy.” The idea behind Crucial Conversations is that we all need to win. We need to help everyone on our team, in our company, in our family, and in our circle of influence reach the results that make us successful. Crucial conversations are necessary to help people find ways to hold emotional and risky conversations safely and with purpose.

Moving forward

  • Read “Crucial Conversations” by Patterson, Grenny, McMillan and Switzler
  • Practice, practice, practice

Don’t expect to read the book and then be beautifully successful in all your conversations moving forward. You won’t be perfect on your first attempt, but don’t worry about it. Just like ITSM, your ability to hold crucial conversation is a continuous improvement process. Just be persistent. Doing so should help lead you to better relationships and collaborations.

Image Credit

CHANGE: Don't be a Statistic!

Change is inevitable, how you manage the organizational aspects will make all the difference

For decades the industry experts have been telling us that 70% of organizational change fails. These experts include recognizable names such as Kotter, Blanchard, and McKinsey. It’s a scary story! This means that 70% of changes fail to recognize a return on investment, and achievement of stated goals and objectives.

In service management the change could be the introduction of new technology, organizational restructure or process improvement. These changes could represent a significant investment of time, money and resources. So can we afford not to break the cycle and allow history to keep repeating itself?

Not only do failed changes result in wasted time, money and effort but they also make subsequent changes even harder. Failed changes result in cynicism, lost productivity, low morale and change fatigue. Expecting people to change their ways of working will be increasingly harder if they have been subject to a series of failed change initiatives in the past.

Failure is due to lack of focus on organizational change

It is my belief that 70% of changes fail due to the lack of focus on organisational change. Projects have specific objectives including on time, on budget and delivery of specified functionality. Projects install changes but do not implement them unless organizational change is included within the project.

If a change is to be truly embedded into the fabric of the organization and recognize the desired outcomes, there has to be a focus on the people. Organizational change is a challenge to many because it involves people and every one of those people is different. They have different desires, beliefs, values, attitudes, assumptions and behaviors. An individual may embrace one change because it is aligned with their value system and they can answer the “What’s in it for me?” (WIIFM) question. The next change may be rejected because that question cannot be answered or the change is perceived to have a negative impact on the individual, their role or their career.

Therefore before we embark on any change we need to clearly identify the target audience. That is anyone who may be impacted in anyway by this change, both directly and indirectly. We need to understand the target audience and their level of awareness for the need to change.

Through identification of the right sponsors for the change at every level within the organization, equipping them with the skills and capability to raise awareness and create a desire to change we are more likely to have a successful outcome.

Announcing is not implementing!

A communication strategy and plan is a key component of the organizational change program. It needs to address the needs of the audience, the key messages and how they will be packaged and delivered. The sender of the message is important. Messages around the business need for change are received better when they are delivered from the CxO level. Messages about how the change will affect an individual are better received from that person’s manager or supervisor.

We also need to select a variety of practices or activities to ensure that the change becomes embedded and people do not revert to old ways of working or their comfort zone.

In 2011 I wrote a book called ‘Balanced Diversity – A Portfolio Approach to Organizational Change’ which provides 59 distinct practices that can be selected from to embed change. Although the framework introduced in the book can be used for any change in any organization, I have discussed how it can specifically be used within IT service management.

In IT we often expect that providing people with some training or undertaking an ITSM maturity assessment will create the desire for change. It takes much more than that and because every change is different we need to use different practices that address the specific needs of the change and the target audience.

I don’t have the space here to discuss each of the 59 practices but a white paper on the subject can be read here.

Keep checking – there is no room for  ‘set and forget’

Finally it is critical to keep checking back to ensure that the change is being successfully embedded into the organization. We often talk about the Demming cycle in IT service management but don’t apply it to organizational change. We need to plan what practices we are going to use to embed the change, do them but them continually check back to ensure they are having the desired effect. If they are not, we need to act before the situation is irretrievable.

If you don’t want to become a 70% statistic and you want to ensure that your changes are a success, get some organizational change capability on your projects. It will be worth the investment.

Image – © Lilya –