If You Want to Remain Relevant it Starts with YOU Taking Action!

The itSMF UK annual conference asked some serious questions around the relevance of IT service management (ITSM) in a rapidly changing world and landscape of other emerging practices such as Agile, DevOps, and Lean ways of working. As Rosemary Gurney stressed at the start of the conference – this was a ‘pivotal’ conference for us to explore our relevance and the way forward.

IT’s Relevance

A highlight for me at the conference was the ‘Great Relevance Debate’. Some of my key observations from this were the recognition of the need to move away from the ‘prescriptive frameworks’ and the discussions around ‘this framework’ or ‘that framework’. It was also clear that the role of IT HAS changed. Yet many are still seen as ‘order taker’. Emerging technologies such as Artificial Intelligence (AI) and Machine learning are becoming critical business enablers. IT has to ask ‘how can we enable and drive business change’, because if we don’t the business will look elsewhere! However, IT has to first get closer to the business to gain a better understanding. I can certainly underscore this. ‘IT has too little understanding of business impact and priority’ is a top scoring ABC (Attitude, Behavior, Culture) card in our global workshops and has been for 15 years!

Eventually we need to shift to ‘one team’ as CIO of the year Ian Penny from Hiscox explained, he didn’t mean one end-to-end IT team! We need to blur the lines between business and IT, ‘tear down the distinction’. This requires a shift in culture, skills, and behaviour from both IT and the business. ‘Don’t wait for the business to tell you what they need, they also don’t know. The world is changing, business models are changing. IT is a critical enabler and the business needs IT to be a partner’.

Ultimately there needs to be more focus on business value, more governance oversight, better understanding of customer experience (CX) and service management will become part of the job for all, ‘throughout the DNA of the organisation’… if we can develop the right skills to be able to accomplish this!

What can we do to remain relevant?

I took the key messages from the debate forward into my Phoenix Project DevOps simulation walk through. Playing the role of CEO I referred back to the findings from the debate. I challenged delegates -‘regardless of whether you want to ‘do’ DevOps, whatever that means, some of the key concepts, such as the three ways, are equally applicable to ITSM’. The guiding principles from ITIL Practitioner such as ‘focus on value’, ‘progress iteratively’ and ‘collaboration’ are also central in DevOps thinking.

As we walked through a scenario in the simulation we captured key pain points and issues that delegates recognise in their daily work:

  • Work was ping-ponging back and forward. Going back up stream, causing disruptions and either slowing or stopping the smooth ‘flow’ of work
  • People were too busy, but neither the business nor IT decision makers had insight into the work being done and how this related to business value
  • Business value was not communicated and not used to prioritise resources.
  • There was no clear relationship between changes, technical activities, and how these related to business priorities – work was entering each area from business, from IT management, and from end-to-end colleagues, often without the business value context, causing IT to make the wrong choices and create more rework
  • Testing and security had little insight into work being done, (or NOT being done) and were therefore unable to identify potential impact and risks to value. Often resulting in defects, risk, and rework
  • In terms of roles and responsibilities there were many ‘assumptions’ and lack of clarity or agreements resulting in ‘blame’
  • In the end mistakes were made which would cause more unplanned work in the next round, reducing the amount of business work flowing and creating a vicious circle of more defects, and more rework. Alan Nance in his presentation the ‘Battle for Relevance’ presented a great sheet on this, taken from the DevOps summit and translated to ITSM. Which clearly indicated the value of effective problem management as a ‘feedback’ mechanism (second way of DevOps) to help prevent passing future ‘defects’ downstream. (First way of DevOps)
  • The business did not share value of short-term features and projects and did not share their strategic portfolio of intentions, nor help IT prioritise scarce resources
  • ‘Fake news’ was given, giving the ‘socially expected’ answer to questions. Fear of blame influencing communication
  • Mistakes were not used as an opportunity to learn, but for a way to look for and pass blame
  • Fortunately, we did capture all of these on a flip-over representing visible end-to-end recognised ‘improvement needs’ (third way of DevOps, continual learning and improvement).

‘Just like reality’ said one delegate! Is it any wonder we struggle and are seen as ‘order takers’ but equally the simulation raises the need for the business to change their mindset and behaviours too.

We then explored the three ways of DevOps in more detail, particularly flow and never passing a defect downstream, feedback, particularly ‘when is work done’? – (when CX or value is realised), and the third way ‘experimenting, learning from failure in a no blame culture’.

The team was given the task of organising their own stand-up and managing the improvement. It felt uncomfortable, the business roles were unsure of their role as product owner. The IT leader was uncomfortable letting go of control, and the team had difficulty effectively collaborating. A ‘self-empowered, self-steering team’ isn’t easy. The business relationship manager (BRM) in the room claimed a leadership role in ‘orchestrating’ the team around value. The team explored this  – if there is no BRM the team discussed other potential roles to help facilitate developing this capability.

What can we take away? Other than paracetamol?

Delegates were asked at the end ‘What are your key takeaways, what will you take away and try to apply? After all we all recognised the challenges and issues at the start of the simulation and we all want to remain relevant in the future?

  • ‘Pain’! I will buy some paracetamol (as part of the DevOps toolkit)! It’s all about culture, behavior, and leadership. Leadership has to help coach and facilitate the change. Yet we saw how difficult it is for leaders in a new way of working. The need for coaches (endorsing Karen Ferris’ approach and the three roles for organisational change). Note: although the comment about paracetamol was a joke it highlights a top theme in our industry at the moment #mentalheath and #mentalwellbeing as we are drawn increasingly into a world of relentless change
  • Start gaining visibility for effective resource planning (work in progress) and prioritisation of resources
  • Develop leadership skills and styles to enable and empower the right culture and behaviours (servant leadership)
  • Understand business value in order to better prioritise (on the one side ‘value creation’ and new features, on the other side ‘value leakage’ – with technical debt, defects, and risks). This requires effective governance
  • Engage people in improving their own work. Seek input, confirm understanding, and agreement
  • Prepare for pain and failure and use this to learn and improve
  • Understand the DevOps method (the three ways) and the need for iterative improvements
  • Communicate throughout the end-to-end flow, e.g. value, prioritisation, understand ‘up-stream’ and ‘down-stream’ communication needs
  • One size does not fit all (scope and adoption level of DevOps) and one size does not fit all (team culture, maturity, need for coaching)
  • Make it visual, see the priorities, see the work in progress
  • Understanding the pipeline, and in relation to business value coming down stream
  • Start small – pick a product or value stream to map and practice improving flow, removing constraints, and demonstrating value of approach.
  • Learn prioritisation between business and IT.
  • Your definition of DevOps, your definition of ‘when is work done’?

Conclusion

The panel debate clearly concluded that we’re very relevant in moving forward, especially with the increasing importance of IT as a business enabler and the risks posed by ineffective governance of IT. If you recognise the challenges and issues the team recognised in the simulation exercise, take a look at their takeaways and see which ones are relevant for you to learn from and apply yourself. If you want to remain relevant it starts with YOU taking action.

Director & Owner at | Website

Paul has been involved in the IT industry for more than 25 years and has a broad background in IT operations, IT management and product innovation and development. He was project team lead in the original BITE (Business & IT Excellence) process modeling of ITIL, an ITIL V2 author and member of the ITIL V3 advisory group. He is co-owner of GamingWorks and co-developer of a range of business simulations focusing on IT Service management, Project management, Business Process management, Business and IT alignment, Alliance management and co-author and developer of the ABC of ICT products and publications.

Scroll to Top