Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.
NOTE: ® ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.
Search
Languages
Select Interface Language:
Advertising
Please contact us via the feedback page to discuss advertising rates.
The Itil Community Forum: Forums
ITIL :: View topic - Organisational structure for PM
Posted: Tue Oct 24, 2006 10:22 pm Post subject: Organisational structure for PM
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?
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.
Joined: Aug 11, 2006 Posts: 262 Location: Netherlands
Posted: Wed Oct 25, 2006 7:06 am Post subject:
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.
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!
Joined: Aug 11, 2006 Posts: 262 Location: Netherlands
Posted: Thu Oct 26, 2006 6:51 am Post subject:
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.
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.
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.
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.
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"
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum