Release management also defines release policy

Transition planning defines release policy [ST p 36], which makes sense. Release management [ST 4.4 p84] also defines release policy which makes less sense.


I can see what you are getting at

I can see what you are getting at. i think it could be argued that the two definitions of policy are slightly different althouygh they overlap. One is in advance as general policy, and the other is in the event as an instance... I think

It is not the only overlap

One of the improvements I was hoping for in V3 would have been clearer roles and responsibilities between the processes.

This overlap is not the only one. There are a lot more areas where two or more processes or areas overlap. The whole Strategy book is detached from the other books. There are not many connections between the strategy book and the other books. For example shouldn't Release policy be a Strategic decicion at higher level and Release management should be just practical application.

Roles and responsibilities

Hey Aale,

In response to your remark on roles and responsibilities: Microsoft Operations Framework (M.O.F. - currently revised to version 4) is mostly based on ITIL. It has however (amongst others) a team model added in comparison to ITIL. Part of the added value of this model is the prevention of the combining of responsibilities that could 'bite' each other.



Hey Michiel

Good point, biting each other. It is easy to imagine what a mess it would be if some large corporation would really implement V3. There would be a fantastic tangle of overlapping processes and functions.

Br Aale

Provincial view

Hate to burst your bubble, but more than a few Fortune 100 firms have spent the last 10 months adopting v3 practices; from strategy to CSI. A NYC-based financial services firm, for example, completed a global program adopting v3 operating models, processes, roles & responsibilities, etc. The results were significant enough that the accountable managing director received a significant promotion.

10 months is a short time

Impressive, the books haven't been out 10 months and some has already implemented everything and even got results. I think it take a bit longer to make actual change.

Sorry but this reminds me of a Dilbert strip about bungee management. Manager comes in, changes everything and leaves before anybody has even noticed the changes.

added value

Well, let's look at it from the bright side: this proves at least part of the added value of ITIL, which is to give a managing director a significant promotion.

Success begets success

Certainly more value than being fired.

Any competence in organizational/cultural change must incorporate ideas such as "bounded rationality" and "satisficing". In other words, it is not enough to address the rational components of change. If the irrational components (e.g., self-interest) are not addressed, then the improvements are not real or valued.

So I agree, the promotion is a key component of value.

Of course, its much easier to deride real-world successes and assert ITILv3 cannot be done, or it takes too long, too expensive, too English, too much process, not enough process, etc.

Update your calendar

The books were released in May 2007. We are well into March 2008. Ergo 10 months.

Much can happen in that time unless (1) you have trouble with basic math and (2) you charge by the hour.

To consider 10 months a "short time" is indeed dilbertesque. How many years is "enough"?

how many years

The books came out on May 30 so 10 months was yesterday. Of course that is not the point. 9 or 10 months is a long enough time for making improvements but a short time for "...completed a global program adopting v3 operating models, processes, roles & responsibilities, etc." It is very impressive if it is real. I'm skeptic.

I'n my experience adopting one process takes several months and it is hopeless to try to force many processes at the same time. People do not have the time. I would be able to charge more if I could push up the speed of implementation. My charge is by process no by the hour.

Measure Value and Success

Most IT organizations that have been introduced to ITIL for the first time will notice value and success in it's first year. Since ITIL (in any version) has a lot of good practices and common sense a reasonable implementation would have brought successes to any manager who have taken the plunge and has used these practices. I will fully believe that IT organizations can have implemented aspects of ITIL3 with success in a 10 month period. Will this success last? Will they move forward and keep improving and implementing ITIL3 practices? What will happen now the manager got a promotion? Will someone else take over the shining light and keep on moving?

The real value and success is in sustaining the quality of service delivery over a longer period of time. And 10 months is not sufficient enough to judge the improvements fully. In the Netherlands we have been implementing ITIL for the past 15 something years. At first we noticed the same kind of successes, the IT service delivery actually improved, uptime went up and downtime became less. And now we are still in the early maturity stages and are experiencing difficulties in maintaining and improving the value we've got at first. I will fully agree that ITIL3 adds more practices for maintaining and improving the quality levels with the CSI book. And it will take several years before we can fully appreciate what OCG and Sharon Taylor have done for us. Or.... we will have found out that ITIL3 has been replaced with ITIL4 (the new name for the SMBOK ;-)

What does it mean to "do ITIL"?

I still am hung up on one basic thing: for large organizations who have been running correspondingly large internal IT capabilities for many years, what does it mean to "do ITIL"? To be "introduced" to ITIL? (Hi, you should do Incident Management! Do tell...) Most if not all of the ITIL processes (perhaps under different names) can be found in some recognizable form in most large IT shops, perhaps based on Harris Kern literature and non-ITIL-based operational IT consulting.

The question is how explicitly such processes are recognized and managed, and how much of a gap lies between such actual practice and the ITIL guidance. But this is a question of degree.

The only organizations for which the question of "doing ITIL" appears to be relevant is the small IT shop who hasn't formalized much of anything, completely relying on heroics even for things like incident management.

Charles T. Betz

Service Management Body of Knowledge

We're tending to use, more and more, the Service Management Body of Knowledge as the primary process view of things. We're finding it provides a better, more comprehensible, structure than does ITIL v.3. We've also found that its use of materials from other, already established, disciplines like Configuration Management, from outside IT, tend to lend greater credibility with clients.
We use ITIL v.3 for what it seems to be, a good practices reference to stimulate thought and conversation. Not as a process guideline. And, certainly not as a policy or organizational structure guideline.

Syndicate content