Organisational structure for PM

[Burki]

Hi everybody!

This is my first post and I hope an interesting question for all of you:
HOW DO I STRUCTURE FOR ITIL?

In our organisation, there is no structured approach to Problem Management. However, I think that Incident Management is quite far developed. We have 6 teams of four people, each supporting 60 customers (we are offering application service providing). The team knows its customers and users quite well, but there's no centralized instance that has an overview over all customers. Support staff is doing IM, no one is responsible for PM.

Now my question is, how do I structure for PM?
Does assigning 80% of the time of support staff to IM, 20% to PM work? Or should I create another function?
Does anybody have the same experiences?

Thanks in advance!

Burki

[Ziad]

In most of the practical situations I see that Incident Management and Problem Management are handled by the same team, probably for better resources utilization and for avoiding the cost of recruiting more staff to handle one of the processes by itself.

Nevertheless, since Incident Management and Problem Management have conflicts within their targets, it's better to assign them to separate teams. The first aims to restore services AS SOON AS POSSIBLE while the second is NOT TIME BOUND and works on solving the errors within the infrastructure.

Regards,
Z!

[m_croon]

Hi Z!

I beg to differ
Fitting a proces such as IM or PRM in a team, is like ... well I don't know what it's like, but it feels tight and I don't like it. You'll end up with an unnecesary spread of knowledge, and one team that will only be chop the tree, and not having the time to sharpen the ax, and another team knowing precisely how to sharpen an ax, but not knowing what to do with it. I agree that there is a natural tension between IM and PRM, but on the other hand they need each other!

Burki,

I think there is nothing wrong with reserving a percentage of FTE/hours for problem management. Youll need strong commitment from management to keep it up though. Maybe you can combine it with the following:
1. Based on a uniform categorizing of incidents (along all teams/customers), start reporting from incident management. Very short and weekly report on workload (new/closed per week, open per team) and top 10-category and top 10-oldest incidents. Use this to create awareness for structural solutions.
2. Give every team a target for # of new problems per month. Either a fixed amount or depending on # of incidents. Start reporting on this target straight away. Use this to enforce a constant flow of problems, that will cause a decrease of incidents.
3. Consider to send problem reports to customers. Do this to create an allie: no better way to enforce problem management than a customer who wants a problem (structurally) solved.

Hope this helps, cheers,

Michiel

[Burki]

Hi Z!, hi Michiel,

thanks for your replies!
Michiel, I guess you are totally right about that axe thing. Every team is fighting its own fires, without analyzing if the same kind of fire has been fought before in an other team. So people are doing the same thing in different locations, which is not very efficient.

The underlying reasons for this behavior are that
1. There is no awareness of PM
2. No awareness, that it's important to document solutions in a way that other admins can follow it (aspect of knowledge management)
3. Searches in the database are too slow
4. Categorization is poor
5. People are stuck in IM
and so on.

Reports are being created, but management/people don't act upon them.
I guess creating 2 or 3 basic but important reports and making sure that people act upon them is a good way to start.

If anybody else has some insights about handling PM with a team structure like the one in my company, I'd be happy to hear your opinion!

BR,
Burki

[m_croon]

Hi Burki,

I hear you say two very important things:
1. No awareness re. PrM
2. No commitment by management

So basicly what you have to do, is to establish a change within your organisation (company culture, "the way we do things" etc.).

May I suggest you have a look at John P Kotter's 8 steps for sucesfull changes. Kotter is from Harvard and has based his steps on research in many organisations. It has nothing to do with problem management as such, is easy to read, yet we all do it wrong all the time.

Also, search for info on "Analytical Trouble Shooting" from Kepner & Tregoe. This goes on with problem management where ITIL stops. ITIL problem management "only" tells you that you ought to do things, and ATS tells you how to do it.

Cheers,

Michiel

[fighter]

Burki,

Why not try doing this..

you have 6 Teams with 4 team members. If you dedicate 80-20 raito of your work force it will conflict with the interest as Ziad had mentioned.

How about 1 member from each team dedicated to deal with Problem Management. The rest 3 can perform day to day operations. 1 member can take care of the reports, analysis for proactive problem management, and reactive problem mangement as well.

Hope this helps!

Vimzie!

[Burki]

Hi Vimzie,

your approach seems quite simple, and maybe it could work.
The problem is, that skills are not distributed equally about the teams.
So in one team there are 2-3 very skilled people, while in the other there's only 1 smart "problem solver".
I guess we have to find a way to make it somehow dynamic:
1. Identify people with problem solving skills and expert knowledge in their field (Exchange, Citrix, printer, ...).
2. Define where IM ends and PM starts
3. Assign the problem to the appropriate Problem Solver, no matter what team he is in.
4. People with problem solving skills must have TIME for problem solving. In that time they have to be free of IM responsibilities.

What do you think?

BR,
Burki

[fighter]

Burki,

Your solution is fine. But look in terms of this.. you have a specialist for each of the service.. but now what happens if the specialist is not available due to holiday or sickness... you dont have a cover..

Try distributing your staff skills with each other

Have a primary and secondary for each of the service which you mentioned. Get the specialist to train their secondary as well..

This is like a person can be primary for email but also secondary to citrix..

This way you would make sure you will have a backup at all time.

The rest of your ideas seem just perfect for your scenario.

Let me know how you proceed.

Cheers

Vimzie!!

[winz]

Hi Burki,

We are in the stage of forming the PM team too.

And, I second the thought given by Vimzie. However, maybe your organization doesnt fucntion in the same way.

For the success of Problem Management, the following things are really important:
1) The problem support team should be technically very strong as they could be the last resource for doing the investigation & diagnosis / RCA
2) Decide upon the KEDB
3) Define the OLA's between teh easy and smooth functioning of the IM and PM team members
4) Make sure the members in the Problem Management team cover all the support areas. If they are weak in some areas, the necessary training should be given to them.
5) Ideally the Problem support team members should not be working on the Incident Tickets at all.
6) Try to groom the problem support team towards effective Proactive PM.

Initially you might have some issues, but once the core PM team is formed the people will realise the true value.

Hope this helps. My apologies if I have missed any points in here.

Cheers
winz
_________________
"Look at Frustration as a positive thing. It is the frustration that drives you to improve"