Vihreä Ruusu - Process Capacity Planning – Do Not Exceed Your Capabilities

Vihreä Ruusu

Service Governance	Service Level	Processes and Practices
Mode of Operation	Vendor Relations	Availability

Suomeksi

Matti Grönroos CV

Matti Grönroos

Process Capacity Planning – Do Not Exceed Your Capabilities

If a perfectionist, a keen process planner, and a junior designer recently passed his/her ITIL Foundation exam are put together to plan for corporate processes, the result usually is a disaster. The result is either overwhelming or nothing. Nothing because the perfectionist never gets anything complete.

A pretty common approach is to cover all walls with large, complex, and fancy process charts. Often, the most important principle is ignored: Create such processes only, which you have resources to run.

Simple math is usually enough to make the initial estimation: multiplication and division, nothing more.

Blindly reading the ITIL book and without thinking, it is easy to end up with processes which simply do not work.

A part of a real discussion:

— From now on, there shall be a problem management for each incident.
— Really? Have you estimated the average workload per case?
— About four hours?
— And the number of tickets per annum is?
— About 300,000.
— So 1.2 million hours total per year. There are about 1600 working hours annually. So, you propose we hire 750 persons to do problem management?
— Well, no...

The resource demand of the processes (both in terms of schedule and in terms of personnel) can be fairly easily roughly estimated by multiplying the number of cases by the time it takes to handle one case. This can then be optimized in several different ways, such as

by limiting the number of cases
by shortening the turnaround time of one case
by reducing the wasted time between process steps
by arranging tasks to be performed parallel

Let us discuss the problem management case above. The idea that for every incident there shall be a formal problem management case is incorrect. The approach might lead to better quality, but quite a simple calculation reveals a bad business case. As we a familiar to live in an incomplete world, we can pretty easily tolerate most incidents by just being happy with the resolution. For most cases, the root cause is evident, and does not need a formal and expensive analysis. The most severe incidents may be subject to problem management, in case there is a valid business case.

In our example, it was decided to filter 98 out of 100 Tickets and send the remaining two only to Problem Management. This ratio can be close to what you often end up with. Filtering can be done by setting a ceiling on human resources, the number of tickets to be further processed, problem management total cost, etc.

It is essential to assess the current processes and mode of operation now and then if they still are reasonable. For example, it may be a fully acceptable way of working to review every incident at the vendor meetings, if the number of tickets is minimal. However, if there are hundreds or thousands of tickets per month, such a procedure is beyond any common sense.

It is true that IT is a complex world, and everything affects everything. However, that is not a good reason to build utterly complex or overwhelming processes. The end-users tend to find ways to bypass such processes. The worst case is the birth of Shadow IT, which is easier to reach than the official one. The complex rat's nest class processes are impossible to measure. Therefore, there is no way to even assess if they create value or not.