Policies, processes and procedures
I remember when I first migrated from a tech role to a service management role I found it hard to get my head round all of those documents beginning with the letter P, so here's a quick overview.
Policies #
These are the top level documents that say what you're supposed to do and how you're supposed to do it. It sets out the rules, for example: all changes to the live system will be handled in this way; any incident that affects this particular part of the business will also get this extra special treatment; all hardware items will be logged into the CMDB but don't worry about power supplies and cables etc etc. The policy will also make it clear why these rules exist (at a fundamental level it will be to protect the operation of the services) and what the consequences of not following them will be. They can be pretty serious, leading to disciplinary measures or termination (of your job that is). When someone steps out of line they're said to have had the book thrown at them. It's the book of policies that getting thrown.
Generally there will be one policy per discipline.
Processes #
Above I said that policies say what you're supposed to do and how you're supposed to do it. Generally this means "follow the processes". A process document identifies the teams involved and the steps to follow. Each step has an input, an action (usually taken by one particular team or person) and an output. Any process document will identify the conditions that trigger the invocation of a process (eg a change needs to be made) and what conditions need to be satisfied before the process can be said to have completed.
Processes should be generalised where possible but often there will be two or more process documents for any given policy. For example: your major incident process may differ enough from your standard incident process to warrant a separate document; the release management process for a continuous delivery stream will differ wildly from a COTS software upgrade.
Procedures #
These are the step by step instructions followed to ensure consistency and prevent errors from occurring along the way. They're usually quite detailed (e.g. enter this value into this box then click next; once this form has been signed by both managers, file it away in this draw etc etc).
There will of course be hundreds of procedures across any business: documented in Sharepoint; detailed in a wiki; or engrained in the mind of Bill from Ops who's being doing this for forty years now.
None of the abovve are written in stone. It's likely that policies and procedures have the proverbial dust blown off them for their annual review but really they should be continually scrutinised as part of your continual improvement activities. This extends all the way up to the policies. If a rule isn't working for one particular area of the IT team, change the rule or add an exception. All of these documents need to be fit for purpose and breakthroughs in improvement come from the people doing the work, not by the people writing the policies.
- Previous: Better is the enemy of good enough
- Next: Maintain your tickets
