Interesting idea for spreading the expertise - and the risk

In our mobile age it becomes very difficult for employers to build a base of expertise in the organisation. It leaks. You've no sooner paid for someone's ITIL Manager's (now Expert's) certificate and they are moving on. Pink Elephant has been talking about an interesting alternative approach: an expert team.

I can't say I'm entirely convinced yet, but when David Ratcliffe (Pink's President) first told me about the idea, I must admit I was intrigued. Recently he blogged on it (a blog worth following, BTW):

...organizations need to see real benefit from their education & training investments, and embarking on an ITIL Expert sponsorship just seems too risky to me. So how about we spread the risk out across the team?

Any large organization these days will have management responsibilities spread across a multi-person management team - so why not train them up to be a “Management Expert Team”? Same goes for a “Practitioner Expert Team”. You could have these teams in place and deliver ITSM improvements within weeks. The risk is reduced, and if the training is bulk purchased over a relatively short period of time any training provider will give you a good deal...

You'd think there would be other models in the industry that work this way, but right now I can't think of or find any.

If I hesitate to embrace the idea it is because I have trouble imagining the practicalities. How would it work where cross-displinary expertise is required? How do other people know who to go to? Would it not mean multiple people pulled onto projects as SME? Maybe I'm just being unimaginative. I'd love to see it tried.

What do you think? A creative way to accelerate the expertise and spread the risk, or just a new way for vendors to bring forward training revenue that would otherwise string out over several years?


Interesting assumption

There are likely to be advantages to training up a group of individuals within an organization that have a common understanding of a new set of processes.

The goal of most companies is to adopt ITIL "good practices" in a way that increase value for the organization and the company. An organization must be careful not to implement ITIL for ITIL's sake.

Warren Bennis reminds us that, “The manager asks how and when; the leader asks what and why.”

I would hope that these individuals would be empowered to engage in a discussion of the what and why with senior management instead of focusing too much on the when and how.

I therefore would be remiss if I didn't point out that the result of this would be rather like having a bunch of newly graduated accounting students assigned to set up the whole accounting and financial controls. Without more experienced supervision they may not achieve the hoped-for results. But, they might.

Cary King
Minerva Enterprises
Managing Partner


We are uplifting our internal processes with ITIL v3 using SCRUM. We have two projects running in parallel with one SCRUM master. Every two weeks we deliver finished processes implemented within BMC ITSM 7 and demo them to our stakeholder team. In addition we deliver finished CMDB content (service models, and IT asset discovery) aligned with the ITSM processes. During the demo we take feedback on our process implemention. The feadback may result in software tweaks to gain operational effeciency, or it may result in organizational change management work to align processes or existing team functions.

The results of the demo are fed back into the product backlog. The product backlog is priortized every two weeks with our product owner (Director responsbile for IT SM) and we then spin off another two week cycle to implement a new set of processes or software customizations.

The two teams are staffed with cross functional experts.

CMDB: Staffed with network, monitoring, technical architects (cross functional system owners), and Disaster Recovery / BCP representatives.
ITSM: Staffed with cross functional team representing Service Desk, Release Mangement, Change Mangement, Problem Management, Operations, DR/BCP, and Remedy Systems Experts.

So far we are making excellent progress. The agile approach has allowed us to adapt when we learn about new requriements or see new oportunities for process or organizational improvment.

Spreading the Risk


Prior to ITIL Version 3, this option did not exist as the training programs between Foundation and Service manager were limited along with the fact that ITIL version 2 was missing quite a few of the pieces to plan, design, implement, operate and to optimize an ITSM program.

What you describe above is what itSM Solutions LLC launched over a year ago ( is teach organizations how to Do IT Themselves (using multiple training methods - classroom, virtual classroom and self-study online) with the support of an experienced ITIL/ITSM Expert mentors....We actually created a newsletter around it (

This whole approach is the same way coaches and military ( leaders get their team ready to play a game or fight a war...everyone understands their roles and responsibilities and when they make a mistake the coaches get them back on track.

The coaches/mentors are the glue that holds its all together...whereas the Practitioners are the one who excute the plan or plays.

What's really funny is how organizations that for many years were focused on keeping the client in the dark (so they could sell more consulting) are now realizing (probably because of the economy) that they need to come up with a new way of doing things to get their revenues back on track. BTW the training needs to go beyond certification (although this is the first step in the training process...learning the what to do first...then the how to do it via hands-on workshops)

Shared responsibilities

Hi Skeptic,

This area is particularly interesting as we are are facing the exactly same situation in product management organization. We used to following problems couple years ago in our R&D team:
1) Each developer was responsible of major improvements to the software with no proper support from colleagues
2) We aimed to release in 9 months and usually the release was delayed for another 3 months resulting in one release per year.
3) When release date came closer, we had to work longer days and developers were having a lot of stress
4) We had quality issues in the releases
5) When we finally released, the current need was already something else than we had accomplished
6) Knowledge was concentrated on single developers resulting in high risk if someone got sick etc.

At this point we had been looking at agile development practises and bumped into Scrum (awful name, I know). I'll skip the details but in one year we got to a point where we were able to work as a team on same development themes, we were able to implement a lot more features than before, we were able to release on time and adjust release goals during development if needed.

We are now able to release every two weeks into production internally.

Now we are applying the same principles in product management. Product managers are responsible for their own products, but the whole product management team will be involved when new products and improvements are being implemented. This will allow us to share know-how, reduce risks related to product management expertise and shorten the time that it takes to get most important things done.

I know that shared expertise works, but it takes a lot of commitment and discipline to implement processes and working habits that enable organizations to work in this manner.

Problematic things are true specialists whose competence is difficult to match. This problem can be solved over time by training and having people work on same things with those specialists sharing their expertise.


I'm a New Zealander. "Scrum" is a beautiful name, lilting, almost poetic.

thankyou for such a useful post - I'm off to learn about it

Syndicate content