Featured Articles arguing, 360

Published on November 4th, 2011

2

Can we stop arguing definitions and instead collaborate to improve ITSM?

Is Lean more suitable than ITIL for addressing the challenges facing IT?  James West says that the debate around this question reveals a fundamental flaw in the ITSM industry which is stopping us progressing and answering the questions which threaten all of our livelihoods.

The Lean and ITIL article predictably inspired much debate, with some comments supportive, while others critical that the former cannot replace the latter because it is a methodology rather than reference tool, and that the two entities are very different and I shouldn’t dare confuse them.

It’s not a new phenomenon, people in our industry have always been quick to jump on the backs of commentators who stumble when defining something as a standard, a methodology, or just guidelines.  My view is that these ‘debates’ are increasingly pointless because they are distracting us from the real issues. Isn’t it time that we stopped the pointless semantics argument, paid more attention to the world around us and actually found ways to meet the challenges that threaten the future of IT?

Before you wade in and argue that these definitions are important, please ask yourself the following questions: did any of these methods/reference tools/standards fully define and shape any ITSM strategy?  More importantly, do any of them offer absolute solutions for the real world problems facing IT today?  If the answer is no, then why are we so precious about guarding them, let alone how we define them?

The industry has been so protective of ‘best practice’ because it is comforting to fall back on bodies of knowledge.  Having a bubble of unique language and terminology to hide behind means that if outsiders try to question what we do, we have been able to counter by saying the criticism stems from ignorance – “you don’t understand book/standard X so you can’t possibly comment” – regardless of the validity of the point being made.

This cosy club may have once made us feel part of the business; privy to information that only technology experts like us can understand.  The problem is now everyone understands the value of technology because it has been successfully packaged for consumers, and the only meaningful question they have is: “why doesn’t business IT work as well as it does at home?”  Our desperation to cling to our petty debates and definitions is one of the main reasons why we are unable to offer an answer.

Whether something is a reference or a ‘method’, slavishly following it while ignoring common sense and the nuances of the adopting business is foolish.  Failure to understand this principle has led to a perfectly useful body of work (ITIL) becoming elevated in importance to such an absurd degree that it has stifled thinking and innovation in the industry it is designed to support.  Going back to my article, Lean shouldn’t replace ITIL for defining how we manage ITSM if it is considered in absolute terms.  My point was that the ethos of Lean is more suited to the needs of IT than a set of books that is pitched at professionals, already overburdened and fighting complexity, by becoming bigger in each incarnation.

Fear is one of the biggest factors defining business IT right now, predominantly fear that cloud/outsourcing/personal devices will make the internal technology department redundant.  In-fighting and arguing over small details will not help.  Instead, let’s collectively find ways to meet the challenges, to make IT more personal, more attuned to the need of the business and start feeding in new technology that will help our businesses compete in the global economy.

Tags: , , , ,


2 Responses to Can we stop arguing definitions and instead collaborate to improve ITSM?

  1. Steve Romero says:

    I don’t doubt “people in our industry have always been quick to jump on the backs of commentators who stumble when defining something as a standard, a methodology, or just guidelines.” I also agree that having “a bubble of unique language and terminology to hide behind means that if outsiders try to question what we do, we have been able to counter by saying the criticism stems from ignorance.” But I don’t agree that these phenomena are an indictment on all discussions of definition and semantics. In some cases, these ‘debates’ are not pointless and do not distract us from the real issues.

    Accurate understanding is just what we need to avoid “slavishly following” a framework or methodology “while ignoring common sense and the nuances of the adopting business.” Your point that the “ethos of Lean is more suited to the needs of IT than a set of books that is pitched at professionals, already overburdened and fighting complexity, by becoming bigger in each incarnation,” is spot-on, but a comprehensive understanding of Lean and ITIL adds the “and” alternative to the “either-or” choice.
    In my travels evangelizing IT governance around the globe for the past five years, I am constantly asked the “either or” question. “Should we use CMMI, or COBIT, or ITIL, or Lean?” My answer is always the same, “Yes!” My yes-answer is based on my thorough understanding of each of these disciplines and the resulting realization of the mutually advantageous conjunction that exists between them.

    I agree with your contention that we need to “meet the challenges that threaten the future of IT” but in many cases, this requires understanding the “semantics” of the various approaches to meeting those challenges. This understanding is required to come to the realization that no “methods/reference tools/standards fully define and shape any ITSM strategy.” I would be thrilled if an IT organization applied Lean principles to their ITSM program while mapping it to COBIT and using CMMI to assess benchmarks and measure progress. But this scenario is impossible if the organization does not understand the definition and semantics of these disciplines.

    Steve Romero, IT Governance Evangelist
    http://www.itgevangelist.com/

  2. Matthew Burrows says:

    I always say that I don’t care what you call it, the important thing is making sure there is a common understanding. One example from a customer is that we used the term “Service Contract” when we could have expanded their existing SLAs to cover the items that should have been in there but weren’t. The main reason we used a new term was because the old term came with baggage – it was easier to drive the culture/people change by changing the terminology. People had an existing knowledge and expectation based on their existing SLAs, and we could have opted to educate them, but there was merit in having their existing SLA as a schedule of a Service Contract which did so much more, particularly in the Business Relationship Management space. Some people went desperately looking through the ITIL books to find Service Contract, but couldn’t. We provided a clear definition – in fact we provided a whole glossary because we had to cover all of the terms and concepts that we’d adapted as well as the ones we’d adopted as they were. The word “Service” was particularly interesting because we had to define several different types in order to ensure it made sense and worked well in this particular organization.
    We shouldn’t get hung up on names. Much of the time it is easier to use an existing term from something like ITIL, but when it doesn’t work, we need to adapt. ITIL was always designed to be used in an “Adopt and Adapt” way – it’s not a standard, just best practice guidance (which means you can ignore some or all of it if you want to).

    Steve – your comments make perfect sense. I’m always telling people that we need to define “the way we do service management in our organisation”, and that it will be influenced by many different things – most likely including ITIL, ISO20k, Cobit, Lean, CMMI, SFIA, eTOM and many others. The debate and semantics are often necessary so that we make the optimum use of existing terms where they help (if they get us there quicker), but as long as we’re open to adapting them and creating new ones when we need to.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>


Back to Top ↑




  • Snap Poll:

    Where do you normally go for advice on IT strategy?