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

Quality over Quantity?

I returned from holidays last week and boldly started 2014 with a ‘polarising’ tweet:

OK, I'm back from holidays and have stepped into 2014.What's new? Has @AXELOS_GBP messed up #ITIL yet? #ITSM

Admittedly quite a blunt tweet, but I was hoping for some responses and got exactly what I bargained for with specifically two interesting ‘discussions’ following (using the term lightly as it was all in 140 character twitter statements, thus lacking some ‘finesse’).

One was rather obviously about AXELOS’ performance to date. More on that later, but first the other discussions which diverted into whether (ITIL) training should be of the best quality or the most accessible. John Custy (@ITSMNinja) mentioned that if ITIL exams were more expenses (based on AXELOS’ price increase) ‘maybe fewer, but more right people certified...’

This got me thinking, as I have always been a great advocate of training quality and a skeptic of the current ITIL certification scheme (see my blog from March 2013 on Action Based Learning).

However at the same time I can see the importance of training be accessible to a large audience, particular at the basic/entry/foundation level. Hence the title of this blog: Quality over Quantity/Accessibility.

The current ITIL Foundation course (or rather ‘Foundation Certificate in IT Service Management’) has become a volume-seller with around 20,000 exam each month. Plenty of organisation are sending all their IT staff to this course and the prevalence of the ITIL Foundation certificate has certainly helped to make ITIL the ‘de facto’ standard in IT Service Management.

Compare this for instance with COBIT. COBIT is seen as an equivalent if not better alternative to ITIL (with more prescriptive guidance, standard RACIs, a direct link to governance, risk, project management …). However, whilst there are COBIT qualifications available, it comprises mainly of Foundation, with then ‘specialised’ implementation or assessor courses which are not focused on general staff. And it is much harder to obtain with fewer organisation (in fewer locations) offering this course less frequently (although there is always the on-line option).

And it is a similar story with MOF (Foundation only), TOGAF (Foundation or Certified qualifications), LEAN or AGILE. Whilst there certainly is certification in those methodologies, it is far less known, far harder to obtain (not because of difficulty but because of availability) and far less recognised.

As mentioned, I believe this is part of the success of ITIL and in order to maintain this it is important that AXELOS not only maintains the quality of the ITIL certifications, but maintains or even improves the availability/accessibility/quantity. Most certainly at entry/Foundation level but also for Intermediates, which have a far smaller uptake. The more people are trained and certified in ITIL, the more people will want to use it (and the more people use it, the more we can work towards quality improvement of the theory).

That doesn’t mean that quality is not important. And whilst I hope that future updates to ITIL will improve the quality of the theory, and with it the quality of the certification (for instance a lower, operation-only Foundation, more practical and less factoid based, periodic exam refreshers to maintain higher levels, …). We need to look at the situation at hand: The Foundation is course is so prevalent that a lucrative and significant grey circuit has developed offering courses that do not (always) meet the existing quality standards. This (in my opinion) is a real threat to both AXELOS, the ATOs and the market.

For instance I believe we can all agree that the existing ITIL Foundation syllabus only just fits in a three day format. There is a lot (too much!) theory to explain and the danger is of the course becoming death-by-powerpoint, theory-overload with not enough time to discuss practical application of the principles. So, I was not overly impressed when I was approached by a (non-accredited) training organisation with the question whether I could deliver the Foundations in two (albeit extended) days … over a weekend … including the exam. I declined and sincerely question the quality and outcomes of a course like that.

Because as important as certification is, there is more to training than that. However we need to look beyond the IP-owner and training organisations and realise that it is the responsibility of the organisation/manager who sends staff to training to obtain ‘value’ from it (as well as the staff attending training). I advocate an immediate follow-up on training: at Foundation level an attendee could do a review of existing procedures, tools and documentation (and discuss any questions or suggestions with the process manager/owner). At Intermediate level this can become a more formal assessment and CSI/SIP and at Expert level the scope increases (all lifecycles) and would include tactical or even strategic customer relationships.

Anyway, bringing this rant to a close: the quality of training is paramount and any customer/participant of training is responsible for choosing the best training and getting the most out of it. The better training organisations (and fortunately there are plenty of them) will maintain quality and inject this into their offering.

The role of the ‘examiner’, in our case AXELOS, is to design a qualification scheme that is acceptable by the market, but also to maintain a delivery model that will make it available to that market.

Whilst this includes maintaining quality (EIs, ATOs, …) there is more to it. And a first action of increases the price of exams (and thus their revenue) does not necessarily give out the right signal. But that is a different discussion (on AXELOS’ performance, which I promised Andrea Kis (@AndieKis) to have in 170 days).

Best wishes for 2014!

the ITIL Zealot

January 2014

The Ghosts of a Service Management Christmas

Unbelievable, it’s December already ... again.

I guess it is only fitting around this time to conclude this year of blogs with a seasonal topic. In this case the ghosts of a Service Management Christmas.

The Ghost of Christmas past: Service Management

Let’s take a moment to reflect on and celebrate the achievement of Service Management!

Being a zealot, I come from a time when service management was literally unheard of, and we were pretty much preaching the good news. Since then there wouldn't many (IT) companies left today who aren't at the very least aware of the service management principles. And whilst it may not be perfect (far from), there is a certain acceptance.

ITIL is past the hype-curve. Although this poses new challenges (in the ‘through of disillusionment’), at least we've left the inflated expectations and start seeing for what it is: a descriptive guidance (not a goal in itself!).

And let's not forget (despite my earlier mentioned ‘zealot’ status) that there are more flavours in the service management universe: COBIT has matured to be a complete framework, AGILE and LEAN are in demand and ‘golden oldies’ like PRINCE2 retain their value. No one framework is king, they all excel in their own areas and we now realise that ‘mix-n-match’ is the name of the game.

The Ghost of Christmas present: AXELOS

For those of you that are still unaware of this: Capita has purchased 51% of the ‘best-practice’ portfolio of the British government, and together they have created a joint venture called Axelos as the IP-holder, accreditor etc. This has brought a lot of uncertainty to those currently ‘involved’ in the ITIL world (or PRINCE2, or MoR, or…): Exam Institutes, Accredited Training Organisations, consultants and the like.

So far Axelos has been saying all the right things (listening to the market, minimal/no immediate change, invest in product development, including alternative training products -read gamification-). But their actions have been less ‘insightful’: a £10 Foundation Exam app and a £1,000 ITIL maturityassessment all indicate a more expensive future.

Of immediate concern is now the training accreditation and examination. Exam royalties are rumoured to triple, but to-date no official pricing has been announced. With APMG relinquishing their role as the accreditor on 1 January (and becoming ‘just’ an EI) there are still a lot of unknowns: no copyright clarity, reaccreditation requirements (or timeframe) …

Whilst the market may hardly notice this, I think it has put most things ‘on hold’ of the past year, hopefully to restart again when the takeover has been completed. 

Which brings me to

The Ghost of Christmas future: ITIL 2015

This may be a case of wishful thinking: but with 6 months development, starting in the middle of next year, followed by a 6 months review and fine-tuning period; we could have a new ITIL in the middle of 2015 (giving me 6-months leeway ‘til the end of that year and the need for a different name).

And what an opportunity for Axelos to get it right and position itself in the market as THE premier service management framework provider. A few things that I’d like to see:

·         Real language (no bull): focus on the concepts\outcomes of ITIL, not the theoretic definitions. After all, ITIL is descriptive.

·         Consistency: link all books, all processes and loose the ambiguity where possible. For instance is CSI a process or not?

·         Integration: clarify the co-existence of ITIL with various other frameworks (overlaps, strengths …)

·         Focus & expand: ITIL has built a name in Operational processes (loosely including the Transition ones), so whilst Service Strategy is certainly important, it is unlikely organisation will adopt this ‘as-is’. Instead focus on the strengths of the operational process and expand the offering with more templates, (implementation) cases and support. People are always looking for a silver bullet and whilst ITIL will never be that, it can provide more guidance than its current 5 publications.

I get all warm feelings thinking about this, sign with me

Jingle bells – service management hell – ITIL’s on its way

Oh what fun – it is to write – a process manual

Wishing you all the best for the upcoming holidays and 2014!

the ITIL Zealot

December 2013

ITIL vs Dev-Ops (itSMF debate)

This month I participated in our local itSMF branch seminar. As it was the last quarter of the year, we were already a bit in the Christmas mood and as it is called the silly season we tried to make the content light and entertaining. To this regard there were 4 IGNITE session. This is where each speaker has a limited number of slides (in our case 20), which auto-forward (in our case after 30 seconds) so that the presenter has not control over the presentation behind him/her. And by asking the speaker to present not only in this format, but also in a more polarising way, we kept it quite entertaining.

But in addition we also introduced two DEBATEs. I’ve used this format in my training whereby the candidates are either in favour or against a statement (like ‘outsourcing will make all our problems go away’ or ‘you should always charge for a service’). This makes them think about all the arguments in favour, but also the weak spots of these statement and phrase there position and rebuttal accordingly.

For the itSMF seminar each team (for or against) presented an IGNITE (although the more traditional 15 slides and a 20 second auto-forward), and then a rebuttal. The debate topics were:

•    Chicken or Egg, what comes first: process or tool
•    Traditional Service Management vs. Dev-Ops.

I was on the latter debate, obviously defending traditional service management. My role was to present our case through the IGNITE, and I’ll provide a brief synopsis of that. To this effect I’ve shared my slidedeck HERE.

I first [slide 2] narrowed the debate down to ITIL vs. Agile and decided that a battle of this magnitude could only be properly debated, explained, reflected by using that other epic battle of good vs. evil: Star Wars!

No doubt that ITIL takes the role of the Jedi here [3]. The ancient, ruling order, steeped in mystic, historical processes but in essence a democratic society for the common good.

Agile on the other hand has more similarities with the Sith [4]: powerful, challenging the ruling order, using emotional, rash decisions (over rational, risk averse ones) and attractive to young padawans/developers.

A good example was the Deathstar [5], a somewhat rushed project that contained a fatal flaw, causing it to blow up with considerable damage to the customer (the republic).

So, what did they do: they build another Deathstar, with the same flaw and put it into production before it was even completed. No surprise then, it blew up again, with even more devastating customer impact (victory to the rebellion).

In my opinion, a lot of this has to do with perception [7, yes I skipped 6 which only served to further focus on an apparent lack of planning with Agile]. You see, Dev-Ops or Agile is currently at the height of the Gartner Hype-curve. In the minds of some people it can do no wrong, and should be used for everything and anything.

ITIL on the other hand is done the bottom of the curve, in the ‘through of disillusionment’. Many organisation have tried and perhaps not achieved the results they were hoping for. Now they are throwing out the baby with the bathwater, completely rejecting any of the common sense best practice IT Service Management approach that ITIL describes.

To a large degree I think this is because of the perceived bureaucracy that ITIL introduces [8]: processes, procedures, templates, workflows, … everything needs to be documented, reviewed & approved.

Perhaps so, but ITIL never actually identifies how complex, wordy, lengthy or formal these procedures need to be. Or even whether they should be written down at all.

More important is to understand WHY something needs to be done (rather than how) [9]. PRINCE2 (from the same best practice stable as ITIL) actually identifies tailoring as a must for every methodology and that tailoring is not about whether to use it or not but about how (formal) to use it. This is driven by factors of size, risk & complexity.

Change Management is a prime example [10]. This often becomes a bureaucratic bottleneck, because people focus too much on the formalities, paperwork, CAB meetings etc.

The ITSkeptic told at the Australian itSMF LeadIT conference, how one dev-ops engineer exclaimed that he could but a new version in production, ‘before you could get an Emergency CAB together’. That last statement doesn’t leave me with a lot of confidence, in particular if it was a mission-critical service/application we are talking about here.

Instead we should focus on the real goal of Change Management, which is to minimise impact. ‘Horses-for-courses’: sometimes you can go slow and secure, other times you need to go quick, but you better wear a helmet!

And Change Management accommodate the Dev-Ops concept of ‘failing fast’ [11] through defining different categories of change, each with their own level of documentation, assessment, approval and oversight.

1.    The Emergency (or ‘oh-shit’) Change means we don’t throw caution to the wind, but instead apply a different, faster, less rigorous process (basically we decrease time, but increase risk)
2.    The Standard Change allows a cookie-cutter approach to frequent, repeatable change, which will significantly reduce overheads
3.    And the use of ‘minor’ Change categories will allow a less convoluted path to be followed, whilst still maintain the appropriate governance.

The key here is no to be afraid of failure, but also not to close your eyes to the risk [12]. Mistakes are part of everyday life, and in fact mistakes are essential for growth, improvement and innovation. I call this the concept of making ‘deliberate mistakes’ [13].

So in our battle of Dev-Ops vs. Service Management, we find that ITIL actually incorporates everything that Agile is trying to achieve. But then, it does much more, allowing for both fast and slow changes; and with a lifecycle that includes Strategy & Operations (as well as Design, Transition and Improvement) [14]

Thus there can be only one outcome, and the (ITIL) Jedi must win [15].

But perhaps rather than looking at Star Wars as the fight of Luke against the Empire (and his father) of the first (now the last) three episodes, perhaps we should encompass the whole (6 episode) series as the lifetime of Anakin Skywalker (from good to bad, and back to good): In Anakin we find good and bad, jedi and sith, passion and ration, similar to how Dev-Ops and Service Management attempt to achieve the same goal (-better- value of services) through different approaches [16].

As long as the good side wins in the end!

(May the ITSM force be with you)

the ITIL Zealot

November 2013

Building a Service Catalogue

This blog is part of the coordinated service management blogging flashmob, with the idea to have a number of bloggers posting an article on the same agreed theme (at the same date/time). The theme for this first edition is ‘My Best Tip for building the Service Catalog’ (yes, American spelling).

I myself have had a bit of a love-hate relationship with the Service Catalogue.

In the beginning, during the dark ages of service management, or rather the 90s, I was spruiking the Service Catalogue as the best thing since sliced bread and an absolute starting point for anyone inspiring to do service management. After all in those days the concepts of service management, or even of a service, were relatively unknown and it seemed a logical starting point to define what your services actually are.

As, in essence, that is what the Service Catalogue is: a list of services. In its purest, simplest form it doesn't even need a lot of text, just a short description, so the customer knows what they can expect from the service provider. This is why a restaurant menu is so often used as an example/analogy for a Service Catalogue (which is wrong, but more about that later).

But then came ITIL v3 and the Service Catalogue obtained its own process, within the Service Design publication. The definition became: Service Catalogue (Service Design) - A database or structured Document with information about all Live IT Services, including those available for Deployment. The Service Catalogue is the only part of the Service Portfolio published to Customers, and is used to support the sale and delivery of IT Services. The Service Catalogue includes information about deliverables, prices, contact points, ordering and request Processes.

Not enough to really obtain an indication of the importance, or irrelevance, of the catalogue. More interesting is how the book describes the two different aspects (or better perhaps: ‘views’) of the Service Catalogue: the Business Service Catalogue and the Technical Service Catalogue. This is a great clarification of the vague reference in version 2 of a ‘hierarchical’ structure of services with some being ‘invisible’ to the Customer. The two newly defined aspects/views show the difference between the visible, outward facing catalogue (for the Customer) and an internal one which can be used for the development & management of systems and teams.

However, at the same time ITIL started confusing what the objective of the Service Catalogue is, and where/when it should be used. Not helped by (the usual ITIL) ambiguity of definitions and inconsistencies across the publications. The main one that bugs me is the distinct different uses of the Service Catalogue in Design (as part of Service Catalogue and Service Level Management), Operation (in Request Fulfilment) and in Service Strategy.

In 2010 I wrote an article (published in the itSMF-A Winter bulletin) on ‘Is the Service Catalogue really necessary?’ (leave comment if you'd like a copy). It concluded that the Service Catalogue has become a strategic document, in the ITIL Lifecycle, defining the Market and the Offerings as well as a structure for the delivery of those. It straddles the bridge between the Portfolio\Pipeline for the future and the ‘next’ Customer, leading to Service Level negotiations.

PS: This is also the main reason why the menu card is not the Service Catalogue of a restaurant: After all, the meals on the menu are merely the products delivered (comparable to an application). And it is not the product the customer wants, but the value he or she derives from this. For instance a bowl of chips is the same product whether it is obtained in the drive-through of a fast food restaurant -with screaming kids in the backseat-, in a pub during the Sunday-session -with mates and a beer-, or as part of a romantic dinner-for-two in a seaside a-la-carte restaurant; same product but the value is completely different (convenience, atmosphere, privacy, view, ...).

Thus the ‘real’ Service Catalogue of a restaurant is the style, location, opening hours, interior, ambience etc.etc. ... All those things that make someone decide to go to that particular restaurant in the first place, rather than pick a specific dish of the menu

So, now leading to my best Tip for building the Service Catalogue. I think the secret is in the diagram showing the Business & Technical Service Catalogue.

Based on Cabinet Office ITIL® material. Reproduced under licence from the Cabinet Office

The business side is showing a link between (business, customer-facing) services and business processes. These links form the bases for Service Level negotiations & Agreements (SLAs) and thus we need to define the utility that these services provide. And I think that is ‘easiest’ done by defining Patterns of Business Activity (PBAs as they are called in Demand Management). PBAs are often related to core business and revenue and thus define (too a large degree) the success of the business and by extension the value of the service.

If you could quantify these PBAs, they are going to be mighty helpful not only in defining the service for the Service Catalogue, but also negotiating the service levels, determining change impact, incident prioritisation etc.etc.

TIP 1: Define Patters of Business Activity, which will lead to utility and service definition

So, that is one half of the solution, on the other, technical side we see how those same services are linked to bits of technology. I think the picture is skipping a level here, as the technology is managed by ‘someone’ (a team, a provider, ...). These links represent the OLAs and Underpinning Contracts that need to be in place with these people (in order to deliver the SLA, customer-facing services above). 

So instead of technology, identify your functions, your teams and suppliers; and then define the (technical) services that each of those deliver. You'll find that these are probably more warranty-focused.

TIP 2: Identify teams that deliver technical, underpinning, supporting services

That's my tip(s): PBAs, utility & SLAs for the customer-facing services; and functions, technology & OLAs/UCs for the technical ones.

But if all else fails, one more tip: start with your applications!

Not all of them, and not in their technical appearance, name or version (no funny acronyms). But applications are the most visible part of a service for the customer, and they provide the utility to the customer and are thus closely related to the customer-facing service definition. 

This is not a perfect solution or (ITIL) theoretically correct, but you could do worse that to start here.

Good luck!

the ITIL Zealot
October 2013

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

What I learned at itSMF-A LEADit

Last week was the annual itSMF-A LEADit conference. Three days of presentations, keynotes, workshops, hot topics and yes, even some fun. But what did I learn in those days?

Firstly that there is nothing new under the sun: ITIL is still ITIL, no new version or revolutionary changes (perhaps AXELOS will provide those in the coming year). No new version of COBIT or any shocking development around any of the other frameworks (AGILE, LEAN, PRINCE2, ..), standards (ISO20000, …) or regulations (governance, outsourcing, …).

The ‘newest’ thing that I personally saw was a presentation on SFIA. Not that that is new, but I hadn't personally been told about a case study of a company actually using it. Great example of mapping less tangible skills (capabilities in ITIL Service Asset terms) onto people and roles, and then managing the gaps.

What was new though, or rather more prevalent than the previous year, was the tendency to do some ‘ITIL-bashing’. In more than one presentation, including a keynote, ITIL was described as old-fashioned, overly rigorous (read bureaucratic) and no longer fit-for-purpose.

Aale Roos in his keynote spoke about ‘unlearning ITIL’ and highlighted several of the idiosyncrasies of ITIL (including the ‘silly’ ITIL v3 Service Strategy publication). He proceeded to explain how the use of the ever-increasing number of processes in ITIL can lead an organisation to be lethargic. He used Nokia as an example and how it failed to quickly respond to the iPhone and smartphone market.

I think Rob England had the right idea by illustrating how ITIL is now at the bottom of the hype-curve (the 'trough of disillusionment'). He lamented that rather than being skeptical of, he found himself in recent times more often defending ITIL.

He continued the picture by showing how dev-ops is currently at the peak of the hype-curve (the 'peak of inflated expectations'). In fact various presentations during the conference highlighted both the need for rapid change, as well as the methodologies that supported this (dev-ops, AGILE .. note NOT ITIL). Case studies for Amazon and Netflix showed their large number of changes and their ability to not only absorb this, but also deal with unfragile systems (not robust, but not fragile either).

This was epitomised by the remark (again from Rob) that it was quicker for dev-ops to put a new version\patch in, than for ITIL to convene an Emergency CAB.

As self-appointed zealot I need to come to the defense of ITIL as in both cases (Aale’s and dev-ops’) it is not so much unlearning or bypassing ITIL, but rather applying it in a practical way. As I have said many times: nowhere in the ITIL publications does it speak about procedure-manuals and how many pages they ought to be. Instead it describes the activities to be undertaken and suggests some rigor to make sure these activities are performed repeatable (for the best outcome).

And the fact that ITIL has more processes now than ever before, doesn't mean there are more activities required (or people, or tools), but it allows each process to be managed separately (from an accountability and reporting point-of-view). If not required, these processes can be easily ‘collapsed’ into a single process(-manual).

It is all about how much rigor  documentation is required, which is dependent for each organisation or even each service. Personally I refer to PRINCE2’s definition of tailoring, which is not about deciding on WHETHER to use any of the theory but on HOW to use it. The level of documentation is then dependent on the size, risk and complexity of the project\organisation\service.

Little side-note: I thought it was comical to, in one of the sessions, see Rob England try to avoid ‘dead cats’ by having an Operations function getting involved in design & test; (i.e. more rigor  and then straight after, on the big stage in a keynote, he is searching for KAMU: a middle-ground between ITIL stability and dev-ops responsiveness (i.e. less rigor).

This is not immediately contradictory  but also not congruent. However I kind of see the point of and agree with both: using Ops-involvement (and sign-off) is great for medium/major changes (on critical services), whilst some of the dev-ops & AGILE principles are more aligned with how Change Management deals with minor or standard changes (with devolved authority and less formality).

So, Aale, we don’t have to unlearn ITIL. And dev-ops and AGILE are just utilising fast-tracked ITIL processes. The basics (of ITIL, of the service lifecycle, and the process-activities) are always applicable, whether you call it ITIL or not (that’s the definition of Best Practice: Common Sense, written down).

ITIL may be at the bottom of the hype-curve, but this is perhaps the time to push it back up to a ‘normalised’ level (the ‘plateau of productivity’), where we can see it for what it is: guidance on how to structure and organise IT activities, in order to deliver value through services to the business. Not a silver bullet but certainly also not old-fashioned.

And here lies the task for AXELOS (and the wider ITSM community) to work towards an ITIL that is more readily applicable. Because I do agree with Aale that some of the sections in the book are ‘silly’, inconsistent and perhaps too open to interpretation. ITIL is never going to be prescriptive, but it would be nice if the next version (4?) was a bit more practical, perhaps with more templates (RACIs etc.) and quick-starts.

And maybe next year there will be more to learn at the conference!

the ITIL Zealot
August 2013