Monthly Archives: June 2016

//June

On being a conference director

Aprill-Allen-smconference-2016-280

 

Conference Director Aprill Allen reflects on her role and her perspective on the itSMF conference experience. Find out more about Aprill and the conference committee here.

 

 

It seems fitting that five years after I became a member of the Australian IT Service Management Forum, I’ll be attending my sixth national conference, this time as the National Events Director.

My first introduction to the itSMF was as a White Paper of the Year nominee for the 2011 conference in Perth. I knew little about the organisation and knew nothing about service management and the frameworks our members rely on to make a difference in the workplace. I’ve since certified in ITIL Foundation and Knowledge Centred Support Principles. I still don’t know much about Cobit, but there’s always something to learn! As a first-time delegate back then, my most memorable experience—even better than accepting the award—was having long-time members introduce themselves to me and connect me with others who have ended up becoming mentors, advisors, respected colleagues and firm friends.

Our conference has evolved over the years to cope with changing economic pressures and the emerging interests of our valuable community of members and sponsors. Last year’s conference, in Sydney, saw the introduction of a new member-driven review process for speaker submissions. It produced a successful program that captured the interests of local and international delegates and inspired new vendors to become active participants in our community.

I stepped into the conference director role for 2016, after Kathryn Heaton’s significant contribution to every Australian itSMF conference I’ve been to, and wondered how I could possibly make my mark after the somewhat radical changes of last year. So I did what every self-respecting marketing-oriented communicator does: I set a left-of-field theme, closed my eyes, and hoped for the best. When I opened them, at our face-to-face programming meeting last month, I was ecstatic to find that our hopeful speakers had understood the brief and grabbed it with both hands. This year, we have a range of submissions that will surely Shake I.T. Up.

We’ve also overhauled our industry awards to align them with the changes we’ve witnessed in the field. Instead of the White Paper of the Year, we now recognise a Thought Leader of the Year, and instead of Service Desk Project of the Year, we now have the ITSM Capability of the Year—opening up our awards to recognise achievement in problem management, change management, knowledge management, service design and more, right across the enterprise. And our changes to the nomination process have removed some of the red tape and barriers that made a lot of extra work for our members wanting to participate.

So, I haven’t had my eyes closed the whole time. Our five-person conference committee has been meeting fortnightly over the phone, since October, to work through keynotes and invited speaker selection, curate ideas for speaker panels, navigate budget considerations, discuss new content and exhibit proposals, work through questions about sponsorship and programming, and more. Until a few weeks ago, I’d been thinking this National Events Director caper was pretty cruisy. Our small committee has been very effective, and our national office and event managers have been an efficient team in managing logistics and a myriad of ideas. To be honest, I wondered where this workload was that my colleagues on the Board of Directors had referred to. Well, now I know.

Conference planning really steps up about 8 weeks out from conference. There are at least half-a-dozen emails flying around most days—tweaks to messaging, attending to finer details of panels, working through the possibilities of late additions to the program, scouting for award candidates and reviewing nominations, honing in on the details of social events, and other exciting trimmings that contribute to the all-important vibe of community in service management that we all enjoy and appreciate so much as volunteers and industry professionals.

I’ve been privileged to see the itSMF conference machine from several different perspectives over these past five years, and now into my sixth. In no time, we will all be in Brisbane, enjoying the camaraderie of a nation-wide community of service management consultants, vendors, practitioners and IT leaders. I look forward to learning more about our field, reaffirming long-time bonds, and building brand new connections in a few short weeks. Maybe you could nominate one of your service management peers. 😉

By |2018-03-19T16:23:19+00:00June 30th, 2016|Service Management 2016|

Are you being served?

lanaTake a sneak peek into one of Service Management 2016’s pre-Conference workshops with guest blogger Lana Yakimoff. Lana is leading two half-day workshops this year: ‘Are you being served? An operational readiness review’, and ‘From BID strategy to operational delivery – where does it all go wrong?’

 

So many corporate and government organisations are ‘transforming’, ‘integrating’, and introducing new services. Stakeholders at times are nervous leading up to the actual ‘go live’ period. However, during Service Transition, an ORR (operational readiness review) can provide reassurance to the custodians of the new service, ensuring all elements required are ready to transition into operations.

The aim of the Operational Readiness process is to help reassure your stakeholders or customers while your project is in flight-mode. The key objective is to ensure the service is working towards readiness for operations to assume full ownership. This activity also helps to provide assurance to stakeholders, and there is sign off and acceptance from the Operational team. It can also identify and manage any risk during the review process. Those risks typically include omitted or unplanned components discovered during an ORR, and allows time to mitigate and resolve the issue/s.

An ORR can cover so many phases or lifecycles, as well as readiness for many different items, including:

  • Design documents: from a high level to detailed solution design documents
  • BCP and ITSCM design, test and acceptance
  • Testing phases documents: test strategy, test cases, scheduling, testing phase acceptance, defect acceptance
  • Business management system readiness
  • Entire Training Phase acceptance – but also tracking all items leading up to training delivery
  • Maintenance and service quality plans

An ORR also includes operational needs which are vital for a smooth transition into service:

  • Account login details provided
  • Support documentation
  • Knowledge articles at the ready
  • Administrative account access or privileged rights
  • Testing phase planning elements and completion
  • Training phase planning to completion
  • Operational monitoring readiness
  • Governance and management forums
  • Specific operational needs to support a service
  • Various operational needs of a business
  • Business processes designed and integrated, ranging from procurement, billing and/or customised reporting needs

Finally, ORR also includes service desk staff remote access and management tools, such as:

  • Procurement
  • Training
  • Operational testing
  • Operational access testing

This is by no means an exhaustive list; ORR also covers many other key topics, from security to organisational change readiness.

Every customer will have similar but also very different needs. A typical project plan will have high-level details and deliverables, however, there are many details that typically are not included in a project plan. An ORR can help keep track of operational items leading up to go-live readiness assessment and decision making.

I’ve undertaken many of these reviews to help provide assurances. A real-time pulse check can show where you’re actually at versus where you should be and potentially allow time to remediate and refocus effort. There are many business benefits to an ORR; when conducted correctly, it can add enormous value.

In my interactive workshop at Service Management 2016, we will cover:

  • A framework approach to conducting a complex or simple ORR
  • Workshops and meetings that can help you conduct an ORR
  • Building relevant IP required

This half day pre-conference workshop at Shake I.T. Up 2016 will provide information, discussions and IP to help ensure a well-focused ORR. Come and join me for a half day interactive workshop, whether you’re an operations lead, consultant, customer or service provider. Learn how to Shake I.T. Up before you Serve I.T. Up.

 

By |2018-03-19T16:23:19+00:00June 23rd, 2016|guest blogger, Workshop|

Communication breakdowns in dispersed teams, and how to overcome them

smconference-2016-workshop-speaker-Korrine-Jones-280

Korrine Jones is our guest blogger today. Korrine will offer a workshop at Service Management 2016 on ‘Leading an invisible IT team’. Korrine is Director and Principal Consultant of OD Consulting, and author of Virtual Team Reality: The Secrets to Leading Successful Virtual Teams and Remote Workers. This blog looks at why communication breakdowns occur in dispersed teams and provides tips on using communication tools and processes differently to increase the quality of communication.

A 2014 study undertaken by Software Advice (Radley) found that communication was the top-cited challenge to managing projects with dispersed teams.  In fact, 38% of the almost 300 professionals surveyed for the study said that communication was difficult for dispersed project teams.

With a wide range of communication tools available these days, including instant messaging, project management tools, wikis, blogs and virtual conferencing via telephone or video, it is interesting to note that the survey found the most preferred communication tool for 41% of the respondents was still email. Delving into the data further, phone is seen as the next most preferred communication channel (36%), 12% selected virtual conferencing as the preferred collaboration option, and only 10% of respondents favoured discussion forums and chat rooms.

However, the survey also found that emails, particularly long email threads, are seen as the top obstacle to effective project communication by 23% of respondents.  In line with these findings, my personal experience has been that dispersed teams often overuse email as their most regular form of communication, with the result of deteriorating rather than building communication, rapport and trust across the team.

The survey results also found that 16% of dispersed team members experienced confusion about which communication channel – phone, chat or email – to turn to for which tasks. It is important to remember when we read these results that the tools are merely the communication channels. While teams I have worked with have found it useful to use a range of tools, to be effective in communication your team needs to agree on how they will communicate and then select the appropriate tool/s for their specific communication needs. Which channel will you agree to use for each type of team communication?

The survey also found generational differences in communication preferences. Specifically, it found that preference for digital mediums (such as email) decreased with age, while preference for analogue communications (phone) increased with age. The study also found that these trends change when looking at videoconferencing, discussion forums and chat, with 35-44 year olds less likely to prefer virtual conferencing and more likely to prefer chats and discussion groups than both younger and older age groups.  This confirms my experience that people have very different preferences when it comes to communication modes and channels. Therefore, a multi-pronged approach is best, particularly in teams with diverse preferences. In this regard, the survey report recommends that a comprehensive communication strategy involving a variety of tools and techniques can help to solidify team connections and improve project visibility.

The richness of each communication channel and its appropriateness to specific conversations is also important for us to consider. For example, communication channels with low levels of richness, such as text-based documents and email, are appropriate for information sharing and one-way communication. As the complexity and sensitivity of the communication need increases, so should the richness of the channel. For example, feedback should be provided by telephone as a minimum and, for complex and constructive feedback, this should be undertaken via videoconference or face-to-face. A recent example of inappropriately delivered telephone feedback occurred within a dispersed learning and development team in a national consulting firm. During one feedback discussion and one performance review, a team member received some constructive feedback that she was not expecting. On both occasions she was taken aback by the feedback and became quite upset. She was quiet on the end of the telephone line for a few moments while she collected her thoughts and got her emotions under control. Each time, her manager responded uncomfortably to the silence on the line, promptly wound up the conversation and hung up on her. This left her feeling even more taken aback and upset. She felt that these situations impacted adversely on her relationship with her manager and eroded the trust they had worked to create.

If these conversations had been held via videoconference or face-to-face, the team leader and team member would have been able to read the body language of the other party and therefore respond more effectively. Therefore, sensitive feedback, as well as conflict and tension should, wherever possible, be addressed face-to-face. If this is not possible, then videoconference is the next most appropriate option.

It is also important to remember that you don’t necessarily need to have highly sophisticated tools to be able to communicate and collaborate effectively. However, you do need to have taken the time to build rapport and trust with team members to make it work. One example that illustrates the value of simplicity comes from United Nations Volunteers. I recently interviewed Michael Kolmet, team leader of United Nations Volunteers working in Africa, for my book Virtual Team Reality. Michael finds that communication can be effective even if the only tools available are email, Skype and telephone, and for them, the video for Skype can be very patchy. So, his team members will always begin a Skype call with the video, but will continue with voice if the video drops out. They find the initial video is sufficient to build the rapport they need to continue the conversation openly.  However, to make this work, Michael and his team members had previously spent time agreeing on shared values and taking the time to build trust and rapport.

The dispersed teams I have worked with, who communicate particularly well, opt for the communication tools that provide greater interactivity. For example, telephone is more interactive than email or texting and Skype or videoconferencing is more interactive than telephone. As the report findings illustrate, we are often guilty of defaulting to email, even with those we do see regularly, but we need to ensure that the more sensitive, complex and substantial discussions are made via phone, videoconference and, if possible, face-to-face.

As a final note, it is also important to choose a form of technology that everyone can use, and to ensure that every team member has access to the technology and has been trained to use it correctly. I have worked with many team members who have a range of interactive communication tools available, but either don’t know that they have access to them, don’t know their full capabilities or don’t know how to use them. It is essential for team members to be familiar with how to use the tools properly so that the team can maximise their capability.

Find out more about Service Management 2016 or register for Korrine’s workshop!

By |2018-03-19T16:23:19+00:00June 9th, 2016|guest blogger, problem management, Workshop|

Delivering Problem Management with Kanban

ian jones

 

 

We are pleased to welcome previous Service Management speaker and member of the ITSMF Awards Alumni Ian Jones to the blog today! 

 

I previously led an IT Service Management team providing Incident, Problem, Change and Configuration Management services in line with ITIL. Our work was highly variable and ranged in complexity since we primarily supported other IT professionals in their IT operations. The whole team used Agile Scrum to manage our work and the problem analysts used Lean Kanban for (ITIL) Problem Management. This blog post will outline how Kanban was applied to effectively deliver our Problem Management service.

Our organisation used Agile as the main delivery method for projects, and Lean (based on the Toyota Production System) for operations. Bell and Ozen (2011, p8) suggest Lean aims to empower teams to simplify, then when appropriate, automate routine tasks. Process improvement frees up capacity, providing individuals with more time and better information to exercise problem solving, creativity and innovation in situations that are not routine.

What is Kanban?

Kanban means sign, signboard, billboard, card or signal of some kind (Liker, 2004, p. 106). It is a scheduling system for Lean, just-in-time production and a system to control the logistical chain from a production point of view. Kanban was developed by Taiichi Ohno, at Toyota, to find a system to improve and maintain a high level of production. The Kanban Method was later added to as an approach to incremental, evolutionary process improvement for organisations (De Haaff, 2013). For readers who are familiar with Scrum, you would be aware of this concept of the signboard or visual management in the form of a story wall. There are differences between Kanban and Scrum and these differences shouldn’t be seen as strengths or weaknesses. Some of these differences include:

Kanban Scrum
Work scheduling  Customer driven pull  Fixed timeboxed push
Task estimation  N/A  Yes
Tracking work  Focus on flow  Focus on velocity
Work in progress limits   Yes   N/A
Process ownership  Team  Scrum Master
Continual Service Improvement  On demand, as defects are seen  At the end of the sprint in the retrospective

 

Application to Problem Management

Initially my team employed Scrum for managing their problem investigations, however we found the concept of timeboxing the work into sprints added no value. Investigations could vary greatly in complexity and therefore finding the root cause and completing corrective actions could be difficult. Task estimation was also challenging and the actual results varied widely due to the above reasons. The team then applied Kanban as an alternative and their wall contained the following columns:

  • Backlog;
  • Post Incident Review (PIR) booked;
  • PIR held;
  • Publish and Task Followup; and
  • Complete.

kanban_wall

 

Kanban suggests that staff ‘pull’ work from left (first column) to right (last column). If staff have capacity  (actual work in column X < work in progress limit in column X) then they pull work from the previous work step (column on the immediate left). This video provides a visual explanation.
The problem analysts employed a series of important variations to their Kanban wall. These variations included:
  • They pulled work from the ‘Publish and Task followup’ and not ‘Complete’ as this step is entirely dependent on other IT staff (tasks like corrective actions are mostly performed by other IT staff) and the duration of task followup is variable;
  • Unlike typical value streams, the problem analysts do not hand over their investigations to other staff and tended to progress the investigation from start to finish (except for extended absences from work). This was because the effort and cost of task switching between problem investigations exceeded any proposed benefits from handovers between investigation steps;
  • Work in Progress limits were informally used and not strictly enforced. If an analyst had too many investigations in a particular column, we used it as a flag for assistance and potentially management escalation rather than a reason to block the incoming work. Upon these events, we preferred to negotiate with stakeholders (service owners, management) on work priorities rather than block the work.
So as you can see, the team took the concept of Kanban and tailored it in a way that supported them, which should not be surprising since problem investigations, by their nature, are not generally standard or repeatable forms of work.

One significant benefit we saw in adopting Kanban was that it supports Principle 5 of the Toyota way: ‘Building a culture of stopping to fix problems, to get quality right the first time’ (Liker, 2004, p.38). The visual management of our work and conducting daily stand-ups allowed the analysts to easily identify defects or weaknesses in their investigations, pause work and jointly derive immediate improvements to their service. This has led to significant quality improvements in their work which was acknowledged by our customers and management.

References
Bell, S., and Orzen, M. (2011). Lean IT, New York: CRC Press.

De Haaff, B. (2013) Kanban the secret engineer killer. Retrieved July 30, 2013 from http://blog.aha.io/index.php/kanban-the-secret-engineer-killer/.

Liker, J. (2004). The Toyota Way, New York: McGraw-Hill.

This blog was originally published on Ian Jones’ blog.

 

By |2018-03-19T16:23:20+00:00June 2nd, 2016|Kanban, Service Management 2016|