Why is Project Management almost invisible in ITIL V3?

This post has been podcast

Why is Project Management all but invisible in ITIL V3?

PM is the engine that moves much stuff (hopefully just about everything) from Development to Production, which is pretty important now that ITIL has muscled into Application Management. PM should interlock with Change Management and Testing. PM should provide most of the Early Life Support. Release and Deployment shouldn't move without PM: if it is big enough to be a release it should be a project. And so on.

So why is it no-one tells you how ITIL aligns with the Project Management bodies of knowledge PMBOK or PRINCE2.

Service Operation gives Project Management two paragraphs (p165), and not as part of Application Management.

Service Transition gives Project Management passing mention on pages 40 and 62 and 200, and page 180 of Service Transition that explains how important it is NOT to ignore it!! To be fair, it also explains how PM is something done by those people over there, not IT Services (and hence out of scope). Service Transition also duplicates all of PMs functions in the Service Transition plan (p40).

Service Design spends time on it (p31-32) but only vague directions to keep the project honest, not details of how the interface might work between Service Design and Project Management, and never once mentioning PMBOK or PRINCE2. The diagram on p31 is just wrong. It shows the project team's job is done at the start of the pilot or warranty period. This is "dead cat syndrome" which must be avoided at all costs. A project team should retain ownership through the warranty period until acceptance has been signed off.

The Official Introduction gives a cursory nod to assorted BOKs in the Complementary Guidance section.

What happened to Project Management when ITIL V3 was put together? Did someone get bitten by a project manager? Have the PRINCE2 people got all the good carparks at OGC and everyone hates them?


It's in Complementary Guidance for a reason?

Yeah sure there isn’t much mention of Prince2 in the v3 books and I would need to be honest from a marketing perspective one would think it would be everywhere. I would say due to Prince 2 being a British framework the Americans have not promoted it as much as it could have been. It has a little more mention than CobiT and Six Sigma etc, but it appears to be referred to on about the same level.

ITIL is an extremely project driven framework with as mentioned before Change Management, Release Management est., having a strong requirement for project methodologies for them to be successful. Although my knowledge of Project Management at this stage is not entirely strong I cant make comment regarding the diagram in Service Design page 31 being incorrect. Perhaps as mentioned in IT Skeptics article regarding the scale of ITIL V3 link: http://www.itskeptic.org/node/533 (Not sure how to do the fancy links you guys do ) the diagram is a flat diagram and may be oversimplified. The IT Skeptic quoted the following in regard to a diagram illustrating the growth of v3 over v2. “Please forgive the fact that in any flat diagram there will be some over-simplifications or even distortions.”

I believe however that ITIL is and always will be focused around processes and functions. As with any good framework ITIL provides a lot of additional information to ensure the effectiveness of these processes. Perhaps there could have been more mention of the Prince 2 framework, but is there not a chance they would start getting side tracked from the point (which is how to enhance IT services for the business, although yes I know an argument to this could be Project Management also focuses on this). Project Management is and always will be a separate profession. You can’t be master of all trades, although if you are a Service Manager you could have a methodology like Prince 2 in your Service Management tool belt. Is it not a case of ITIL pointing out the basic way (my assumption) in which it would make use of a project methodology. Then leave the Project Managers to fill in the grey areas. Surely if you are a well seasoned PM you would be able to understand what ITIL is requiring and fill in the blank spaces.

Therefore ITIL makes mention of Prince 2 Specifically in the complementary guidance section in the appendix of CSI. I also feel my point is made valid by the following text in the Service Transition book in Change Management on page 54 under table 4.5 "The focus should be on identifying the factors that may disrupt the business, impede the delivery of service warranties or impact corporate objectives and policies. The same disciplines used for corporate risk management or in project management can be adopted and adapted." Now this statement I know is pulled out of context but I still feel it makes a relative point that the general focus of the framework is to present the processes and how they function (in a nut shell), and to complete this package Project Management should be employed, for your convenience they offer Prince 2 as a complimentary guidance for you to pursue to enable you to fill in the grey areas of the framework. ITIL is one tool in the Service Managers tool belt.

I would like to hear your comments on my reply.

Tat for tat

Perhaps it is because service manager are invisible to project managers?

service delivery visibility on projects

Yes, Service Delivery needs to kick down a few doors and make themselves visible to projects.

We aslo need to greatly reduce the Service Diameter of the Service Porthole (as Real ITSM puts it) and stop accepting dead and mangy cats from projects. I propose holding up implementation of a project due to failure of production readiness. Whether you ultimately win or lose the fight does not matter. PMs like a smooth ride and SD will then be very visible on subsequent projects :D

Whose fight is it?

In a straight fight between SD or Ops and the project SD tends to lose. Where I've had most success turning this around is by getting senior customers to realise the responsibility lies with them - but you don't achieve that if you only raise concerns at the last minute

Kick the doors down early

Agreed. Kick the doors down early in the lifecycle of projects - get in there communicating.

After you try playing nicely, then when that doesn't work make a big fuss about a dead cat coming over the wall. Make it really painful for the project to go live - doesn't matter if you lose. The other PMs will want to know how to avoid the same pain.

Not sure that senior customers should have to (or will want to) resolve internal IT turf wars

Is it internal to IT?

Often the conflict is that business area A's major release going into production is going to degrade business area B's service, or delay area C's vital maintenance release. Lots of organisations are good at prioritising between projects, but not at prioritising the mix of projects and BAU activity.

And of course if there is an SLA to be signed off, or a customer facing contract then the business have to be involved

A release shouldn't be a project

The release management process should handle releases in a BAU/standard operation manner. If a project it required it is usually because the release management process is lacking. IT projects are there to handle very big unique changes - data center moves, introduction of new technology, systems and processes, etc.
The big challenge for many projects is trying to deliver something of quality into an organisation that lacks standards and processes to manage their services. Many projects neglect the vital role of service development within their plans but even if this is there it is really difficult to achieve smooth transition if the service requirements are overly complex due to a chaotic operations organisation. The role of Service Transition in ITIL v3.0 looks to address this with the introduction of an organisation that supports the transition from project to operations. However these guys will have the same problem that projects have had if the organisation they are transitioning into has poor standards and processes.

If the runway is bumpy don’t expect a smooth landing!!

some context to this post

Fair points Richard, so I think I should give some context to this post. There are a number of strongly established bodies of knowldege that ITIL bumps up against. COBIT especially and the Johnny-come-lately ISO20000, but also ASL, PMBOK, PRINCE2, CMMI, SPICE and several others. I think a big piece of work missed in ITIL V3 was working out the mapping, interfaces and role delineations between the BOKs and ITIL. It is a fair question. ITIL does a superb job of defining how its own processes interafce: how incident and problem management work together or change and release. Why not change and project to the same level of detail? Or availability and project? it was in the too hard basket I suspect. "Not if we are ever going to get these books out". But the people associated with those BOKs are in general busting to help integrate with ITIL. And it would have made implementation of ITIL a hundred times easier to have a little plug-and-play with other BOKs in the environment.
The fact that PRINCE2 got snubbed is one thing, but a Yank-heavy team doesn't explain it really, despite my cheap shot at the start, because PMBOK sufffered just about as rough treatment too.
In fact the whole domain of PM got short shrift. Along with Risk and perhaps one or two others, I think it is a reasonable expectation that project management would have got more attention, and more detail about how it interfaces with ITIL (not how to do it).

BTW, the fault in the diagram mentioned is not a distortion due to flattening. the big fat arrow labelled "Project (Project Team)" stops one phase too short. It is old entrenched thinking that Operations has to pick up the baby at the start of a pilot and clean up any messes it makes going towards production.

Why do you say it was

Why do you say it was "Yank-heavy"?

The authors/architect I met were nationals from the UK (5), South Africa (1), India (1), Canada (2), as well as the US (2). The mentors and reviewers were even much more geographically distributed.

I'd say the balance had shifted trans-Atlantic

I'd count David Cannon and Majid Iqbal as honorary Americans. So I'm counting six out of 11 authors from North America including the Chief Architect. (and David Wheeldon works for HP so some would count that as another half). Given the mix that wrote ITIL 1 and 2, I'd say the balance had shifted trans-Atlantic.

South Africa

Wow, didnt know anyone was an author from South Africa. Who was it?


Mr. David Cannon is South African if accent is any indicator. Though I believe he does spends most of his time in the US. Mr. Majid Iqbal, on the other hand, is known to correct those who mistakenly call him American.

I suspect Mr. David Wheeldon (who I believe resides in Spain) would be quite bemused to be labeled a Yank. :-)

national origins and current political alignment

Let us not confuse national origins with current political alignment. David Cannon has been resident in the USA for a long time and works for HP. Majid Iqbal was at Carnegie Mellon, on of the great bastions of the American empire, and is now at Gartner. I am a Kiwi but for years I worked in Australia and represented Australian interests within my employer. I didn't like being called an Aussie any more than David(s) or Majid like being called a Yank but I wasn't there representing NZ.

"Its my Cupcake!" "No I baked it its MINE!"

Very interesting. Our accents are certainly strong :-). Although very often mistaken for Australian in Europe and several other places.

Ultimately it is well known ITIL "originates" from the UK, but let’s not forget ITIL did not re-invent the wheel in many of its processes and content. For example Dr Edward Deming, who was born in Sioux City, Iowa, USA, regarded as the Quality guru in the USA and responsible for the Japanese post war industrial revival, has a very strong presence in Continual Service Improvement (e.g. The PDCA (Plan, Do, Check, Act) model otherwise referred to as the Deming model). The "Yanks" have had a very strong presence through out all versions of ITIL as they have been the leader in many ways for the worlds industries. Yes I give my full acknowledgement to the OGC and UK for putting the books together and I most certainly am not implying they "copied" everyone else’s ideas as that would just be silly. I also acknowledge the UK for its original content of the ITIL framework and its many influences it has had on world industries as well. I would heed warning in making comments regarding "who wrote the book" as this I feel is going to become a dispute in the future. Making comments like this will ignite these disputes. This dispute is not only extremely unprofessional, completely out of the scope of ITIL, but this will throttle the growth of the framework in the future. The Americans need to be involved in writing "The Book's" as does the rest of the world. The point I’m trying to make is a framework or any other complex methodology will be far more fruitful if many cultures and experiences are mixed into it. This will allow the framework to be far more versatile and effective. Let’s not generalize here, as there are many strong positive elements from each nation, as well as negative. Pay respect where it’s due.

Does it really have a negative impact on the framework? I don’t think so.

the "ownership" of ITIL

We've discussed the relative influence of the various contributors already on the blog. From those who were there in ITIL V1 it seems it was indeed international, but with a strong input from the UK and Europe. Where the origins of the ideas was is anyone's guess.

It is generally felt that there was a certain element of the "Not invented here" syndrome around the slow adoption of ITIL in the USA, and only the championing by HP (and Microsoft's pushing MOF perhaps) that changed that. So the throttling happened in the past due to America's own xenophobia and we are past that.

It is inevitable that ITIL get dominated (or else pushed aside) by the biggest and most aggressive economy on earth. It is happening in certification and training despite APMG - a British company - retaining control. But that should happen in a controlled manner, with the consent of the rest of us, and without losing the international flavour (spelt with a "u"). There is nothing unprofessional about keeping an eye on the power politics of ITIL to ensure it does not become captive to vested interests. Somebody has to do it, and OGC and itSMF and APMG don't.

I am delighted to see other cultures contributing at at an international level, in books and in itSMFI. I wish there were more. I think some countries pull above their weight. I'd expect to see more participation from other European and Asian countries. India is showing rising interest and activity. I expect China to loom large in a few decades just like it did in manufacturing. China is the sleeper.

Right now ITIL is still the property of Her Majesty Queen Elizabeth II.


ahhh, I see what you were referring to, I will make note of this.

Syndicate content