Two ITIL-derived rules of thumb for organising the IT department

Someone asked on LinkedIn about what guidance ITIL gives us for restructuring an IT department. I came up with two rules of thumb:

You can organise in any way and do ITIL. ITIL roles are hats that people wear (part or full time), not job descriptions. ITIL processes are just that, processes that cut across organisational units - you don't need to organise around them and it is not always a good idea.

The only ITIL-ish rules of thumb I would offer are

1) separate front and back office.
Front office activities are the user- and customer-facing ones. they include demand, catalogue, Service Desk, incident, request, SLM, account/CRM, availability (yes! all about planning for future service levels and new services)...
Back office functions are the inward-facing IT ones. they include problem, IT change (yes! I'll argue that one), application, testing, release, event, operations, technical, capacity, continuity, financial...

2) separate management from operations.
I think change, service level reporting and maybe others like financial are management functions (some would say "governance" but I don't like using that word in this low-level context) that should not be answerable to the managers they are controlling and measuring, such as IT operations or service desk.

Comments

broken thumb

Organizational structure is a mystical religion. In my experience, mostly irrelevant to performance of an organization. Leadership, management, role definition, accountability etc.. are the determining factors of success.

You could easily argue separation of front and back office, or separation by technical competency (desktop vs server vs etc..) is the most efficient method. You could argue separation of management from operations gives management little or no ability to affect operational change quickly in response to service issues etc..

Organizational design is another thing that is best (IMHO) developed top down based on the strategy of the IT organization. The logical grouping of functions under a single structure is mostly to create greater informal working structures and responsiveness which should respond to goals of the IT organization. It also considers the capabilities of management and skillsets of the people in the organization to determine the scope and responsibility of each group/division.

I'll throw in a whizzer and see if anyone bites. ITIL or Service Management execution is not a goal or strategy of an organization or an IT organization. Its a cost of doing business not a value add (ie. something that creates revenue, marketshare, etc..) . You should be doing it at a level appropriate to your needs. Therefore you should not design your IT organization around Service Management. You design your processes, accountability, roles etc.. and not structure.

$0.02

B

Don't forget RACI

I agree with what you've said. However, I would add that ITIL IS specific about clear understanding regarding a couple of things:

Before undertaking and ITIL adoption effort, be sure certain roles are filled (which ones depends on where the organization starts).

ITIL also says that reporting, accountability, etc., also have to be clearly defined (aka RACI). Chapter 6 in the CSI volume provides excellent guidance in this area (while it's about CSI it has broader applicability -- there's also good material about organizing in the other books).

David

COBIT gives RACI. ITIL will just give you platitudes

of course if you actually want useful RACIs without having to invent your own, don't look in ITIL. Look in COBIT which has clear RACI charts for every process. ITIL will just give you platitudes about how important they are

Syndicate content