Who is your process council?

[sherman_1206]

Last time, I introduced myself with a declaration to post useful information for the Higher Education community. To get started I want to take the bird's eye view of ITSM Process Councils. The who, what, where, when, and why of the process council.

What is this council you speak of? A process council facilitates design and improvement of ITSM. Each of the core ITSM processes (Incident, Change, Problem, Request, Knowledge) are delegated to an owner. This comprises the council.



Who are members of this council? An organization's Process Council includes each process owner. Additionally, when in context the developers should be included to discuss the technical limitations. These individuals provide parental guidance to an ITSM process and its development.

Incident Manager is the captain steering the S.S. Incident Management, Problem manager is in the corner of the ring rooting Problem Management onto root cause analysis victory, Change Manager provides traffic control for the changes on the runway ready to take off. These are the business stakeholders who have a vested interest in the success of ITSM.

Additionally, when relevant, part of your core development team should be included. Developers should not be the focus of these discussions generally speaking, they are there in the background to provide context and discuss architecture and constraint.

So why the heck do we need one? Process cohesion and dependency is the simplest answer. Each of your processes can run independently and process collision is guaranteed to ensue. There has to be a better way! The process council is your answer. An unique opportunity is presented by regularly convening your council. The ability to develop the connections of processes. Technology is always changing and thus organizations have to remain agile and expect change. Therefore, incident and problem management can benefit from tying into change management. Root cause analysis is a heck of a lot easier if you knew last week operations took down the entire lan for example.

The idea is that each process should be aware of the others enabling process continuity and coherency.

Where does this council meet? Where is not as important as the others but can set the tone of the meeting. If everybody has to drive halfway across town (OSU is a large campus) to meet, attendance and interest will surely suffer. Meetings should never be a chore; they should be desirable. What is more desirable then enhancing your IT Service management? The first step you can take is to regularly assemble your council and stakeholders. Let the discussions commence!

When is extremely important. Too many meetings will result in declining attendance, too few and focus will broaden. Too broad a focus and the meeting will lose scope of its original purpose. Thus when needs to be fine tuned over time to remain on topic and discuss relevant items. (Everybody wants a CMDB, does your Change manager need to emphasize this everytime the council meets? Probably not. Everybody wants to do root cause analysis, does that mean your Problem manager should harp on the drum some more?) Focus is critical and to keep in focus the when must be catered to your own IT Service management needs and current developmental efforts.

To wrap this up, ITSM in your organization can benefit from regular meetings. Without regular discussion each process can become siloed. The group should consist of all those in proximity of the topic being discussed. Remember the five W's of your Process Council and the next time you summon this group expect ITSM enhancement and progression. Lastly remember that your ITSM processes are supposed to go through continual improvement. To perform CSI your council has to meet.

Thanks for reading, next on my agenda is discussing identification of your user base and their needs versus wants.

Feel free to comment if you have any questions or concerns.