Reality requires prompt and effective procedures and work instructions development for IT teams that usually comes from processes gap identified by audit or problem resolution activities.

Let’s agree on the following definitions in order to have structural approach in process formalization: Process – sequenced activities that can be considered as governance or management ITIL-like process, e.g. Asset Management or activities that aimed to support the IT service, e.g. Messaging Application Support; Procedure – defines process in terms of inputs/outputs, flow and validation; Work Instruction – document that describes the activities of the process in detail. Some procedures can refer to one or more Work Instructions depending on its complexity.

Procedure

Procedure consists of the following paragraphs:

• Scope – High level description of the Process and its boundaries.
• Process Trigger – Ways of the Process initiation. The Trigger can be any request like business, demand or project one, or any output of the process like Incident, Problem or Capacity management.
• Process Outputs/Deliverables – This paragraph describes the Process outputs and/or the outputs receivers that can be, for example, another IT process.
• Roles and Responsibilities – Roles involved in the process and their responsibilities. It is easier to write the responsibilities after Process Model and Process Phases finalization.
• Process Model – The graphical high-level representation of phases/activities of the process that help to view the “big picture” of the process, hence optional. The model can be depicted with Cross-Functional Diagram in MS Visio or any other similar tool. Each phase or activity in the Model should have unique identifier.
• Process Phases/Activities – Description of the phases, activities or group of activities in the Project. Use table with Identifier, Phase/Activity and Description columns where each identifier and Phase/Activity shall be represented in the Process Model.
• Systems and Tools – Applications, equipment, files etc. used by the Roles within the Process. Common tools are Request Management or ITSM, CMDB, Administration/Monitoring or Logging tools. This paragraph can be skipped, if the Tool that is used is clearly defined in another part of the document, e.g. in Scope paragraph.
• KPIs – Key Performance Indicators used to control the performance of the Process. Each KPI usually has Title, Description, Formula, Ranges (e.g. Excellent, Good, Fair, Poor), and Period of Measurement. Another approach is to list the answers for the questions: who, what, when, how, where. There are plenty of good article regarding KPI development, for example: https://www.cio.com/article/2955777/best-practices/12-critical-metrics-for-it-success.html, http://dev2ops.org/2010/01/how-to-measure-the-impact-of-it-operations-on-your-business-part-2/
• Controls – Company-wide approved process measures to ensure that the Process objectives are met; Controls are usually based on COBIT and/or ISO standards. This paragraph can be omitted if there is no any control for this process or company doesn’t’ use controls at all.
• Reports – Periodical distribution of the Process status, usually based on KPIs and Controls to the Management. This paragraph should clarify what to include in report, who has to create it, who has to receive the report and when the report has to be created. If the report can be created automatically, the role responsible for report creation can be omitted.
• Process Assessment and Review – Process improvement initiatives usually performed annually.

Work Instruction

Work Instruction can have following structure:

• Scope – High-level introductory description of the activities of the Work Instruction.
• Inputs -Detailed description of the Process Trigger related to the described activities.
• Tools – This paragraph can be skipped, if tools were described in the related Procedure or in Scope paragraph.
• Activities– Sequential detailed description of the activities. It is good practice to support each activity with the screenshots and photos for clarity.
• Success Completion Criteria/Validation Testing/Outputs – The activity or evidence that can justify the successful completion of the Process. E.g. Ticket closed, Check was done; Validated via Monitoring activity (see par. xxx).

There also can be more paragraphs depending on Company Document Management Process, Governance or other requirements. The proposed structure can help to develop IT process documents quickly and with minimal sufficient detail.