This post has been podcast

[Updated again: links to COBIT planned content]
Those who say "COBIT is the what and ITIL the how" either haven't read COBIT, are oversimplifying or are being excessively polite to ITIL.

Everyone is tiptoeing around the fact that COBIT offers a significant competitive body of knowledge (BOK) to ITIL. Sure ITIL goes into more depth in places, but to say COBIT sits over the top is to grossly understate the overlap. COBIT extends a long way down into the "how" and it does it with an intellectual rigour that ITIL lacks. I haven't done or seen a detailed mapping but my guess is that COBIT is as comprehensive a description of the how as ITIL in some areas. And of course it covers areas ITIL (even ITIL V3) doesn't, such as information architecture (PO2), manage HR (PO7), educate and train users (DS7), ensure compliance with external requirements (ME3) or provide IT Governance (ME4).

I feel COBIT suffers a bit from the ITIL V1 and V2 problem of too many books: it is a fragmented BOK with multiple perspectives. This is great in terms of being able to find a view of the BOK to suit any situation, but it makes it more challenging to find the right view (book). Funding those consultants again.

Take a look at my favourite: COBIT Control Practices. Add to it the IT Assurance Guide for assessment, the IT Governance Implementation Guide for business governance, Val IT (now 2.0) for measurement, and what looks to be a great book, the upcoming COBIT User's Guide for Service Managers. [updated: "The guide will contain ... the key governance tasks for the role aligned to the ITIL 3 processes and COBIT 4.1 control objectives" What a shame ITIL V3 wasn't quite so cooperative in the reverse direction!] Put them all together and you have a hefty BOK on the "how" that I think easily rivals ITIL.

[Updated:]And take a look at what is coming down the pipeline from ITGI/ISACA. This is starting to look very like ITIL V1's 26 books!

But it's not considered polite to say so and spoil ITIL's day (or decade) in the spotlight.


Not read Cobit...?


ISACA itself says in the Cobit-ITIL mapping document, that "Cobit defines the what, and ITIL provides the how".

Are you suggesting that ISACA haven't read Cobit? No, it must be that they are very polite. And that is not a bad thing on that level.



All in good time...

yes I noticed that the other day and it made me smile.

I think ITGI and ISACA are exceedingly polite, given the brash upstart that is currently posturing all over their front lawn as if it owned the place.

In their own genteel way I think they are getting quietly even, what with the mapping paper and now the Service Managers guide. All in good time... ITIL will be put firmly (but politely) back in its place any year now.

Jack of all trades, master of none

I do not believe a single individual or consultant can know everything about ITIL, never mind ITIL and COBIT. It is not about individual knowledge or endeavour but the dynamics of a tiger team operating to achieve objectives.
I do not believe there are generic ITIL experts but I truly believe it is possible to construct a team of ITIL experts. Now if one of these experts focussed on a field, e.g. problem management and the BOK came from ITIL / COBIT or even MORT or Taproot, who cares?
I think there is no difference between "ITIL compliant" software or "ITIL compliant" consultants. A single individual cannot consult on ITIL in the same manner as a single vendor cannot deliver software that does ITIL.

ITIL experts

Oh I can think of a quite a few names that I would be happy to have consult on any aspect of ITIL. Bear in mind there are people with very experience of ITIL and ISO IEC 20000 who have been involved in every stage of their development. I do cocncede that weare talkign about management consultancy here - I wouldn't let any of them near the technology side of things ;-)

Sadly though there are a lot of ITIL experts, in training, in consultancy and in management roles whose knowledge really is limited to the old service support disciplines - and even then they are often lacking in problem management.

Getting dirty

How good are you really if you don't get dirty?
Read Step inside the circle -
I would like to challenge ITIL consultants to genchi genbutsu by going into the data center, and drawing a circle. After sitting and analysing for a few hours would they be able to provide ten improvements that directly address anomalies from their direct observations.
BTW: I think I have just stumbled across the perfect practical exercise for the next job interviewee.

Practical Experience

Get dirty is great advice. After working as an ITIL consultant for some years I often felt I was on a bit of a high horse telling IT employees how to run their departments.

I decided to actually take a role where I actually worked in IT to try to walk a mile in their shoes.

Funny thing, less than 2 years later, my job disappeared because of a Service Transformation / ITIL implementation.

From a people perspective, my observation is that ITIL sends the IT cowboys on their way, and will download a lot of work on to the IT worker.

Also, an ITIL implementation can promise a renewal for an IT department which has made some huge project failures.

Interesting option

I would like to get dirty in this way... but I wouldn't draw the circle in the datacenter, as this is where technology lives... and ITIL is more about people than about technology. I would like to draw the circle in the middle of the IT department, just between the tables of the development team and the operations team, near the CIO desk and close to the helpdesk... and wait. Just close your eyes and concentrate on the conversations.

In a few hours you can hace more than ten improvements coming fromo your direct observations. I bet.


Already better than some...

If you could sit in one place and see those people at the same time then you are already in a better IT department than most. For all the metaphorical talk of silos I'm suprised how many IT departments are still located in building(s) where the office layout and design encourages silo thinking rather than communication and cross team working.

The corner office

That is right. Not many CIOs can eyeball the troops from their desk in the corner office.

audit nose

I think all the names I was thinking of could come up with a starter for 10, and also most of the decent auditors I've worked with. After all in the case of the ITIL names they have all had experience of operations.

Lets have a go myself, thinking of a typical set up that I was in just the other day

1 - Remove the clutter - old manuals and disks lying around is a no no, and my bete noir is people storing things in the server room, closely followed by dust, especially in any voids. Start the ritual of a weekly clean up. DON'T TRUST IT TO CLEANERS. I vacuum/hoover every orifice of my home office computers, but perhaps I'm a little bit sad*.

2 - If possible reorganise the server room so that it is as easy to get old kit out for repair/replacement as it is is to install new kit. I've been in server rooms where the server everything else depended on was impossible to reach physically. It was such a shame when its' power supply caught fire.

3 - Likewise with cabling, it doesn't have to sophisticated structured cabling, but patching is a mess far too often. Even in my home office I have 'cable days**' where I desperatly attempt to find a logical approach. Last week I found three cables that weren't attached to anything at the other end, and a back up drive that wasn't connected to the disk it was supposed to be protecting

4 - Stop people doing cable patching on the fly.

5 - Stop people doing anything on the fly. Make sure there is an effective and policed work log signed off by a third party.

6 - NO engineer goes anywhere near my system without telling me exactly what he is going to do in advance, and what they will do if it goes wrong.

7 - No default passwords

8 - Power, power, power - enough of it, conditioned, and with tested back up. Nothing worse than a UPS that doesn't kick in****. Check that you can restart the system cleanly as well. Check you know where the cables go when they leave the server room. That applies to any cable going out the door until it is off your site.

9 - Make sure manuals and key software you might need to load from media are where they should be, with the right balance between accesibility and security.

10 - Make sure you have up to date SOPS for all likely outcomes. I was in a client's site the other day that was nearly crippled because (see 8 and 9 as well) they didn't have the right instructions available to restore the VOIP service after a power outage.

11 - Make a manager go into the server room at least once a week.Just don't let him touch anything. He doesn't have to talk to anybody.

12 - Ask difficult questions of anyone claiming to be doing real time monitoring. Remind them of Three Mile Island.

13 - Take photos of the server room, including the back of everything you have on racks, you never know when it might come in handy.

You'll noticed I've not focussed on many people issues, so

14 - take each member of the ops team off to a dark corner where a) nobody can hear their confessions and b) nobody can hear their screams. Just ask them what they think their responsibilities are, and what could get them sacked.

15 - A brilliant book

Sadly out of print. Sid has a website

Buy as many books as you can secondhand. Make sure everyone reads them.

Now the key point about 15 is this - everyone in the US in particular looks for an individual element of the TPS that makes it work, not at the whole philosophy. His book is a masterwork in applying Japanese approaches in western cultures.

Skep, any chance of a thread about our favourite bedside reading?

ITIL? Use it to keep the server room door open whilst you are taking out that failed UPS***.

* No serioulsy it can really affect the temperature of motherboards - you do monitor that, don't you?
** OK, I am sad, but I only do it because if my other half does it things will be tidy but won't work.
*** Only kiding guys.
**** OK, there are worse things, but do you know how shaming it is when the Police come to see you because the noise, smoke and fumes from your back up generator have caused complaints from your residential neighbours? Especially when the generators didn't even keep running because nobody had made sure they had fuel.

You are hired!

James, your hired. Please start Monday and bring your own vacuum cleaner.

The Toyota method


I'd like to think I could come up with a typical top ten list after spending ten minutes in an IT management team meeting as well.

There is another book out soon, that judging by the article based on it that appeared in the June HBR could be worth reading

"Extreme Toyota: Radical Contradictions that Drive Success..."
by Takeuchi, Osono and Shimizu

Now that you have brought up the subject of Toyota

Well, I suppose I did but the more I read about it the more I like it. However, the nonsense that followed it like Lean and Six Sigma is smelly pooh.
Funny, I feel the same way about ITIL v2 versus ITIL v3. I am alone in thinking that the plot has been lost in v3?

The smell of ITIL

Both Lean and Six sigma have their place, but like anything they aren't a panacea, particularly when implemented as a fad.

As for ITIL v3 - my personal jury is still out. Does v3 give me anything that makes my job easier? No. Has it introduced any new concepts I wasn't already aware of? Notn that I've noticed.

But perhaps we should see it as a work in progress, which at least encourages us to look at service management afresh. The real insights might not be in the books themselves yet, but could arise as the professionals start to use v3. I think it is fair comment that my view and understanding of v1 and v2 changed significantly as I used it more and went into it in more depth. A lot of the insight was gained from time debating with delegates on the training courses, and I worry that the changes in training will prevent that sort of debate about v3

Responding to your earlier post with the list of basic things I would look for in a data centre made me think how much of what I do myself isn't actually explicit in ITIL, perhaps because we think it is too simple, obvious and uninteresting. Sadly though it is the basics that still trip people up.

Perhaps Real ITSM is the answer ;-) I've ordered the book (actually two copies by mistake) so hopefully I'll find out soon

write a book

James - you should WRITE a book.

yeah let's have a thread...

A P.S. to the above

I'm not going to claim any credit for those ideas, most of them were in one of my two "audit bibles" when I was young, the UK's CIPFA Computer Audit Guidelines which gave you chapter and verse on how to audit a data centre. Just don't try and check for dirt in the voids if the computer room has solid floors, as two of my students found out. It was galling for them that their Head of Computer Audit was also one of my visiting lecturers at the time, and would occasionally mention the point, or at least once a week, whichever was most frequent. On the other hand the Ops manager I know who put a new water cooled IBM mainframe on to an unstrengthend computer room floor whilst they moved the old one out of the way knows all about that certain sinking feeling. A well known ITSMF personality can tell you all about that horrid moment when it turns out the cable you cut isn't the one that isn't working but the back up circuit that HAD been working right up until that second*

The other "audit bible", BTW, was Sawyer's Modern Internal Auditing, which is also well deserving of a read if only to get to my all time favourite audit quote** "Control is a force - it gets things done"

* let us call him IE, to hide his shame, and it isn't his worst story. That involved an engineer doing a repair to a water pipe in the ceiling void with a blowtorch, who was knocked off his step ladder,whilst he had his hand on a recently detached waterpipe, and fell on to the comms and electrical cables in the floor void that was been worked on at the same time. I'll let you imagine the full horror of how the situation played out. It was in a data centre that the entire UK's defence rested on at the time.

**OK some of us have favourite audit quotes. Get over it, I have.

Life would be boring

If the knowledge required to managed IT Service Delivery was a commodity and easily documented by one organization, or person, then most of the readers of this blog would probably not be doing what we are doing.

Innovations is stifled by acceptance of one true monopoly of thought. To all you budding publishers, authors and professional organizations who think they have a different point of view... Bring it on!!

Let the consulting dollars flow and the opportunity to specialize in this area thrive.


Brad Vaughan

blinded by the guidance

I am guilty of saying pretty much that same thing, and having recently passed the CISA Exam have read CobiT. I'm not sure I agree that CobiT is 'competitive' to ITIL and view it more as 'complimentary'. Is there overlap? Absolutely. I do think CobiT's focus is much more on WHAT to control than on HOW to control it, but I'm not sure where "CobiT sits over the top of ITIL" comes from; not sure what that means...can't remember ever saying that one...perhaps the governance aspect...

No one said you have to limit your knowledge to ITIL, or CobiT or anything else for that matter anyway. We are free to use whatever we want, and must judge the value of any guidance for ourselves.

At the end of the day, the only BOK that matters is the one YOU determine is helping you succeed. So by all means be Skeptical....don't be blind TO the guidance, but don't be blinded BY it either.

I don't think we will ever have a single, universally accepted BOK and in the spirit of honesty hope we never do. I am, after all, a trainer and consultant. So bring on ITIL, CobiT, PMI, ISO 20K, et al...gotta know 'em all


Mama always told me not to look into the sights of the sun
Oh but mama that's where the fun is

John M. Worthington
MyServiceMonitor, LLC

Tower of Babel or a Rosetta Stone?


You write:

"At the end of the day, the only BOK that matters is the one YOU determine is helping you succeed. So by all means be Skeptical....don't be blind TO the guidance, but don't be blinded BY it either.

I don't think we will ever have a single, universally accepted BOK and in the spirit of honesty hope we never do. I am, after all, a trainer and consultant. So bring on ITIL, CobiT, PMI, ISO 20K, et al...gotta know 'em all"

I partially disagree with you.

I think that, if properly constructed, a Body of Knowledge (BOK) should provide an adequate view and conceptual model in a given area that allows you to have a more whole, unified view of the area.

It should give you the ability to consider many other types of (seemingly disparate) knowledge and help you connect it all together. We don't need to suck up all the detail and produce a single, grand, unified theory of everything! You're welcome to try, but I certainly wouldn't want to.

What we have today is the equivalent of the story of the Tower of Babel in the bible(Genesis 11:5-9) that we've inflicted on ourselves!!

We all speak our own specialist language and consider knowledge from the perspective that the language gives. I think that we can use a BOK as a means to translate and build bridges between areas of specialized knowledge. In a very real sesne, it can act as means to translate between the areas -- a Rosetta Stone (of sorts).

In so doing, we can each gain an understanding and appreciation for the constituent parts that directly contributes to an enhanced view of the whole that wasn't available prior.


the Manager in the Street

I think the Manager in the Street wants one answer-in-a-box to their process problems and that answer is - according to everything they hear - ITIL. 90% of the IT community are not party to our broader knowledge of other frameworks and complementary systems. if they have heard of COBIT at all it is as some obscure audit thing. And none of them have the leisure of picking and choosing or mixing and matching - only expensive consultants do that for the small proportion of organisations that pay for a tailor-made solution.

if the wind changes and all the talk is about COBIT, it will need only a little meat on the bones to provide much the same guidance as ITIL does now, only over a broader range. So I say "why not?" and so do others. there is more in-depth guidance to COBIT arriving all the time.

it has the components that ITIL lacks such as prescriptive criteria for assessment but I think it is as loosely aligned to ISO20000 as ITIL is (comment anyone?)

personally i think the world is moving towards more professional formal systems such as COBIT, and the amateur ITIL days are numbered. Big numbers but numbered.

Where Are We Now?

One of the questions the CSI Model asks is "Where Are We Now?" In ITIL v2 at least we had a self-assessment questionnaire to help answer that question. Version 3 leaves that question painfully unanswered (or, worse, answered any way you want).

Your comment, "it has the components that ITIL lacks such as prescriptive criteria for assessment but I think it is as loosely aligned to ISO20000 as ITIL is (comment anyone?) hit a nerve with me.

I can't seem to find out when we will see Part 8 of ISO/IEC 15504, which is a Process Assessment Model (PAM) based on an ITSM Process Reference Model (PRM or framework - in this case ISO 20K).

From what I have heard it may be 2 years away. TWO YEARS AWAY?! And that's based on ISO 20K (not ITIL v3). Perhaps it is up to the marketplace to establish a PAM for ITIL v3? I'd like to know how we'd get that "blessed" by ITIL if that's the case.

This leaves plenty of wiggle room for assessment in the meantime, which I don't think is a good thing....for ITIL or anybody. Standards-based assessment against these frameworks would be a very, very good thing.

Until that happens, You Are Wherever You Say You Are.

John M. Worthington
MyServiceMonitor, LLC

Process Assessment Model for ITIL V3

What if we built our own PAM here?

The IT Skeptic and the Raroa Coding Gnome have been busy. Wait a couple of days....

I’d be curious as to what

I’d be curious as to what you come up with.

I suspect ITILv3 kept out of the PAM game for very good reasons. Much like the “definition of process”, process assessments (i.e. process capability models) are another area under flux. There are many available if needed: ISO, proprietary and open. ITIL shouldn’t have invented another.

Most of the models, however, are derivations from CMMI, Bootstrap, Trillium and the like. Such PAMs have shown themselves to be either woefully inadequate or deeply flawed.

I’d welcome any real breakthroughs.

ad nauseum

Sorry I've heard this argument ad nauseum that a framework for ITIL assessment is either

  • too hard
  • imperfect
  • a moving target
  • not necessary because we have ISO20000 etc...
  • available at a special price for you my friend from MegaBucks Consulting Inc or free with your MegaBucks CMDB

I'm not buying it for the simple reason that the user base is not buying it. People want ITIL and they want to know if they are doing ITIL and they want to know if their supplier is doing ITIL or if their megabucks consulting firm is giving them ITIL.

I think ducking the issue just shows that Castle ITIL is more focused on producing a product than meeting the needs of the users - the very attitude and behaviour that ITSM is supposed to fix.

Funny that it wasn't too hard for COBIT.

I apologize. I thought you

I apologize. I thought you were referring to a PAM acting as an exemplar, a model of excellence independent of the process implementations it measures; something akin to SCE or ISO/IEC 15504, rather than an ITIL compliance model.

Forgetting for the moment that ITIL is not positioned as a process framework (except, perhaps, by that same user base), an ITILv3 PAM should not duplicate known shortcomings. For example, there is no universal agreement that the maturity/capability of a process corresponds to the maturity/capability of, say, service delivery. To what extent should IT staff focus on the management of services vs. the attributes of the processes used to manage those services?

Mature IT services can be delivered with little process and poor service delivery has been designed under the guidance of mature/capable processes. For smaller organizations, the burden of heavy process structures far exceeds the benefits, regardless of the assessment of most PAMs. Heck, there are billion dollar organizations who've correctly reached the same conclusion.

Perhaps I missed it but I haven't found this addressed in Cobit. Feel free to correct me.

Is 15504 a good road?

I thought ISO 15504 provided an exemplar, and that this was the basis for others to develop PAMs specific to a process or process framework (like ISO 20K?). I admittedly am still learning about ISO 15504, but I thought that it clearly indicates that you need to balance the gaps in process capabilities and attributes against business objectives. It does not say 'process for process sake'.

CobiT seems to be all over linking IT to the business, and the ITIL (or ISO 20K) processes seem to provide the process framework against which an 'agreed' PAM could be established. My thought was that having an ISO 15504 based PAM for ITIL would be a great way to get some consistency in evaluating ITIL implementations. Proprietary assessments may lead to a fox in the hen-house kinda thing, ya' know?

It might also enable some research to determine just how much process benefits service delivery for that matter.

The more I learn about ISO 15504 the more I'm drawn to it's potential, but I'd be happy to know if I'm lost in space. I've been reading Han van Loon's book(s) for now, and may eventually break down and buy the standard.

It just seems to me that ISO 15504 would (might?) bridle some of the enthusiasm over various frameworks and force some consistency across customers and suppliers. While any PAM would take hits, having the framework providers 'bless' the assessment model would be a pretty good starting point.

So I'm on the road to 15504 for now. Is it worth the trip?

John M. Worthington
MyServiceMonitor, LLC

[Link added by the Skeptic:]

If you thought ITIL was expensive try ISO15504

Hell's bells! If you thought ITIL was expensive...
ISO 15504 (a.k.a. SPICE, Software Process Improvement and Capability dEtermination) has 6 parts. The 7th is currently in Final Draft Standard form. Part 8 is coming.

  • 1: Concepts and vocabulary
  • 2: Performing an Assessment
  • 3: Guidance on performing an assessment
  • 4: Guidance on use for process improvement and process capability determination
  • 5: An exemplar Process Assessment Model
  • 6: An exemplar system life cycle Process Assessment Model
  • 7: Assessment of Organizational Maturity

5 are on Amazon:


ISO/IEC 15504 is probably

ISO/IEC 15504 is probably one the best publicly-available exemplars. It has shown interesting evidence of its predictive validity for organizations over 50 staff. However, the evidence doesn’t show a similar suitability for smaller organizations.

Its roots are in software process assessments and it shows. It shares a common set of problems, some of which have been mentioned, but which are primarily based with the hazards of idealized end-states and artificially derived practices. These types of PAMs emphasize statistical process control methods--an approach that has been called into question.

There is a move afoot in many channels to develop alternative approaches but it will take time. There is a recognized need, for example, for assessments to be closely tailored to the company’s overall strategy. Do the imperatives require IT to support speed and entrepreneurship, as seen in some firms, or high degrees of collaboration and partnership, as seen in others? Without well considered linkages--not just a checklist--it’s tough to get executive sponsorship for the assessed recommendations, leading to low priority and inadequate funding/resources.

An alternative approach, for example, is performing assessments though a participative approach: tailored to the goals and needs of the individual organization, not benchmarked against a synthetic model of best practices. The Scandinavians (i.e., SINTEF) are quite active on developing this approach.

That said, you could do much worse than ISO/IEC 15504. It is worth close study.

TIPA (ITSM SPICE) is ISO/IEC 15504 Assessment for ITIL

I have read, with interest, the thread on using ISO/IEC 15504 as the Assessment Model for ITIL and/or ISO/IEC 20000. This Model has existed for a while now, in the form of TIPA (Tudor IT Process Assessment).

TIPA is an internationally-recognized framework that uses the principles of the ISO/IEC 15504 standard for IT process assessment within an organization. The framework offers a turnkey solution to determine the maturity levels of IT processes that are aligned with IT best practices such as ITIL, and enables process improvements.

TIPA is the result of over seven years of research by a team of international researchers who also worked on the development and review of both the ISO/IEC 15504 (Process Assessment) and the ISO/IEC 20000 (ITSM Quality Standard).

The TIPA initiative began in 2003 when a research project was defined in order to develop a framework for assessing IT Service Management (ITSM) processes. The issues that organizations were facing while improving their ITSM processes, such as the need for an objective and repeatable approach for assessing processes and a well-structured improvement path to follow, paved the foundation of the initiative.

From the year 2003, the ISO/IEC 15504 has been revised as a generic process assessment standard. It was then possible to assess any kind of process, in any company whatever their core business area. At the same time the IT Infrastructure Library (ITIL®) de facto standard was developing quickly in Europe. The combined use of both of these standards became Tudor's research objective, and the idea of a Tudor IT Process Assessment (TIPA) framework was born.

TIPA has been used extensively in Europe and is now making it's introduction into the U.S.

John Clipp
TechnoLava LLC

good service requires good process

I wouldn't presume to correct you :-D

And I was the confused one, sorry; yes i somehow segued from generic PAM to ITIL assessment. PHP coding fries my brains.

Wholeheartedly agree that process can be overdone and there isn't a fixed link with service capability. nevertheless this is funky modern thinking. ITIL V2 was all about process. letting go of process as the foundation is a big step for many organisations. I would also put it to you that "funky" = "immature", and abandoning process as a discipline is akin to many other post-modernist rejections of fundamentals (and common sense) that have ended in tears (or will).

I'm the first to say process needs to be done with restraint, and I point to my CoPr and SM4SME work to support that.

But I don't intend to throw the baby out with the bathwater. i'm old-fashioned enough to believe that good service requires good process at appropriate maturity levels and investment levels.

And that process maturity can be measured. i'm more interested in what is pragmatically useful in the trenches than what is idealogically correct or compliant with the theory du jour.

Define good

I don't propose to abandon process; I continue to see it as a vital capability. My concern is when process is taken in isolation, without context, without linkages to the greater goals of the organization.

The experiences of ITILv2 showed that maximizing the performance of processes is invariably confused with maximizing the performance of the overall organization. Optimizing each process independently, in general, will not lead to an increased optimization for the overall organization.

Worse, ignoring the interactions between processes more often impedes organizational goals (another factor frequently ignored by PAMs).

There have been many learnings over the last decade. My humble suggestion is this: we don't repeat the same mistakes. If this is post-modernism, then I am guilty.

what the post-modernists will d

I've always touted one of the benefits of ITIL V2 is that it actually defines the interations (and demarcations) between processes, but you are quite right: they are too often taken in isolation. We're on the same page (as usual). I guess my concern is not that you are being post-modernist but more what the post-modernists will do with these ideas. "process doesn't matter", "any approach has to be seen as valid", "it's not what you do, it is what the service feels like", "the service has to WANT to change" ...

The business manager in the office

Largly because of SOX the business manager in large organisations is often familiar with COBIT, whweas ITIl's penetration into boardrooms is probably less than some would like to think. I did come across one, relatively small, insurance company that had one manager tasked with implementing COBIT sat opposite one tasked with implementing ITIL.

There is an awful lot of meat on the COBIT bones, especially if you are a subscribing member of ISACA, and unlike the current version of ITIL there is rerltively little fat - though in both worlds I worry that there is a proliferation of "extra" guidance.

Interesting that the current issue of the ISACA Journal contains a large number of references to ITIL v3.

COBIT is wooing

COBIT is wooing. ITIL is playing hard to get.

I suspect Rob Stroud is one of those playing matchmaker.

Syndicate content