Become a Champion Thought Leader!

Earlier this month I had the great honour to be awarded the itSMF Australia ITSM Champion of the Year and the Thought Leader of the Year Awards (the latter together with my indomitable colleague @mmg9898).  Now, as thrilled as I am with this recognition and as much as I think it is a reward for my activities and commitment, it also got me thinking how we need more champions and thought leaders, in all organisations, at all levels!

Champions

I need to clarify that the word ‘champion’ in this context is not about being a winner (although on the Industry Awards night I certainly felt like one), but rather about being an advocate (i.e. ‘to speak or write in favor of; support or urge by argument; recommend publicly’- source: dictionary.com)!

In order to be a champion\advocate, firstly there needs to be an audience otherwise you are just ‘shouting in the desert’.  But, a champion provides a reminder to that audience about what (in this case) service management is, its correct application, new developments and other noteworthy aspects.

During the conference it was frequently mentioned that organisations need a kind of ‘Service Management coach’ (similar to an Agile coach etc.) to guide an organisation in its use of the many different service management practices available these days (as well as the staff applying them).

But … it goes further.  A champion is not necessarily a person with expert knowledge and capabilities or seniority, but can be ‘merely’ that one person in a team who is motivated about the practices in use, and advocates, encourages, guides, supports and influences the team members around them (regardless of hierarchic position).

We need those champions: from a global expert perspective, but also as an organisational coach or an operational enthusiast … BE A CHAMPION!

Thought Leaders

Apart from Champions, we also need more Thought Leaders.  I think sometimes people expect our ‘thought leaders’ to be exceptionally brilliant people who amaze the world\industry with creative and original ideas …

Far be it for me to say that this isn’t true for some luminary colleagues, however, I reckon that most thought leaders do not necessarily have all their original thoughts themselves.  Instead they observe their environment, the community they operate in and collect individual challenges, opportunities, thoughts and solutions.  They engage and interact with the community to gather and this information and proliferate, expand, share it in a novel & structured way that is recognised as ‘leading the way’.

It reminds me of the ‘Dancing Guy’ video from Derek Shivers, whereby the ‘lone nut’ is the person with the original idea but indeed is only a lone nut, until the ‘first followers’ validate the idea and start the movement.  Thought Leaders are these first followers who recognise and validate the potential of new ideas.

And with this comes the concept that ‘Continual Service Improvement’ is at the heart of any (service management) operating model and culture.  We need to question the status quo, we need to judiciously apply new practices and methods and constantly measure the value of our outcomes. 

Thus, if thought leaders do not need to be exceptional thinkers, and we all need to be thinking about bigger and better ways of operating … BE A THOUGHT LEADER!

Why do we need Champion Thought Leaders?

Now, all of the above has been true for some time, but I think that in this current day and age it is even more important to have Champion Thought Leaders.  First and foremost, as Service Management is a community that is fed by individuals contributing to the collective wisdom (as well as organisations, commercial or otherwise).  The more people that contribute, the larger the collective wisdom available to the community is.

I can see three current developments that increase the need for Champion Thought Leaders today:

1. Relevance

Unfortunately, a reality is that the field of traditional service management is losing its relevance.  Not so much in real terms (as in contributing to business outcomes and value) but in terms of the attention it gets (from the business, management but also prospective staff).  It is just not ‘sexy’, and definitely not when compared to agile practices or artificially intelligent technology!

I think this is partially because we view service management as operations only (i.e.  day-to-day, business-as-usual), rather than seeing the full scope of it, of the complete service lifecycle including strategy, design and transition.

And, regardless of whether this is true or not (and: it’s not!), service management is here, it’s not going away and all those agile projects, all those smart, connected technologies still need to be part of a service that delivers value to the consumer and need to be operated (and improved, and … well: managed).

Thus, we need Champion Thought Leaders to not only keep service management in the forefront of people’s thinking, but also to look for improvements & new practices (and that way linking service management to the more sexy agile, lean and innovation\transformation activities organisations are paying attention to).

2. Complexity

The days of the de-facto standard in service management are gone (the one ring to rule us all, to repeat another theme discussed during the itSMF conference) and instead we are bombarded with a myriad of practices, each promising to do things better or rather to focus on a particular area of service management (where pain is felt, improvements can be achieved or transitions made).

So, we need global experts to create and introduce these new practices, and then organisational ‘coaches’ to find the best ways to introduce and apply them, but it all starts with ‘local’, operational Champion Thought Leaders who see existing practices that need improving and are willing to expand their scope beyond the known\available\common theory.

3. Relevance (again)

Yes, I know that service management relevance (or rather the lack thereof) was my initial development necessitating Champion Thought Leaders but this one is more or less the opposite of that first one, as there is an increasing relevance of service management in the enterprise, i.e. outside of the IT department.

Enterprise Service Management is needed for those organisations tackling digital transformations (and let’s be honest: which organisation isn’t … or doesn’t want to?) as now we no longer have IT-services, but rather technology-enabled business services.  The end-to-end service covers the technology, but also the other enterprise aspects and thus service management capabilities need to be extended into the enterprise as well.

Now, back at the same conference where we were awarded the ITSM Champion and Thought Leader awards, we delivered a presentation on VeriSM™, as one of the new ITSM kids in town, especially focused on service management in a digital age and in an enterprise setting. 

Afterwards we got the question of who would talk to the business about this (i.e.  enterprise service management practices), and the answer is: ‘well … you of course!’

Become a Champion Thought Leader!

Service management is on the praecipe of a renaissance.  Emerging technologies (cloud, IoT, AI …) make IT service management less relevant, but technology enabled business services much more so.  Digital transformation is on everyone’s lips, including of the organisational decision makers (i.e. outside of, as well as over-and-above the IT department).

And because we’re entering unchartered territory, it is not the usual channels that will bring the message.  Not the globally recognised service management guru’s (or skeptics), not the spruikers of new practices and methodologies, not even the consulting organisations and researchers, like Forrester, Gartner and the like, that are usually keen to provide an insight of ‘where it’s at’.  Rather the message needs to come from ‘within’, from those that understand the business and preferably have some real life experience in this (warts and all, good and bad, lessons learned, pitfalls and all that). 

This is where you come in.  Service management is one of the things that we have actually done quite well within the IT environment, and it is our duty -and I mean: all of our duties … including you as the reader here- to share this with the business, advocate service management practices and lead the corporate thoughts on practices and structures … BE A CHAMPION THOUGHT LEADER !

Viva la (service management) revolution

One of my favourite expressions within service management training is the concept of ‘evolution, not revolution’.  I use this concept to explain that, for instance ITIL, is not an ‘all or nothing’ proposition that should be dismissed if it can’t be achieved ‘just so’.  My explanation is that most Foundation training courses describe a perfect world situation.  However, whilst your environment may never be perfect, that doesn’t mean you can’t use the concepts to IMPROVE your current practices.  Hence ...  evolution.

The other reason is that no best practice guidance will tell you that everything must be done ‘exactly so’! If your current practices are working, or even if they are merely ‘sufficient’, there is no reason to ‘wipe the slate clean’, ‘throw out the baby with the bathwater’, completely get rid of them and implement the best practice ones instead.  After all, a much-loved saying recalls that ‘if it ain’t broke, don’t fix it’ and a common consulting approach is to start with the area where there is the biggest pain (and thus the biggest potential gain, and where it is easier to obtain commitment to change etc.).  Again … evolution.

Evolution is the gentle cycle of Continual Service Improvement (CSI) where bit by bit, step by step, we improve towards the perfection of the ‘theoretic’ practice.  So, by applying an evolutionary CSI approach, not only do we start where there is likely to be more commitment and where there is more benefit to realise (and thus generating Deming’s or Kotter’s cycle of successful change), but we are already embedding the concept of CSI into the new practices.  Pretty cool move!

But … sometimes existing practices are so ‘rutted’ in, that gentle improvement is like trying to rock a cart out of these ruts (in order to change direction).  A small improvement or motion may be observed, but relatively quickly the cart will resettle into the old ruts and continue its previous (and probably doomed) course.  In this case, the only option is revolution: thrust the cart out of the ruts, topple it, disrupt it … and then reset it on whatever new course is required.

Not an easy choice, and certainly not a popular one … but sometimes necessary.  I had a professional acquaintance whose job was just that: pushing the organisational cart out of the established practice ruts.  He would be invited into an organisation seeking to make substantial change.  As such he would basically come in, change everything and make himself hugely unpopular.  After a few weeks or months, he would leave (or was ‘made to’) and whomever followed him in the role, not only was ‘free’ of all the old practices (which had been changed and dismantled), but also was instantly welcomed after the horrendous experience the staff had just been through.  The ‘shake up’ had paved the way for the new manager to establish new, best practices with a higher acceptance and create calm where there had been chaos.

I think that, on some occasions, in service management, we have reached this position of being ‘in a rut’, ‘down a hole’ or ‘at a dead end’.  Many of us have been working with service management practices for a long time, but in some cases, have not progressed much past the operational, reactive processes.  Even then, how have we truly matured these processes to a point of excellence?  Who dares to stand up and sing the praises of their perfect change or problem management processes?

For some reason, it appears to be difficult to ‘elevate’ our service management practices to the proactive service design processes, let alone into the strategic arena.  In my opinion a critical factor in that is the lack of getting the business involved in these processes.  And that is not just about getting input from the business, or the business taking an overseeing and authorising role (although there are many challenges with those aspects of governance that make these common obstacles), but I’m talking about a customer that truly participates in the planning & defining activities of those processes (or services … or products).

I’ll come back to that (customer participation) later, but I think that after a more than a decade of evolution we can conclude that that is not going to get us much further with the tactical\design elements of our service management model.  We are ‘rutted’ or, to switch analogies, we’re stuck on a track that is going nowhere. 

A new approach is needed … a revolution!

And, the timing is right as, in my opinion, at this point, two developments are converging to create the opportunity to consider a revolution.

The first is the emergence of new best or enabling practices.  These new practices advocate a new approach that is arguably more aligned with the modern technical and business environments, and thus provide more suitable solutions for our current challenges.  Agile, SIAM^© and VeriSM™, to name but a few, are offering practical guidance, structure and progressive practices.  Note that these practices often align with existing, more traditional ones (like ITIL^©, for instance) and that thus -at least on the surface- perhaps a revolution would not be required (but instead we can utilise these new practices through the customary evolutionary approach, ‘splicing’ them into the old, established processes).

But, the second development currently emerging is that of enterprise service management, or business service integration.  Again, this is not something that is revolutionary on its own, and some of us have been preaching service management in the enterprise for a long time, but the business is, perhaps only now, realising that IT truly is an important business enabler, and therefore needs to be integrated within the business processes, business services and business management. 

That’s right, the keyword here is ‘integration’ and not ‘alignment’!  IT alignment is nice, but it still presents IT as separate to the business, whereas what we’re after is true integration.  Add a term like ‘digital disruption’ (or the more palatable ‘digital transformation’) and we may find a business that is receptive to adopting service management practices to improve their business model.  But these businesses may not be keen to follow established IT practices, like ITIL for example (especially if their success is contentious), but rather look to emerging practices that have the business at the forefront.

So, whilst there is still the potential to simply evolve and embrace either newer service management practices or enterprise service integration, by slowly improving and expanding your existing practices, I believe the stars have aligned to allow for consideration of a more radical approach and hit these two birds with one stone …

A revolution, which can more quickly establish new practices with the business, rather than ‘allowing’ the business to utilise and become ‘part of’ well-known IT practices.  This might be the time to design a new service operating model, from the ground up: purpose-built, with business input and participation, based on existing practices that we know that work (remember the baby and the bathwater?) but augmented with new, progressive practices to utilise their strengths (especially where those old practices failed, or at least were insufficient).

I believe that VeriSM offers a great start to approach the development of such a revolutionary service management operating model.  VeriSM outlines the need to create a model that considers Governance, Service Management Principles and the wonderful new concept of a Management Mesh.  This mesh combines the various practices, technologies, resources and the environment (market, culture, …) available to an organisation and through which it can develop and provide products and services.

This openness and flexibility is a theme that is mirrored in other progressive practices.  For instance, SIAM describes a structure which allows an integrated approach to managing multiple providers to deliver end-to-end service, focussing on collaboration and culture. It does so without prescribing the specific ‘how’ to the parties involved.  For this ‘how’ we look towards best-of-breed practices like Agile, ITIL (and half-a-dozen or more others), which can be selected based on suitability to a specific project, customer or environment and applied.  The point is that all these practices offer useful elements and indeed can and should be utilised where they will deliver benefit.  One size doesn’t fit all and it’s a case of picking and choosing elements based on a particular project, service, customer, culture or geography.

So, why not start a revolution? I believe, now is the time to ‘throw of the shackles’ of the past and seek to achieve those goals that perhaps used to seem out of reach, but which are also those that are critical for future growth of an organisation! When doing so, perhaps the following might be helpful:

• Be brave – Evolution is always a safe option, whereas revolution gives you that feeling of ‘burning your bridges’.  But ‘no pain, no gain’ and in order to make that next, quantum-leap forward you cannot keep doing what you’ve always done (see Albert Einstein’s definition of insanity -or maybe it was Rita Mae Brown-).

• Start with the business – The business is your friend and partner in this.  It’s them that need the IT integration (whether they realise it or not, remember ‘digital transformation’?) and it’s them that will push the need to do things differently (and thus will support revolution over evolution).  Start a conversation with them on IT integration, on digital (business) services, on enterprise support (automated, self-help, …) and on agile project management and product innovation practices … all things this revolution can bring about for them and which would drive true business benefit.

• Start from the top – A ‘golden oldie’, but therefore not less true.  With a revolution it is important to establish the required outcome first, before planning your attack.  Make sure the governance, service management principles and Management Mesh are in place, before worrying about the details such as which practice, which technology etc.  If you get too gung-ho and start selecting practices, rewriting processes or -worse- implementing new tools you may score a short-term victory, but may lose the overall war due to lacking direction or no ownership (see previous point) and thus no long-term commitment.

• Mix-‘n-Match – No one practice will do everything, for everyone, every time.  Surprisingly, although different practices have different strengths (and weaknesses), they are remarkably similar in principle and thus can be combined.  After all common sense is (supposed to be) common, no matter who writes it down or which perspective you take.  The revolution will allow you to pick new & best of breed practices and mesh them into your model for maximum flexibility and benefit.

Good luck!

the ITIL Zealot

February 2018

SIAM blogs

With the release of the SIAM Foundation & Professional Body-of-Knowledge, I've created a number of SIAM related blogs, shared with Scopism (where you can also download the BoKs). 

You can find the blogs here:
Supplier Management Categorization: www.scopism.com/supplier-categorization-siam.

Supplier Management: www.scopism.com/siam-supplier-management.

Framework Integration: www.scopism.com/framework-integration-and-management. 

And as an extra-special present you can find my name & photo too!

Merry Christmas & a Happy New Year

the ITIL Zealot

December 2016 / February 2017 / January 2018

THE NEW STEADY STATE IS CONSTANT FLUX

A few weeks ago I read Mark Smalley’s‘Kill DevOps’ on the back of a year of increasing interest in Devops, in particularly when compared to the slow-and-steady ITIL.

Mark finished his article with ‘The only desirable steady state is a constantly evolving state of mind.’ And thus rejecting basically any system or methodology, including DevOps which embraces change like no other.

And that got me thinking: do we need stability (for which we often strive)?

Human nature often makes us conservative (maybe along the lines of ‘better the devil you know?’).

A majority of people prefer the status quo, the familiarity of the existing practices, the security of knowing how to do something.

From an organisational point-of-view stability is also preferred. Very few business models welcome surprise and change and are normally based around a status quo (which can be expanded, enhanced or sometimes just maintained).

Even CSI, which is in essence continual change, is based on improving SOMETHING that is more-or-less stable, that can be benchmarked and baselined; and from there to improve efficiency & effectiveness of the status quo.

In fact many of the best practice concepts around Service Operations, are based around BAU (or Business As Usual). By thorough design and testing we avoid any surprises in operations, thus enabling us to deliver a dependable, repeatable (, measurable), guaranteed service … day-in-day out … the same every time.

Based on the renowned Ivor McFarlane I often explain the Operations is supposed to be a boring place to work and that as an Ops Manager, if your staff gets excited … you should get worried!

Or I use a fast food chain as an example of a process based organisation, where everyone (almost regardless of past experience) can create the same quality food (using the term lightly), anywhere on this planet!

But those later ones are certainly not attractive examples of stability: boredom and fast food do not rank particular high on most people’s wishlist.

And thus despite our preferences, we are looking for change, for excitement, for new experiences, new horizons … a bucket list to work through before the eternal stability of death reaches us.

DevOps advocates rapid change and Disruptive Technology hardly preaches a dull and secure application.

So, which one is it: the security of stability or the excitement of change.

As per usual the answer lies in the middle, a bit like bi-modal IT, merging DevOps and ITIL, having your cake and eating too, having the best of both worlds.

I think chaos is change without a solid foundation, thus neither improving nor deteriorating the situation (which BTW makes chaos a constantly changing status quo … ooh, that’s deep).

Stagnation on the other hand is stability for the sake of stability causing dogmatic, micro managed often overly-bureaucratic organisations.

I can accept that change is inevitable and that potentially change is a good thing (as good as a holiday I’m often told!). But not all change and not change for change’s sake.

I see benefit in distinguishing improvement (the same but better) and innovation (different) and both will need a place in a mature Service Management organisation.

It is true that ITIL does not really deal with innovation (a bit in CSI, a bit under ‘new technology’ in Capacity Management), but neither does DevOps (or COBIT or pretty much any best practice that I know of). And where DevOps supposedly signifies the death of ITIL, Mark poses that ultimately DevOps needs to die as well to keep changing/improving/innovating/evolving.

Ultimately everything must or will change, including ITIL and DevOps, but I don’t think we need to actively euthanise either of them (just yet).

Rather (and as always) we need to apply the common sense guidance of either methodology (, framework, or whatever you want to call them) where and how it applies best; and make sure you have the right objective in mind (, business goals, value, again many terms that can be applied here). If there are ‘blindspots’ (like innovation) than make sure you augment your organisation with the necessary structures to fill these in.

For innovation specifically ‘Google time’ comes to mind (20% of time spend on ‘personal’ projects, which got abandoned in 2013), or something I picked up as 7x7x7: 7 ideas are given $7,000 to work on for 7 weeks. This keeps the wildly creative and anarchical innovation within defined time (7 weeks) and budget (7x7=$49,000) constraints and cycles.

So, let’s embrace change but makes sure we have a clear understanding of the direction of this change. After all ‘let’s go left’ only makes sense if you know where you are and where your destination is!

And let’s not blame our ‘system’ or methodology for the lack of innovation but instead make sure innovation is covered within the system (and yes, that includes innovation OF the system).

Onwards and upwards!

(to boldly go …)

the ITIL Zealot

May 2016

Making deliberate mistakes!

For a few days now I have been pondering what to write about for this new\my next blog. In this ever-changing world there is actually remarkably little happening in the service management space. I guess we’re all waiting to see what AXELOS will bring to the party next year (or perhaps we're secretly plotting a defection to COBIT).

Mostly people are providing (excellent) examples of how to actually apply the service management concepts, or they are bashing the (perceived) rigidness of ITIL, especially compared to AGILE or DEV-OPS. And in particular on that last topic, I have felt the need to ‘come to the rescue’ of ITIL to explain how its generic concepts apply, even in the modern, fast-paced world of DEV-OPS.

At the core of ‘my’ argument is that ITIL is a best practice, and my favorite definition of that is: “common sense... written down”. Now admittedly common sense isn't always common (and in ITIL's case doesn't always immediately make sense either) and it definitely isn't written down.

The thought behind this is that we need to move from ‘best-effort’ to ‘best-practice’. Best-efforts are individuals doing their individual best. In itself nothing wrong with it, but individuals are just that, and best-effort often means that different people are dealing with the same issues in a different way. The end result of that is a differing experience (for the customer) and something that is not repeatable, consistent or guaranteed.

Those last two words (repeatable & guaranteed) are key in delivering a service. Customers want to be able to rely on the value provided, which is why we negotiate SLAs etc. and try to provide measurable targets. After all: You cannot manage, what you cannot measure.

But in extension: You cannot measure what you cannot define!

And this is one of ITIL's greatest strength, it defines processes and concepts (like Incidents, Problems, Events, Changes, CIs, SLAs, …) within the IT service provider, allowing them to become measurable and manageable.

So, defining something allows you to make it (more) manageable, and then writing it down allows you to share it with others, making it repeatable & consistent.

I think most people understand the benefit of ITIL here: the one language, the structure and definition of the processes are all very helpful in building a more effective and efficient service organisation.

However, the writing down bit is where things often go wrong with ITIL. It manifests itself as procedures, flow-charts, RACI-matrices, forms and that often becomes bureaucracy.

Now, I've lamented before that we need a level of documentation (a pilot landing a plane without a checklist is .. scary) and that ITIL actually doesn't specify how big procedures need to be (80 pages, 8 pages, 8 paragraphs or 8 words). In this context I've referred to size, risk and complexity are factors that determine the amount of documentation that is applicable.

I guess we all agree that ITIL needs to be adopted, based on your organisation and objectives. As much as we look for a prescriptive silver bullet, this was never what ITIL was intended to be. It has always been positioned as guidance to help you.

In determining HOW to adopt ITIL, it is important not just to understand WHAT ITIL is defining as best practice, but -more importantly- WHY ITIL thinks this should be done.

And I believe that a lot of the detractors of ITIL are focusing on the WHAT (and sometimes on very specific phrases in the publications) and not on the WHY.

So, take DEV-OPS. Change Management is all about (the WHY) delivering new\better value to the business and minimising impact (of not changing or badly changing). DEV-OPS (or AGILE), in my opinion, is not different to that, it is just focusing on rapidly changing. Traditional ITIL may perhaps focus on preventing all (or at least most) errors (through assessment, CABs, testing, ELS, …) but that is just an interpretation.

There is nothing wrong with making a ‘fast change’ (emergency change would be the defined concept) is that provides a better value to the business.

And now we’re getting closer to the title and thus the message of this blog. I believe that almost everything we do in life is based on a risk-reward judgement: is it worth the risk (of failure) to obtain the reward?

Often we try to make this measurable, and then again often in financial terms (ROI, TCO). But in essence this can be a very subjective, individual judgement.

And we don’t like individual actions\decisions in the service management world, or at least we’re trying to make sure that different people make the same decisions, and preferably the right one (although who is to judge which decision was right in the end).

To me, this is a key principle behind ITIL: it is not a silver bullet, a straight-jacket of procedures to be followed, a regimented framework which will avoid errors at all costs (through design, transition and operation). But it is a framework that allows an organisation to collect better information (measurements) which will lead individuals to make better (, more consistent, repeatable) decisions through which to deliver more value to the customer.

Now, no-one is perfect, and I don’t think ITIL (processes or rather their documentation) should be something that an individual should hide behind, afraid to make a decision.

After all a process never covers all eventualities and if people follow process-for-process-sake it’s the equivalent of announcing that the operations is a success, but the patient died (but look at the stitching … beautiful, consistent, text-book)!

With service management, we also need to create a culture of people understanding the WHY and giving them the ability, confidence and security to make decisions.

Even if those decisions are wrong. I often say that I don’t mind people making mistakes, as long as they were deliberate mistakes!

Deliberate mistakes you can learn from, and the next time you will change your frame of reference, and make a better decision. ‘Random’ mistakes however have no inherent learning built in, and there is no guarantee the results will be better (or worse) next time.

Most of this is based on an anecdote of IBM CEO Tom Watson. There are various versions of this, differentiating in time, people\departments involved and the amount at risk, but this version explains the message quite well.

Trust your people, and use ITIL as a tool (, framework, guidance) for them to structure their work better, and to provide them with better information, to make better decisions and deliver better value.

the ITIL Zealot
September 2013