COBIT, ITIL, and other IT Service Management frameworks assume the readers have a good understanding of "process." In practice, writing procedures and evaluating procedures are an important part of process improvement.
Processes have common characteristics, be they the "freshmen orientation" process or the "change management" process:
The book Business Process Change, by Paul Harmon, also explains how processes can be at various levels of granularity. For example, one component of the "freshmen orientation" process might be "tour the campus" which in itself could be another process. Harmon suggests a set of terms for this hierarchy of processes:
For example, a "Service Level Agreement process" might itself be a component of an overall "Service Design process."
A glossary will help codify your organization's jargon. Please make sure you have a clear, authoritative source before building a glossary.
Process documentation requires using jargon. Most process templates include a section for "definitions." Definitions should be included here, so the process can be considered a complete reference text. However, definitions should also be included in a central glossary, to ensure terms are used consistently throughout the organization. This glossary can also be a training guide for new staff.
When adding terms to a glossary, consider:
Also consider whether it might be appropriate to have some form of change management over the glossary, and how to publicize the glossary to your department.
Departments tend to use the same words to mean different things, even inside the same University. Even if the IT department starts using words like "customer" and "user" consistently, that doesn't mean that anyone else at the University will understand.
There needs to be an owner for the glossary, someone such as a technical writer. There need to be "watchers" who notify the glossary owner when they hear a new term.
The Software Engineering Institute at Carnegie Mellon created a standard in the mid-90s called the "Capability Maturity Model." This model could "rank" an organization's software development lifecycle from one to five based on its process maturity.
CMMI, successor to CMM, uses these five maturity levels:
COBIT, giving credit to CMM, uses these six maturity levels:
(The text summaries describing each maturity level are not from the sources; they are summaries for the reader's benefit.)
Process assessments will often use maturity models like these to help quantify how an organization is performing.
RACI matrices are sometimes called "ARCI" matrices.
A "RACI" matrix is a chart of "who does what." RACI stands for
In terms of a process, a RACI matrix illustrates who does what step in a process:
| Activity | CIO | Service Desk Manager | Change Manager | Problem Manager |
|---|---|---|---|---|
| Schedule changes | - | C | A/R | C |
| Handle incidents | - | A/R | - | I |
You can see from this chart (which isn't necessarily how you should set things up in real life!) that the CIO role does not need to be informed about any of these tasks, the incident manager is consulted on scheduling changes and accountable/responsible for handling incidents, the change manager is accountable/responsible for scheduling changes and not informed about handling incidents, and the problem manager is consulted for scheduling changes and informed about incidents.
One issue with RACI matrices is understanding the perspective of the person reading the matrix. Perhaps a University president would hold the CIO accountable for all tasks. The CIO would in turn hold others accountable, and so on.
People sometimes play many roles in a University IT environment. RACI matrices can become very complex without an accompanying "roles list" that defines the various roles in a department. Through defining roles, people can understand their obligations without using actual job titles.
Before you begin, you will need some form of change management, so that procedures can be ratified. Stakeholders need to agree on how procedures are approved.
Also, consider creating a "procedure procedure" that defines how procedures are created, modified, and removed. For example you may wish to have a step where procedures are reviewed for style, before they are approved.
ITSM best practices are predicated around written processes. These written procedures allow IT departments to have a standard, defined method of performing tasks. However, when it comes to the actual act of writing procedures, there's not much material available.
Another challenge in procedure writing is that there are various levels of processes and procedure granularity. A higher-level, "value chain" view of a department can be decomposed into several processes and sub-processes.
Wake Forest University's Information Systems department has created a procedure template that we use internally. Several versions of this template are attached below; "FV2" is the latest version. Please feel free to modify and use this template as needed when writing procedures.
If the people writing a procedure are not going to maintain the procedure over time, the procedure authors should take care to fill out the template's "procedure owner" section. There should be a clear hand-off of the procedure to its operational owner after the procedure is ratified.
ITIL v3's Service Design book has an appendix that briefly states some recommended sections for documented processes and procedures.
| Attachment | Size |
|---|---|
| TEMPLATE Procedure 2008-06-30.doc | 60.5 KB |
| TEMPLATE Procedure FV2.doc | 63.5 KB |