​Somebody asked me earlier today, "What do you do?". I gave my usual self-deprecating response, then got home and thought about it. Why do I answer so flippantly outside of the work environment?
Time to regroup and give myself a good talking to.
Simon Sinek tells us to "Start with Why".
Why do I do what I do?
To help people.
I've worked in IT roles for over 30 years, in roles like data entry, helpdesk, desktop support, server and network support, team leading and management, working with teams in the UK, India and New Zealand. I have been extremely lucky to have been supported throughout most of my career by organisations and managers who helped me and gave me what I needed to succeed. Since going solo in 2010, I have only wanted to help others to succeed. People and process are my "thing".
How do I do this?
There are a variety of methods, and they often merge into each other.
I consult, to help organisations and teams to get to where they want to be and in a way that means they can generally support themselves moving forwards.
I coach / mentor to help individuals grow.
I train people to learn new ways of thinking and working so they are comfortable moving forwards.
I contract as IT Operations Manager to help organisations when they find themselves in a bit of a pickle.
What do I do to achieve this?
Consulting usually focusses on Service Management, DevOps, agile and Lean ways of thinking and working, and governance / audit.
Coaching / mentoring (I've never had a coaching session which hasn't required mentoring or vice-versa) uses experience and knowledge gained over many years of making mistakes and learning from others.
Training can be provided as online training, simulation workshops for larger teams or tailored training sessions to provide an overview of subjects such as Service Management or DevOps (not technical though). I also enjoy helping teams to understand the culture they want to have to help get the people, management and organisation all understanding each other and helding in a mutually agreed direction.
What's YOUR Why?

I’ve been working with ITIL since the early 1990’s when I was first introduced to it at F.I. Group and worked my way through the Foundation certificates, ITILv2 Manager’s Certificate, ITILv3 Expert and recently ITIL4 Managing Professional certificate. 

Then, once I became a self-employed consultant, the breadth of my knowledge grew, as I started to absorb other ways of doing things.  About 12 years ago I started to play with COBIT, through 4.1, 5 and now 2019.  Then I started to speak with people who used Lean Six Sigma and learnt a bit about what they do and how they think and work.  I can’t say it made a huge impact on me, but I was aware.

In 2016 I was encouraged to get interested in DevOps and flew to San Francisco for the DevOps Enterprise Summit conference. That was interesting for a few reasons. Firstly, I’d never been surrounded by so many developers before. I also realised that just because they used Ops in the title, it did not mean that they would talk about Ops, although admittedly there were two out of many which did. Those speakers were Mark Imbriaco and Erica Morrison. The conference was also during the 2016 presidential election results, so as you may imagine, that in itself was interesting. 

Through DevOps I started to look at agile ways of working, Lean IT and Kanban.

Due to my interest in all these things and my own inability to remember as much nowadays, I have to keep refreshing myself about all the different versions, frameworks, ways of thinking etc. and that’s because there is so much to learn. If you want to work in a modern organisation, it is expected that you will be across or aware of most of these approaches. You may not need them all, all of the time, and in some roles, you may not need some of them at all, but most modern organisations who have been through some level of digitisation will be using or talking about those approaches.

It’s this interest in all the different ways of thinking and working which has made me realise that we’ve now reached a point where all frameworks or approaches seem to have a set of principles behind them, whether it is the so called dinosaurs of ITIL & COBIT, or the cool kids at the party, DevOps, Lean etc. Agile tries to convince people that it’s cool, but it’s nearly as old as ITIL and Kanban is older than all of them!

So principles. What are they?  Why do we care about them? Why do we need them? What are all of these principles? 

ITIL 
ITIL4, released in 2019, introduced the 7 guiding principles, down from 9 in the Practitioner book. 

These principles are :

• Focus on Value 
  • Everything we do, whether it is in IT, teaching, manufacturing, retail, chimney sweeping or any other business, is about value. If we aren’t adding value, why are we doing it?
• Start where you are 
  • Don’t reinvent the wheel.  If you are looking to improve something, find out where value isn’t being delivered and start there. You don’t need to start from scratch though.
• Progress iteratively with feedback 
  • Make small changes and then ask your stakeholders if it's any better. If not, move on.
• Collaborate & Promote Visibility 
  • Work with others and be transparent
• Think and work holistically 
  • It’s not just about you or your team. Any change in your processes or ways of working may have an impact on many others, so consider them and the wider organisation.
• Keep it simple and practical
  • Let’s not over engineer anything or make it so complicated that people now or in the future haven’t got a clue what it means.
• Optimise and Automate  
  • Improve improve improve and then if there is value and you believe you have the improvements optimised, automate it.  This could be scripts, SM tool portals or a wide range of options. 

COBIT 2019

Then we have COBIT 2019.

1. ​Provide Stakeholder Value
2. Holistic Approach
3. Dynamic Governance System
4. Governance Distinct from Management
5. Tailored to Enterprise Needs
6. End-to-End Governance System

COBIT 2019 has basically stuck to it’s guns and been fairly stable, although it has made a few minor tweaks from COBIT5.  Many of its principles link in with those from ITIL4 and are also reflective of the DevOps principles.

They are very formal but clear: deliver value, think end to end & focus on a dynamic governance system as well as management.  This is pleasingly what you expect from COBIT.   

Agile

Now agile, which has its roots in the early 1990s with approaches like RAD in 1991, Unified Process & DSDM in 1994 as well as Scrum from 1995 is probably best known for it use mostly in the development world, but there’s plenty of other uses and flavours out there, with agile project management, agile managing & agile parenting courtesy of Rob England and Dr Cherry Vu at Teal Unicorn, and many other varieties of agility in the workplace.  

You can see their principles here:

• Customer Satisfaction
• Welcome Change
• Deliver Frequently
• Working Together
• Motivated Team
• Face to Face
• Working Software
• Constant Pace
• Good Design
• Simplicity
• Self Organisation
• Reflect & Adjust

Fundamentally, it's about satisfied customers, welcoming change, working together, delivering frequently at a constant pace, talking to others, being motivated, self organising and adjust when you need to. 

Kanban
Then we have Kanban which came about in the 1940’s or 50s at Toyota in Japan, with the intention of reducing stockpiles of material and to limit production to demand.
The 5 key principles of Kanban which have now been arrived at are:

• Limit Work in Progress 
  • focus your efforts on fewer things at a time to ensure a faster flow of deliverables. You can’t work on lots of things at the same time, so don’t try.
• Make Process Policies Explicit
  • Build your standards into the way you do your work rather than bury them in documents. Make doing the right thing obvious and easy.
• Visualise the workflow 
  • Make your up to date work and workflow visible to the team and stakeholders at all times
• Improve collaboratively 
  • Work together to improve continuously with a focus on results as a team rather than individuals.
• Manage Flow 
  • Use your board and the data it generates to identify and iteratively remove blockers to work flowing smoothly through the system

DevOps
The principles of DevOps are lovingly referred to as CALMS or CLAMS if you prefer kaimoana.
CALMS for those of you who may not be aware stands for 

• Culture, 
• Automation, 
• Lean, 
• Measurement and 
• Sharing. 

Culture
Getting the culture right is hard.  Most people reading this are probably working and breathing within the IT Operations sphere of an IT department. Or connected to it.
IT Ops people, generally don’t like change. We are designed to keep things steady; keep the lights on. It’s what we have learned over 5, 10, 20 years of Ops work. If things are changing, it’s the Operations person who gets the call at 2am and has to fix the server, network or whatever is broken. 

Ops are risk averse.  So you need to create an environment where they feel safe and can experiment.  

It’s all about creating a safe environment where they can not be blamed. Too many CIOs still blame IT Ops as a team or individuals when something fails. If that happens, then you are never going to get people who want to try new things or better ways of doing things.  

Start at the top.  

Automation
So many DevOps conferences, presentations, articles etc talk about tools.  If you are an IT Operations team keen to use the DevOps principles to improve the way you are working, it doesn’t need to be a massive spending spree.

Monitor everything that you can. There are some great free tools and some great cheap tools which will help you get started. Hard to believe maybe, but there are organisations out there who don’t monitor servers - capacity or availability, networks, applications.  Learn what is happening. Alert when it is sensible to alert. Keep fine tuning.  If you don’t know what is happening, you can’t improve it.  

As you learn what needs to be done, to fix issues, look into what can be done to stop those issues. Most tools allow you to script auto-actions before alerting, so look into that. 

Do you have to perform the same task day in day out? Try and script it. If you can’t do it, get a contractor in for a few weeks to do it.  Work out what you need doing and get the contractor to script it for you.  A few days of a contractor will save you weeks or months of work redoing tasks or reacting to alerts. 

Lean
Lean is all about 

• Identifying value, 
• mapping the value stream, 
• creating flow, 
• pulling work and 
• striving for perfection. 

Note, this perfection is primarily to ensure that in your workstream you don’t pass errors to others in the flow. That creates rework and is waste.  

Lean is all about reducing waste. Don’t do the stuff that doesn’t need doing. 

So if we imagine a new member of staff is being on-boarded. The new person will be adding value to the organisation (identify value). The Value Stream will list all the teams involved in onboarding, their tasks and how much effort they need to put in. The flow of work is understood. 
Now let’s imagine that HR makes a simple spelling mistake in the individual’s last name - got the i and e the wrong way round - which is easily done when humans are involved.  

The new starter goes to get their id badge, but the name is spelt wrong. No biggie, but the badge needs to be redone. Then they sit down and their AD account is wrong because IT had the wrong spelling. Again, no biggie but that and their email address need to be changed. Then payroll ask the person to fill in an online form. Guess what..they have the wrong spelling, so the bank won’t recognise the person. More rework.  None of it may be big, but it all adds up. 

So just like most things in IT, baseline where you are. If you think you can speed up the time it takes to provision a new starter, understand how long it takes now. How often does the requester come back with “Very nice, but it doesn’t have this installed”  or “We requested a new user be set up with a laptop, but they don’t have the right software or access to the right groups in AD”. Measure this as a baseline and then try to improve it.  What are the new measurements? Have things improved - whether time to deploy or perceived satisfaction? 

Then you will know whether you are improving. If you aren’t why not? Can you improve on it further? Should you undo what you have done and try something else?  

Sharing
Another key tenet of DevOps is the sharing of knowledge, information and capabilities. 

Share knowledge of systems with colleagues, to reduce the risk to the business if you aren’t there. Give yourself a break from being called during the night or holidays. Heroes are not the ones who get woken up at 2 am to fix an issue that nobody else knows about. Heroes are the ones who share knowledge and skills so that they DON’T get called up on holiday. Start to embed that in the culture. 

Share capabilities with others. Fed up of getting calls for simple tasks? Show the Service Desk how to do it. If they don’t have permissions, script it so they don’t need the permissions.  

Shift Left

So for example, Change Management people could share what they are looking for in a Change, so that everyone knows what is needed before the change is reviewed.  

Sys. admins could provide developers or projects with their non-functional requirements at the start of a piece of work, so it doesn’t have to be rejected at time for support.  

If you can give others further left in the flow (remember that?) the information they need to give you what you need, then does it need to go to CAB? Could it just be a tick box and implemented? 

There’s a multitude of areas where knowledge, skills, capabilities, requirements etc can be shared with others to enable value and to deliver that value to the wider business.  The more that is kept in silos or individual heads, the slower everything becomes. 

You won’t lose your job if you share knowledge. You might, if you don’t. If you can share everything you know and do, the chances are you will get more opportunities in exciting areas. 

Shared Principles

So, we have all these approaches and ways or working, but I think we can extract the following 6 key shared principles to help us on a day to day basis

• Identify & deliver value - have satisfied customers.
• Understand how work flows and collaborate with customers and colleagues
• Keep improving how we work so we don’t stagnate. 
• Build and maintain a culture which welcomes change, collaboration and the sharing of knowledge, skills and information. One which embraces no blame and experimentation
• Always think end to end. Get rid of silo thinking
• And Keep it Simple! 

So there are many different frameworks, approaches and ways of working out there which help us work smarter.

And I’m not suggesting that you shouldn't learn them. If there is value to you or your job in learning them, get out there, read books, do courses, become certified.  But do you NEED to?

I think there are only 6 key things you need to remember, to be able to work effectively and efficiently in most roles.

Thoughts?

Way back in 2015 I wrote a couple of posts about meeting etiquette. One was for physical meetings and one for online / phone meetings.  Things have moved on with online meetings and following a post on LinkedIn from Kendra Ross I thought I ought to update my thoughts. So, once again, in no particular order:

Organisers

• If you are arranging the meeting send everybody the correct method to connect to the meeting.  Check that it works before sending it. Send it in a meeting invitation and not in a separate email. That will get lost.
• Be aware of the technology you are using and how your guests might be connecting. Are there any corporate restrictions on inviting external people to your Teams meeting?  Do all attendees need to be using a locally installed version of Zoom to get all functionality, or is the web version ok? Will people need to download anything on their tablet / mobile phone before being able to join? 
  
• Make sure that  if there is a waiting room, you are using the right account when you join, to allow people in. 

Attendees

• Check that you have the means to use the methods provided, as soon as you receive them.  It is frustrating for all, to have attendees turning up at random periods after the start time because their phone / tablet / laptop / computer couldn’t use the appropriate technology for the meeting.

Everyone

• I think it would be fair to say that standard meeting rules apply, as it doesn’t really matter what forum the meeting is in, it is still a meeting.  However, turning off electronic devices may be difficult due to the way you access these meetings. You should however, not carry out other work in the background.  Your lack of attention WILL be found out.
• If the meeting involves webcams, try to sit where there will be the least amount of distraction behind you.  If you have to use the in-built webcam, try and angle your screen so that people aren't looking at your chest or up your nose. 
• Turn up a few minutes early. Test your connection. Have everything ready so that at the agreed time, the meeting can start.
• Mute your phone / microphone when you are not talking.  Other people do not want to hear your background noise, whether it is builders, children, animals, emergency services sirens, office chatter or anything else. Yes, we are now more accepting of life happening around others, but that doesn't mean we want to listen to what is happening around you all the time.
• Use headphones rather than speakers, if possible. This reduces feedback.
• If you are going to use bluetooth headphones for the microphone, charge them. Also, make sure they are not connected to your mobile and laptop, cutting you off when someone calls your mobile.

As Kendra states in her post:

• Have a buffer between meetings of 10-15mins either side. Hopefully this ensures you aren’t late & gives you the added benefit of a break to stop video conference fatigue
  
• If you are going to be late be respectful of that person's time - message them to give an ETA but also confirm they still have time to meet, otherwise reschedule.
  
• Apologise if late, I’ll say this again, apologise if late! It can help take the sting out wasting their time.
  
• Have a good look at who you are often late for, do you think they are less important? Do you not value them? What is the silent message you have sent them by been late?
  

What's missing?
 

It's interesting to see how over the years, certain things are always at the fore of an IT Operations Manager's sleeplessness.

• High workload - balancing BAU with Projects
• Tools - Unable to get the best tools to enable the team to do the best job
• Team size - There's never enough people, based on the amount of work coming through the door
• Skills - There is never the time or budget to provide enough of the team with the right skills, especially as new technology is introduced through projects
• Technical debt - The team are expected to support old and often unsupported hardware of software.

While it is often comforting that so many IT Ops Managers experience the same issues, it's also disconcerting that so many are still experiencing all, or some of this pain.

So how can this be addressed, so that you can sleep at night without alcohol?

• High Workload
  • Use visualisation / Kanban style boards to show ALL the work that the team has on. Work with your CIO, PMO other stakeholders to prioritise the work; either MoSCoW or Eisenhower matrix can be used to prioritise.  Prioritise on value, not by the loudest voice.
  • Then limit the team's Work in Progress so that they are working on one thing at a time (or however many is reasonable). They will achieve more this way.
• Tools
  • Tricky one as it depends on your internal processes for Capital / Operational spend.  Proof of Concepts often work well, but so can highlighting what work can't get done (see above) based on the lack of tools.  Take prioritisation back to value-based prioritisation and that may well help drive the conversation the way you need it to go.
•   Team size
  • I see this regularly and often it's not the answer. Improving the flow of work, identifiying constraints and looking to shift left or automate wil often deliver more benefits to the team and the wider organisation, than just recruiting more people.  Not always, but often.
• Skills
  • Using thinking like KCS and Intelligent Swarming will often deliver this skills transfer without the need to spend more time or budget on training. 
• Technical debt
  • See the first point. Prioritising effectively allows you to highlight that if certain areas are not upgraded, then particular priorities cannot take place.  Also ensuring that work to introduce new technologies includes the removal or upgrade of older technologies as well. No more dead cats. 

If you would like help introducing or improving any of these areas, please get in touch and let's work together to make you look even better than you did this morning.

Ok. This might seem odd for some of you to hear me say this, but it's true.  

I'm not going to go into too much detail here, because I have written a way too long thing about it for Scopism, but most frameworks or ways of working just require you to understand and use a few principles. 

ITIL - ITSM

• Focus on value.
• Start where you are.
• Progress iteratively with feedback.
• Collaborate and promote visibility.
• Think and work holistically.
• Keep it simple and practical.
• Optimize and automate.

DevOps

• Culture - get the culture right - No blame - Experimentation & learning
• Automation - Automate stuff if it's going to add value
• Lean thinking - Understand flow, identify bottlenecks.
• Measure - so you know that improvements are just that 
• Share - Share knowledge, skills, tasks. Shift left. 

COBIT 

• Provide Stakeholder Value
• Holistic Approach
• Dynamic Governance System
• Governance Distinct from Management
• Tailored to Enterprise Needs
• End-to-End Governance System

That's pretty much all most of us need to do our jobs well. And fundamentally they all agree with each other. 

However, if you want to know more about any of these, check out the training options I have available. 

In October 2019, I will have been an independent consultant and contractor for 9 years. This blows me away.

It's not been an easy 9 years, with my finger hovering over the "apply for benefits" button on one occasion because I hadn't been able to get work in for 6 months, and a couple of applications for permanent roles made, just because I couldn't see the light at the end of a long dark tunnel. I still say "never say never" to permanent roles, because if the right thing comes along, I would be silly to turn it down, but it's not my priority.

However, the positives have outweighed the negatives and I am SOOOOO glad I did it. 

Being independent has enabled me to:

• Spend time with my family when needed (most of the time) and (mostly) work sensible hours. 
• It has enabled me to move around different companies and learn from different people. I've now worked in Broadcast, Health, Tertiary Education, Retail, Local Government, Manufacturing, Managed Services, Charity, Communications and Utility sectors, which I wouldn't have easily been able to do if I had stayed in permanent employment. 
• It has broadened my network, enabling me to have close professional and personal friendships globally.
• It has enabled me to provide coaching and mentoring to people. 
• It has enabled me to give time back to the community through board membership of itSMFnz.
• It has also enabled me to set up Good Guidance with Aprill Allen, Karen Ferris, Robert Bull & Paul Phillips, which has allowed us all to expand the area that our net casting covers and to provide clients with improved offerings.

Will being independent work for you?
I'm a consultant, so I am legally obliged to answer with "it depends".  You need to:

• Be flexible.
• Be willing to travel.
• Be willing to stay away occasionally.
• Be willing to listen. You can't offer advice if you don't listen
• Be flexible.
• Be willing to learn from others. Your clients often have different perspectives that you may not have considered. Don't discount them.  

So these nearly 9 years have been challenging. They have been satisfying. They have been enlightening.  Has it made me rich? Not financially. Emotionally? Yes. 

If you have been a client, a colleague, a friend or my family, THANK YOU!   

I've written before about what teams get out of The Phoenix Project simulations and how they can learn the principles of DevOps in an experiential way. However, that was always focussed on DevOps. 

Now, ITIL4 is a big change in the ITIL world. ITIL didn't fundamentally change from V2 to 2011 and while the world skipped off to embrace agile and lean thinking and play with the cool kids of DevOps, traditional Service Management and IT Operations seemed to continue to do things the same old way. ITIL4 is now kicking stones around the outside of the group of cool kids and may even join in soon. It too has embraced lean thinking, using Service Value Chains, iterative improvements, and the whole Guiding Principles approach, introduced with ITIL Practitioner.  All things that many good consultants and experienced service management practitioners were doing as they adopted and adapted ITIL, but it wasn't as clear in the framework before.  

The MarsLander simulation from GamingWorks has been redeveloped to allow teams to experiment and experience how ITSM and IT Operations teams can operate in a more lean and agile method. This brings obvious benefits in organisations where development or project teams are more agile and the Operations teams continue to be more traditional. They can all start to think the same way. It also allows those IT teams that don't need to change because of outside influences, but just want to change so they are operating better, to learn about and try different approaches. Then there are those teams who have gone through ITIL4 Foundation training and know the theory. MarsLander allows them to put it into practice and see how to use that knowledge.    

Aprill Allen - aka Knowledge Bird - and I are currently working with a client, as part of the Good Guidance collaborative team, to help them adopt a new and improved way of working. As a Managed Service Provider, they have been operating well for a number of years, always reviewing how they can improve and deliver greater value to their customers, but now it has been decided that a fundamental shift in thinking and working is required. As part of their learning experience, I ran a MarsLander simulation for a number of their team, including CEO, CDO, Service Delivery Manager, HR Manager and a number of technical people including Service Desk.  I'm not going to go through their findings and learnings with you here, as that would take the fun out of you experiencing the simulation, but there were some key outputs which resonated with them, and every other team who has run the MarsLander or Phoenix Project simulations:

• Prepare before planning​
• Communicate between teams
• Collaborate effectively
• Create feedback loops
• Understand goals, roles and the strengths of those around you
• Have an end to end view of your work
• Share knowledge whenever and wherever you can

​An earlier blog of mine pointed out similarities between different ways of working and thinking, with regards to learning, so the gods must be trying to tell us something. 

What do you need to do to make change happen? 

There's a lot of change going on in the way that organisations work.  For many years we have, generally, carried on in the same manner, working in the same way. Whether this is in IT, HR, Finance, Logistics, Retail, or any other part of the organisation, we've pretty much done things the same way for several years. There have, of course, been small changes in the way things have been done, but, at least within the IT world, we seem to be rolling out new ways of thinking and working at a rather busy rate.

In the last few years we have seen a formalisation of SIAM (Service Integration and Management), VeriSM, ITIL4, COBIT 2019, Lean IT, DevOps, Agile ITSM, Cynefin, etc and along with those approaches, we have introduced teams to ways of thinking and working that have been used elsewhere for a while, like visualisation of work, Kanban, Value Stream Mapping, Theory of Constraints, servant leadership, constant organisational change management, agile management.....a growing list.

Don't get me wrong, this is all very good stuff and is needed in many organisations. Some are further down the path of change than others, but that has always been the case and always will be. 

All these "new" (to some) approaches can be overwhelming. The other weekend I felt like I was back in the technical world, which I left because it was all changing too quickly for my little brain to cope, with what felt like a barrage of new approaches to thinking and working.  However, when you take a step back and think about it over a nice cup of tea, it's not too bad.

Many of the approaches I have mentioned are fundamentally saying the same things. In no particular order and in a very simplified view: 

• Understand how work is done from end to end
• Break work down into manageable chunks
• Collaborate - internally between IT teams, with service providers and with the wider organisation
• Understand how you work and identify areas of improvement. Does it add value? If not should we be doing it?
• Keep improving little bits (just enough is good enough)
• Allow others to know and see what you are doing
• If you can and if it's worthwhile, automate it. 
• Always think of the whole thing (system, organisation, flow, etc), not just your silo, and try and make it better for everyone
• Share knowledge and make it available to everyone when and where they need it.
• Allow people to have time to try things and learn.

​ There's nothing in that list that we shouldn't really be doing in our everyday life, is there?

If there is one key point from everything that is going on, it's that last point: Allow people to have time to try things and learn. In DevOps speak, this is part of the Third Way.  Rob England & Dr Cherry Vu also talk about this in their book "The agile Manager"; Em Campbell-Pretty talks about it in her book "Tribal Unity"; Karen Ferris discusses it in her book "Game On! Change is Constant" and I'm sure in countless other places. 

Knowledge Bird recently published the inaugural Knowledge Management Career Survey and one part of the results jumped out at me.

















​This highlights what we are all trying to do, or should be.  Ways of working are telling us to create environments where people and teams can experiment, try things and learn from it.  We are saying that people need to have time to learn, while at work. This goes beyond only learning something new when sent on a 3 day training course, or having to learn at home.

​This survey points out that among many other things, one of the key things people want to create improved knowledge for, is to "extend capabilities within their role". The teams are telling us all that they want to learn more. The approaches to new ways of working are telling us that we need to create cultures where people can experiment and learn. 

What are you doing to make this happen in your workplace? 

​

Over the last 12 months, I have been lucky enough to be able to deliver business simulations to organisations who are either going through change, or who are looking at different ways of working.

These simulations have been created by GamingWorks and go by the names of The Phoenix Project and MarsLander.

The Phoenix Project simulation focusses on helping teams to explore and learn about DevOps and Agile ways of working.  MarsLander helps Service Management teams explore how a more agile approach can help them deliver faster, with more value and use the ITIL4 approach in their everyday working. However, with the latest update to ITIL taking onboard the learnings of DevOps, Agile and Lean and applying them to ITSM, these two simulations help attendees explore, experiment and learn these similar concepts but in different ways.

The teams who have taken part in The Phoenix Project have come away from the day, and it is a full-on day, telling me and their colleagues that they understand the need to collaborate better, that the “business” representatives (as opposed to the IT team members) “get” what they need to do to work better with IT, that “business” and IT people understand why they need to communicate better, that they all understand the benefits of limiting their work in progress.

The teams who have participated in MarsLander, tell me and their colleagues that they understand the need to collaborate better, they understand why they need to communicate better within teams and with their customers (internal or external) and suppliers / partners, that they all understand the benefits of visualising their work and limiting their work in progress.

Senior participants - CIOs and IT Managers - tell me that they want to promote greater visualisation or work and encourage greater preparation, not just planning, within their teams.

Those at the pointy-end of delivering IT services tell me that they want to get their management teams on the simulations so that they understand the need for improved ways of working.

Non-IT attendees go away with a greater respect for their IT colleagues and talk to me about running the simulations within their teams - non-IT teams.

All team members also come away from the simulations as closer teams. Some were brand new teams only meeting for the first time on the day, but after an hour or two, you wouldn’t have known that.

So if you are looking to improve collaboration between or within teams, looking to explore different ways of working, or to understand how the DevOps principles or ITIL4 approach can help your teams deliver better services, get in touch. I may have just the simulation for you.

​