Management is...... seeing patterns now and acting on them for the future
Management is.... understanding that improvement is always an option.
Management is... marriage of theory and practise.
Management is .... helping things happen. [submitted by Aale Roos]
Management is... laziness. Instead of doing things youself you make others do 'em.
I think the market has started to sort itself out - finally! Two factors:
- saturation in frameworks i.e. too many, too many people already trained, and its becoming overwhelming to determine what ones you should use, why, and how do they relate to each other, if at all.
- disillusion from a lack of results that each one promises in the fact that they all seem to posit the notion that if you just adopt their framework, it will solve all of your issues
The frameworks created too many "Method Lemmings" that could follow the frameworks but not deliver any real business value from the work because following the framework was more important...
Hi Jan van Bon, many thanks for your reply. i just orderd the ISM as well as the design/implementation book. I retired in Jan 2012 after a number of years with the US Federal government and have worked on several very large and complex IT projects.
Over the past 15 or so years before retirement I was involved with a number of improvement projects. I have been consulting in various areas over the last year and have decided to write a series of articles on ITSM focused on the US Federal government. I'll keep you informed. Oh, by the way I lived & worked in Europe (Germany, Netherlands, Maastricht & Italy) over a 14 year period. I would be very interested in knowing if there are any papers that were developed for the work that was done for the Dutch government that could be shared. Thx Ron
That is exactly what we solved in the Netherlands with the ISM Method.
Standardized structures, standardized plans, predictable results and cost, customzable to any organization size. Check http://bit.ly/ISMbook
I couldn't agree more. Its even more fussy when applying all the other ISO20k requirements, not just the SMP in the federal government environment. Would most interested in a dialog with anyone wokring in this area.
I have thought and been confronted many times for many years that all these frameworks are extremely difficult, if NOT impossible to effectively plan and implement within a complex organization structure like a national government in any consistent, uniform, and cost effective manner.
There is aneed to fill this gap and I would like to hear from others. Thanks
ITIL Master from APMG is on same lines as CCIE from Cisco. It is less about teaching and more about evaluating whether an individual can apply the fundamentals at workplace and give real tangible results to business.
Postgraduate courses cannot beat real field experience and application of principles and hence, ITIL master course will eventually get its due in industry and provided APMG does not let it get diluted, it will stay the best certification in ITSM domain.
In V3 they went from using "best practice" to describe it to using "good practice" - I guess the 2011 version must be "bestest practice" or "gooder practice". :) Not sure what they will call the next version!
Regardless of what they call it, it has become bloated and dangerous as it has resulted in the never ending debates in on-line forums as everyone tries to figure out just what the heck it all means. If it is supposed to be some sort of a "practice" that can be followed then we should be able to just follow it shouldn't we? Instead we spend our time in endless debates trying to decipher what was meant by this or that term or this or that process. And that is what makes it dangerous to organizations in my view as the never ending debate detracts from actually doing anything with it!
I too have seen the slog of never ending consultants who make hay (and millions) off the backs of their unsuspecting clients (both large and small) by trying to make sense of it - time after time anew for each client as if they themselves are seeing it for the first time! Just how many BPMN diagrams generically mapping what is in the ITIL texts do we really need in this world anyway?
I think @Jan with ISM has nailed it - just give organizations a plug-in set of processes and procedures they can start with right away and then evolve with any specificities that may be unique to their situation.
Like the Nike ad, organizations just need us to be able to "do it" and to stop talking about what is meant by "doing it!". If you ask any of your customers or clients I am pretty sure none of them really care what we think ITIL means, they care about whether or not they are getting efficiency and effectiveness out of what we do for them in every sense of what that implies.
And I can't see much efficiency or effectiveness from something that none of us can seem to agree on as to what it is supposed to be telling us. It has ceased being a set of best practices to me and become more of a sink hole of never ending debate. Yep there's some good to be had from it - but only if we use some rationality and logic in what we extract so we can actually start delivering and stop talking about what delivering means.
ISM is damm fine start on doing just that.
For Rob England when he is able to comment here to accompany tweets. When someone suggests the output from a project is an artifact, the catalog was mentioned, and the business benefit is better KPIs, that is inside-out thinking in action. Then again it depends on who the customer is, if they are an internal stakeholder who cares most about the KPI - point taken.
But, a service management outcome should be associated directly with an activity a customer is able to perform in pursuit of success..... not a project artifact...
my point was that ITIL v3 authors have chopped the v2 CHM process in pieces, creating even more complexity than v2 already had (in terms of redundant practices). And of course I can jump back and forth to discuss the evolution of ITIL.
ITIL has never claimed to be 'theory' but has always been defined as 'best practice', it's on page 1 of each book. As a consequence I don't see how I can make 'fundamental errors' on 'ITIL theory' -imho that doesn't exist.
Larry - since we have now connected - I think the application of Agile thinking within IT, across the board - is where we should be focused. Traditionally, Agile has its roots in software development, more recently product management, and its value to me is that it reinforces outside-in or customer centric decision making against a backdrop of change at the speed of light.
In today's connected, social world, needs and wants, opinions and experiences can be influenced and change in real-time. Service Management (the one I refer to in the USMBOK, not the traditional - made up version we see in many IT shops), was designed to help those delivery products adapt to the service society.
Agile to me, resurrects the old 30-60-90 timeboxing principles of old and mixes in the user perspective (epics, stories and so on) to make sure that under time and money pressures, the provider is working on the right thing.
Frankly, I can't see any difference here for ITSM. So my view is that Agile helps refocus an IT organization under pressure to deliver, with finite or not enough resources, but here I dont mean deliver on an ITSm project.
No I mean deliver - deliver the information services needed by their customers.
So I use what many might recognize as Agile thinking, along with Outside-In for emphasis, and (universal) service management, plus a few other useful methods, to help folks establish a continuous capability to find opportunities to improve, and to prioritize and sequence work properly.
Unfortunately, I have read and heard of many using the term to imply lighter or more nimble ITSM projects... ho hum...
Unfortunately in my opinion - good acronym, misplaced emphasis. Totally agree with your opening sentence - ITSM is a means to an end. Not the end itself. Then I differ.
ITSM as a project is a total waste of time. After all, what is the role of IT today - hopefully something close to providing the IT the business needs to be successful. In fact ITSM is a shiny object to many, an attractive force that gets in the way of understanding what needs to be done.
ITSM should be read as the application of a service management philosophy, its concepts and methods, to the challenges of an organization being judged or performance managed as a service provider. Yup, we can count IT in that.
Service management as I have written frequently, is all about looking at things from the outside-in, or the perspective of those using the service to some purpose. So when you cite outcome, its not an output. Or the result of a project, those are inside-out views. Its the result or 'successful customer outcome' the user of a service achieves, through its use.
You then have to consider what the USMBOK terms the 4Es - expectation, span of service (request) encounter, experience delivered, and emotions at play. This is service management as invented and defined by the non-IT folks - the business.
So good acronym, good start, healthy conversation, but I fear still inside-out working its way to outside-in... torturous path....
Here is an informed article on release management.
Sorry Jan, I have an ITIL v2 book here. Change and Release Management are two distinct processes even in v2. Release Management is much more elaborated in v3 and even further elaborated in 2011.
Please identify the source that identifies transition planning and support in v2 as part of change management. Transition planning and support is a net new process introduced in v3.
ITIL did change a lot in v3 to be more readable and aligned with a SDLC.
I would not really talk about v2 anymore. It has been replaced with v3. You cannot jump back and forth between the two. While a business could operate on v2, there is a reason the new versions are introduced as part of the continuous improvement of ITIL.
My challenge is your article makes some very fundamental errors about ITIL theory.
ITIL is only a collection processes. How you implement these processes would be defines as practice. Which one does ITIL refer to as a practice in your comment:
"The list contains RM and CHM, labeled as 'processes'. Many people have a very hard time understanding this, when the one is described as a process ( the 'what') and the other as a practice (including the 'how')."
Please site the ITIL source I can refer to.
ITIL says that it has some 30 processes, and then lists them, ordered in sections that are called 'life cycle phases'. The list contains RM and CHM, labeled as 'processes'.
Many people have a very hard time understanding this, when the one is described as a process ( the 'what') and the other as a practice (including the 'how').
The same goes for my list of 5 processes that used to compose one process, CHM (in v2). So, either v3 changed the very nature of ITIL content, or someone has messed this up in such a way that many readers can't follow any more.
My column was based on a long discussion with ITSM experts where this was the issue.
By the way, this statement is incorrect:
"In ITIL v3 and beyond, the CHM process was split up into 5 components:
•Service validation and testing
•Transition planning & support
•Release and deployment management
•and..... Change management."
These are not the components of Change Management. These are the components of Service Transition.
It is very incorrect to say that ITIL defines Release Management and Change Management are one and the same processes.
I am assuming JVB is not referring to the ITIL defintions of release management and change managemenet with this statement: "What RM activities are NOT covered in CHM?" The true answer is "all of them" based on ITIL definitions of the two processes. Change is about managing risks, scheduling, and approvals. Where are release is focused on build, test and deployment. These are two distinct but interdependent processes or components within service transition.
From the sounds of it, JVB is discussing a change management process that has incorporated elements of release management. This is a common mistake when people use their working definitions of processes instead of the ITIL process definitions for processes.
By definition, a release could consist of a single change which kind of breaks down the entire discussion.
Good Article Jan and interesting view points! After many many years of working for large enterprises release management and change management often was so overlapped they where seen as one function BUT release management is probably the one ITIL discipline that has been most neglected and badly defined as a job description. I often see that a Change Manager (aka Implementation or deployment manager) being put on the hook for managing releases through the various pre-production phases (design, build, test) only to be pushed out of the function due to high volume of emergency BAU changes.
Many very large orgs these days are starting to run release management (Im talking about pre-production, project and BAU releases) as a separate function under the umbrella term 'Enterprise Release Management'. We have picked up on this and after realising that ITSM tools which cater for prod change management dont actually work and fit the profile to manage pre-production release planning and execution we started Plutora http://www.plutora.com to address this gap.
From what I've seen in several banks so far is that the formal release management function is only going to get bigger and bigger purely because of the complexity involved in managing concurrently releases across different assets with multiple vendors.
Full Disclosure, I'm a founder at Plutora Inc.
"Complexity is their culture" well said.
I like this quote :D
@Farhan - that is exactly what I meant. In the Netherlands this is a reasonably common practice. Only the larger organizations are likely to follow the overly complex guidance, but then again "complexity is their culture".
@Jan. Great article. Ever since I started in the ITIL world, I felt similarly and I work for mid size firm with a decent size IT department. The ITIL V3 processes are way over the top for most organizations. They are almost targeting large software development companies cranking out releases to a large customer base. Our approach in change management is very similar to what you mentioned...all changes are changes, whether standard or not. Where possible we bundle changes from different systems together in the same time windows to minimize multiple service interruptions. From a RM point of view bundling multiple changes in one software release is fine but it should be built in a way where any one should be able to roll back any one change if it is causing issues in production.
Thank you for this very useful informations, it really helps me as part of IT Team achieving ISO 20000 Certification.