Monthly Archives: April 2016

//April

Workshops for Service Management 2016 announced!

Service Management 2016 has announced workshops for 2016!

This year, a range of half-day and full-day workshops are on offer to supplement your Conference experience.

The workshops will take place in Brisbane on Tuesday 16 August 2016 – so you can dive in and get a head start on ways to Shake I.T. Up before the Conference kicks off on Wednesday 17 – Thursday 18 August.

Get practical career advice, develop your leadership skills, improve relationship building, ensure smooth delivery from project intention to outcome, discover new methods or rediscover new approaches to familiar topics, including Service Integration and Management (SIAM), Agile, Lean, DevOps, and the Operational Readiness Review (ORR)!

Workshops include:

  • Agile, Lean IT and DevOps – a survival guide for the mid-career professional with Charles Betz
  • Extreme Leadership Workshop: taking the radical leap with Em Campbell Pretty
  • Behave Yourself: Building IT Relationships with Simone Jo Moore and Mark Smalley
  • SIAM: revolution or evolution? with Simon Dorst and Michelle Major-Goldsmith
  • Leading an invisible IT team with Korrine Jones
  • “Are you being served?” An Operational Readiness Review
  • From BID strategy to Operational delivery – where does it all go wrong? with Lana Yakimoff

Register for workshops and the Service Management Conference with the Earlybird rate before 27 June 2016.

And remember, you can still submit to be a speaker this year!

By |2016-04-29T16:26:22+00:00April 29th, 2016|Service Management 2016, Workshop|

Switch in Action: Business Change Management Applied to Software Engineering

Em-Campbell-Pretty-280

 

 

Our guest blogger this week is Em Campbell-Pretty. Em is a Partner at Context Matters, a blogger at PrettyAgile.com, and an invited speaker at Service Management 2016!

 

One Saturday evening in July, whilst reading Chip and Dan Heath’s Switch, I found myself thinking of the challenges we had rolling out “Trails”, our automated deployment tool. Even though Trails was built by our System Team, using agile methods, including fortnightly demonstrations of working software, the roll out was far from smooth. Would we have been more successful if we had used the Switch Framework (which I blogged about here)? Switch argues that for change to be effective you have to Direct the Rider (our rational side), Motivate the Elephant (our emotional side) and Shape the Path (clear the way).

elephant_with_rider

A few months later, the System Team had another change ready for implementation. This time we would be changing the EDW source control repository from SVN to Git. Given the experience with Trails, the System Team made a huge effort to get buy in from the impacted teams. They spent countless hours at the whiteboard talking with teams about why version control is important and how version control will enable better data in development environments. There was some resistance, strangely enough because some engineers thought the proposal was to replace SVN with a bespoke in house application called “GIT”! The conversation improved significantly once everyone got on the same page. To use the metaphor from Switch, we had started by appealing to the developers’ rational side, the Rider, by Pointing to the Destination: Change is easier when you know where you’re going and why it’s worth it.

As the cut over grew closer, the System Team, using their new found “Jean Tabaka” skills, scheduled a workshop to plan the change. They had learnt from the Trails roll out that no amount of PowerPoint or documentation would make a difference. What had worked last time was sitting with the engineers while they tried to execute the new process and helping them. If Switch was to be believed, we should:  “Follow the Bright Spots. Investigate what’s working and clone it.”

Replicating this approach was not as easy as it would seem at face value. With Trails the change was less invasive, only impacting the engineers executing a given deployment. A member of the System Team could sit with the engineer each time they needed to use the new deployment tool until they were comfortable. With Git, we needed all six teams to make the change at once. After coming to the realisation the System Team were not Gremlins and could not be multiplied by adding water, a different approach was required.

In the days leading up to the planning meeting, EDW Development Manger, +Wayne Palmer had been giving a lot of thought to the roll out approach. His original instinct was to include all the things that “we just had to do” in the scope of the change. The theory being that the engineers were going to have to use a new tool anyway, so they wouldn’t know the difference. Thankfully his train of thought eventually lead him to refer back to Switch. He knew his instincts were wrong, we needed to: Shrink the Change. Break down the change until it no longer spooks the Elephant.  He talked to the System Team Product Owner about the magnitude of the change. They discussed their hopes and fears for the upcoming deployment and decided to defer the major change to the current branching strategy, continuing with branch by project rather than moving to branch by feature.

Even with a smaller change we were still going to need more support than the three System Team developers could provide, if we were going to be successful. Again using the advice from Switch, Wayne suggested we look to increase our pool of subject matter experts by growing our people: Cultivate a sense of identity and instill the growth mindset. Each team was asked to nominate a Git Champion that was passionate about the change and respected by their peers. The System Team then partnered with the “volunteers” to define the process that would be used to migrate the non-production code from SVN to Git.

The change was deployed and to quote the System Team Lead Developer, “It went scarily well”. That is not to say we have not had some hiccups since.  Last week someone accidentally deleted the master branch in order to overcome a merge conflict, by using an SVN technique as opposed to a Git technique. Thankfully these types of errors are easy to back out with Git!

All things considered, the concepts we used from Switch lived up to their promise. I do think we missed a trick when it came to the third component of the Switch Framework – Shape the Path. While the hiccups we experienced have not been catastrophic, with more focus on ideas like building habits they might have been avoided completely. So next time you are looking to change the behaviour of your software engineering team don’t forget:

For things to change, somebody somewhere has to start acting differently. Maybe it’s you, maybe it’s your team. Each has an emotional Elephant side and a rational Rider side.  You’ve got to reach both. And you’ve also got to clear the way for them to succeed.            – Chip and Dan Heath

This blog originally appeared on Em Campbell-Pretty’s blog PrettyAgile.com. You can register to hear from Em and a host of other exciting speakers at Service Management 2016.

Do you have a Service Management story to share? There is still time to submit to be a speaker at Service Management 2016. 

 

By |2018-03-19T16:23:21+00:00April 21st, 2016|guest blogger, Service Management 2016|

Delivering the Message – Things to Consider When Announcing an Organisational Change

kareen-ferries-280

 

We are delighted to welcome Service Management 2016 invited speaker Karen Ferris as this week’s guest blogger. Karen was awarded the inaugural Service Management Champion accolade by the IT Service Management Forum (itSMF) Australia in 2007 and awarded the Lifetime Achievement Award for her contribution to the ITSM industry in 2014.

Every ITSM improvement initiative is an organisational change. Whether it affects one person or a hundred people, it is an organisational change that requires people to change the way in which they do things. It could be a change in process, technology, roles or responsibilities.

Whatever the nature of the organisational change may be, there are important things to consider when announcing and communicating it.

Honesty

Firstly – be honest. Employees need to know the whole story – warts and all. Too often the CxO and senior managers are concerned that staff will be upset by the forthcoming change and therefore avoid telling the whole truth. If it is perceived that employees are going to be upset by the change announcement, the chances are they certainly will be when the change comes about.

So, it is important to tell them about the change as soon as possible so that they have time to prepare – and you have time to prepare them.

Don’t underestimate the time it will take to identify where the resistance to change may come from, put in place a plan to overcome it, execute the plan, continually assess its effectiveness and make changes as required.

Therefore the sooner you understand the reaction of employees to the change, the sooner you can respond accordingly.

You will only know the ‘real’ response if you are open and honest and provide employees with the whole picture.

Managers need to put themselves in the firing line – be prepared to answer the hard questions and to be transparent.

Transparency and consistency will be key if you want to stop the rumour mill. If employees feel that they are only being told half a story they will make the other half up themselves, making your job even harder.

You don’t want to have to spend the majority of your time trying to dispel rumours that only came about because you did not communicate openly.

Everyone Needs to Be on the Same Page

It is imperative that time is taken to prepare the message and to make sure that everyone who is required to deliver the message is able to tell the same story. Everyone needs to be on the same page. Inconsistency will fuel a fire that is waiting to happen.

Time needs to be taken to prepare the executive, managers, and sponsors who will be required to deliver the message. They need to understand the reason for the change and be champions of the change.

They may need coaching and mentoring to (a) help them overcome any resistance to the change they may have and (b) equip them with the skills and capability to deliver the message effectively.

All communication channels need to carry the same story – where are we going? – why are we doing this? – how does this align with our organisational strategy? – when are we doing it? – how are we doing it? – and most importantly – what’s in it for me (WIIFM)?

Test It

It is a good idea to test the message with a sample group of the target audience to determine if the message is clear, concise and complete. Things you may assume obvious may not be so to all employees so you need to remove the assumptions.

The sample group should help identify the questions that employees will be asking. What you assume people need to know may not be the case.

I remember working in an organisation, some years ago, that was undertaking a relocation of a department to another part of the city. Management assumed that staff wanted to know about recompense for additional travel, whether there would be parking available, how accessible the new location was by public transport etc.

But this wasn’t what was causing concern. It turned out that the biggest question staff wanted to know was whether the kitchen would be equipped with a microwave oven! This was because another department, relocated earlier, had not initially been provisioned with a microwave oven which they had previously had access to.

Don’t assume employees won’t sweat the small stuff. They will! Your sample group can help identify what this may be.

Check It

Throughout the period of communications you need to be checking its effectiveness. You need to regularly check understanding of the message. Don’t assume that because no-one has asked a question that the message has been understood. Silence does not mean that all is good!

There are various ways to check the effectiveness of the communications and it will be the change agent’s job to determine which are the most appropriate for the organisation.

Employees can be surveyed to determine if they understand the change.

At a recent client engagement I created and distributed the communications regarding a forthcoming change. Customers using a particular application were required to change the way in which they submitted service and support requests. The customers were distributed across the country so I followed up the communication by randomly picking names from the email distribution list and telephoning them to determine if they had read the communications and whether they had any concerns, questions etc.

This helped me understand whether the communications were having the desired result and to make any changes as required.

Other methods to determine communication effectiveness include focus groups, observation, monitoring collaboration channels, monitoring traffic on web pages where information about the change resides, monitoring feedback channels etc. It is more likely that if you are not getting feedback or questions, the change has not been understood or is being resisted.

Organisation change management models such as ADKAR can be used to determine if communications are having the desired results during organisational change. ADKAR can tell you whether employees are Aware of the need to change; have a Desire to participate and support; have Knowledge of the change and what it looks like; feel they have the Ability to implement the change on a day-to-day basis; and have the Reinforcement to keep the change in place.

ADKAR is used for much more than just checking communication effectiveness so is an ideal tool to have in your organisational change management toolbox.

Answer the Questions

It is important to answer all the questions received from employees. In the client engagement I mentioned earlier, any questions I received about the change were collated and the answers were distributed in future communications. Each communication had a FAQ section. The chances are that if one person asks a question about the change, there are myriad others wondering the same thing but not prepared to ask.

Collect all questions asked and provide a FAQ either in distributed communications, via collaboration tools and/or on the intranet.

Strike a Balance

Communications should be balanced. They need to be frequent enough to help employees with their transition and addressing their concerns and questions but not overly frequent to the point that people stop paying attention.

Also give due consideration to the communications channels. If employees hate SharePoint, don’t use that to deliver your message despite it being the corporate collaboration tool!

Note: I have nothing against SharePoint!

Use a variety of channels but ensure they are ones that employees will access. Just like communication content effectiveness should be checked, so should the effectiveness of the communication channels.

Monitor the number of emails that are opened. Monitor the number of click-throughs to the web site. Monitor the number of downloads regarding the change from the intranet. Monitor the number of impacted employees attending information sessions.

All of these, and more, can help you determine which communication channels are having the greatest impact so you can give them more focus. There may be communication channels that you stop using as they are having the least impact. But you won’t know unless you monitor it. As with anything else, the adage ‘you can’t manage what you don’t measure’ also applies to change communications.

Summary

Your organisational change communications need to be honest and transparent. The message, and the deliverers of the message, need to be carefully prepared. There needs to be one story and only one story.

Test the message and regularly check the effectiveness of the communications. Answer all the questions being asked and make the questions and answers accessible by all impacted employees. Ensure that your communication channels are appropriate for the change in hand and will be accessed by impacted employees.

Finally, be prepared to change course. If it’s not working, stop and make the required adjustments to get back on track.

This blog post was written by guest blogger and Service Management 2016 invited speaker, Karen Ferris. You can register to hear from Karen and a host of other exciting speakers at Service Management 2016.

Do you have a Service Management story to share? There is still time to submit to be a speaker at Service Management 2016. 

 

By |2018-03-19T16:23:21+00:00April 12th, 2016|guest blogger, Leadership, Service Management 2016|

Welcome to Service Management 2016!

Aprill-Allen-HGIH-RES-APR15-Editted

Welcome to the Service Management blog for 2016!

We are delighted to be back and looking forward to celebrating at itSMF’s annual conference on Wednesday 17 – Thursday 18 August 2016. We will also host a pre-Conference Workshop day on Tuesday 16 August, and of course, the highly anticipated Gala Awards Dinner on the evening of 18 August 2016.

This year, the Conference will be held in beautiful Brisbane, and centres around the exciting theme of Shake I.T. Up! Over two dynamic, invigorating days, we will explore ways to ‘shake up’ IT projects and teams. How can we adapt, innovate, or disrupt to ensure greater agility, long-term improvements, and better outcomes for all?

We are now in the final remaining weeks before speaker submissions close. If you would like to share your successes and challenges and connect with an engaged community of your peers, now is the time to submit a speaker proposal

Over the next few months, our Service Management blog will feature exclusive interviews and articles from our speakers and workshop leaders, as well as content that explores ITSM and how we might think about shaking I.T. up!

We look forward to sharing this with you in the lead-up to Service Management 2016.

Best wishes,

Aprill Allen

Conference Director

By |2018-06-30T15:20:27+00:00April 6th, 2016|blog, ITSM, Service Management 2016|