Documenting Policy and Procedures

Image credit: rawpixel on Freepik

The article ‘‘Understanding Governance Documents’ provided a framework and hierarchy of commonly used governance documents and the article ‘Developing Effective Process & Procedures’ dealt in detail about the process to be followed if the Process and Procedures developed are to be effective. In these articles we have seen that for achieving consistency, standardisation, business continuity, meeting the requirements of certification standards and various other reasons, it is important to document the Governance Documents. Two of the documents that are invariably found in most organisations, irrespective of their size and nature of business are Policy, and Procedures. This article deals with documenting Policy, and Procedures . Documented governance greatly enhances the ‘Effectiveness at Workplace’.

Although the primary focus of this article is Policy, and Procedures, most of the information and concepts contained here are generic that can be applied to other documents as well. For documents other than policy and procedures, use only the relevant sections discussed in this article. The process flow diagram for example is applicable only for the procedures and not for documents such as Policy, Mandate, Guidelines etc.

Factors to be considered

Before starting documentation, it is important to consider certain factors that determine the nature of documentation.

Type of document

What is the type of document? Is it policy, procedure, work instruction or other type of document? The structure, style, and level of detail of documents must be appropriate for its type. For example, a policy document is high-level and brief, while a work instruction is very comprehensive providing details of every step to be followed and should be exactly in the right sequence in which it is required to be executed.

Target audience or users

The language, style and graphical content of the document varies based on the target audience. For example, a policy is generally used by managerial and executive level employees, whereas a work instruction is used by operating level employees and the language used should be appropriate. If a machine or equipment is used by qualified engineers, there is no need for explaining basic technical details in a document, whereas if it is used by technicians without much technical background, it may be necessary to include not only what needs to be done, but also why it needs to be done in a particular way, including necessary graphics.

Organisations that provide greater operational freedom to its employees may write only high level guidelines in its policy document, whereas an organisation with highly centralised and concentrated authority may need detailed instructions in its document.

Separate policy and procedure or combined?

While documenting Policy and Procedures, one question that often arises is whether to have separate documents or both can be combined. There are two distinct practices in this regard. Some prefer stating the applicable policy first, in the beginning of each procedure and then describe the process and the procedure. Others prefer to keep these two documents separate. The decision is ultimately based on ease of use and compliance.

Operational level policies generally have a direct relationship with one process or procedure. In such cases a combined policy and procedure is recommended. Strategic level policies are generally high level, impacting several procedures and as such, a separate document is recommended.

When just one or two statements of policy cover a whole process and procedure, it makes sense to state them in the procedure document so that the user is first introduced to the policy governing the process and the procedure. This sets a context for the procedure. It is also easy to maintain. However, when there are several policies that are impacting a procedure and those are spread over several functions and departments, their custodians being different, it is recommended to keep policy and procedure documents separate. The approval authority and the custodianship is another factor to be taken into consideration for such a decision. If the approval authority for all related policies and the procedure is same, one document may be sufficient, but in other cases make separate policy and procedure documents.

The policies are relatively more stable compared to the procedures and therefore the revision of policies is less frequent. A highly dynamic organisation constantly improves its processes and thereby updates its procedures more often. Separation of policy from procedures helps in incorporating such process improvements more easily.

Medium of publication

The governance documents may be published online or in a printed format. Online publishing improves the accessibility and has the advantage of printing the document whenever required. The IT technology provides necessary access control and features to monitor usage of the documents. Although most of the organisations today prefer publishing the documents online, there are still some traditional organisations that prefer having governance documents in printed format. The online publishing have the following advantages:

Ease of Access: The documents being online are available at the point of use, indexed and easily searchable. They can be accessed from any portable device, including smart phones.
Document integrity is ensured as there can be only one version i.e. the latest approved version available online. Physical retrieval and disposal of older versions becomes redundant.
Cost effective: There is no paper and printing cost involved. Drafting, reviewing, approval and reference all are online. No staff needed for receiving, and validating requests for printed copies and issuing them.
Better responsiveness and document update: The response to the end user requests for updates for error fixing or to meet changes in the process, organisation etc. are faster.
Ease of cross referencing: Often one document has to refer to content from another document due to cross functional dependencies, controls or compliance to policies. In an online document this cross referencing becomes easy due to hyperlinks, enabling the end user to navigate from one document to the other with ease.
Knowledge sharing: Due to ease of availability, the stakeholders can refer to the Governance Documents accessible to them, even if they are not related to their area of work. This helps in knowledge sharing and can lead to cross functional learning and improvement suggestions.
Accessibility of the document improves due to features such as reading aloud (text to speech) by the system and zooming.

When policy and procedure documents are published online, structure them with indexes based on the business functions they represent. Make a provision to print the documents, if necessary. Include appropriate keywords to facilitate accurate search.

General Guidelines

The following guidelines are applicable to all types of governance documents.

Clarity & readability

The documents must be clear without any ambiguity and scope for misinterpretation. Use simple language understandable by the target audience. If the target audience is technical, use appropriate technical terms and if the audience is non-technical, avoid highly technical terms.

Keep the policy statements or the activities of a procedure structured and in logical sequence. If there are headings and subheadings, maintain a logical hierarchy that reflects the process flow. If it is necessary to use numbering for structuring the text, do not use more than two levels of numbers, it adversely affects the readability.

For technical procedures and those having computer interfaces etc. if certain training or certification is a prerequisite, it must be stated in the beginning.

Define all special terms, acronyms and abbreviations used in the document before their usage. If any standard terms have special meaning within the document, they must be defined as well. The use of abbreviations and acronyms must be minimised to the extent possible.

Use the white spaces, tables and bullet points liberally to improve readability. Avoid too many underlined, italicised and bold typed words and sentences. Overuse of these defeats the very purpose of their usage. Do not use highlighting. It loses its effect when printed.

Maintain one common style of sentence construction throughout the document.

If a document is published as PDF, create the PDF file directly from the word processing application instead of creating a scanned copy from printed and signed document. This will reduce the size of the pdf and also increase the clarity. The pdf documents should have OCR for search.

If two processes are closely interrelated and have too many interactions, combine them in one document.

Double check the draft to ensure there are no errors. It’s a good practice to send the draft to all key stakeholders for review and incorporate their feedback in the final version.

Appropriate level of detail

Keep the writing accurate and complete, but concise, avoiding unwanted explanations. If it is a policy, state what the rule is rather than how to implement it. The details depend on the target audience's expertise and experience. Include only ‘need to know’ information as a general rule and include ‘nice to know’ information only if the document is also required to be used as a training manual.

Include quick reference cards in procedures such as maintenance or plant operations.

Use of graphics

A picture speaks a thousand words but at the same time over reliance on graphics has the danger of users skipping the text. This can lead to misinterpretation of the graphics. Include graphics wherever necessary to bring about clarity. For technical processes, use diagrams and illustrations for easy identification of the parts of a machine or equipment. For tools and equipment, along with the graphics, use the Equipment Number or any other identification number assigned for storekeeping.

For online publishing keep the graphics size minimum. Large images take up excessive storage space and make the page opening slow, which can be annoying on a slow network. It can also unnecessarily overload the server and slow down other work.

Avoid Information that is prone to frequent changes

Avoid information that is prone to frequent changes such as names of persons, their phone numbers etc. Rather provide the position title and office email for contact. In situations such as emergency reporting etc. there must be a company owned common phone number that does not change and is always accessible and held by the responsible person on duty. It is a common practice to create a common customer support email id for responding to queries.

In a lower level document, it is common practice to refer to a higher level document. For example, a procedure may have a reference to one or more policies based on which it is developed or the policies which it implements. In such instances, it is recommended to provide just the reference of such a document and not copy the contents in order to ensure easy maintenance of the document. When any changes are made to the higher level document, if only a reference is provided, there is no need to update the lower level document.

Publishing

It is important that the approved procedures are made available to the end users. Irrespective of the medium of publication, the end users and key stakeholders must be notified about approval of new and updated procedures and recall of old versions.

Sometimes, especially for policies the date of approval and effective date of implementation may be different. This is to allow time for related procedures to be updated and ready for implementation or to ensure that the changes in infrastructure, other related policies etc. are made. In such cases the notification should also include the effective date.

Access Control

For online content, provide maximum access possible for all documents. Transparency is the best policy and this can also promote interest in employees to explore policies and procedures of other functions and can become a learning platform. The confidential and sensitive documents only need to have restricted access. A restriction may be put on printing the documents, contributing a bit to save the environment.

Standardisation

The format, look and feel, language etc. should be consistent and standardised. It is a good practice to create standard templates for various types of documents, which can greatly enhance ease of compilation and usage. When standardised templates are used, the users know exactly where to look for specific information on the document.

Special terms used must be explained and those terms should have the same meaning across all documents. For example “Capital Equipment” cannot have one meaning in Purchasing procedure and another meaning in Accounting procedure.

Some of the terms commonly used in governance documents are explained below.

ATTEST

Validating the accuracy of a document by comparing it with an approved original document.

For example, attesting an Invoice by matching it with the Purchase Order (PO), Goods Receipt Note (GRN) and Quality Inspection, which is generally known as four way matching in ERP implementations. Most of us are familiar with the attestation of copies of academic certificates etc.

VERIFY

Validating a document or the output of a process against a standard or reference document, for establishing the compliance and accuracy.

REVIEW

Verification of a document or process for establishing the adequacy and accuracy of content. Review needs to be carried out by the stakeholders and people who have domain expertise.

SIGN

Signing is a way of documenting approval by a person having adequate delegated authority to do so and it is a verifiable proof of approval. Organisations generally have Table of Decision Authority (TODA) and Table of Financial Authority (TOFA) that list the authority of each position with limitations and restrictions if any. The signature may be physical on printed documents or electronic when the documents are approved and published online. Whatever may be the case, the proof of approval and the details such as the approving authority, designation, date etc. must be reflected on the document.

OMIT/OUT OF LOOP

This imposes a restriction on sharing or divulging of information to certain persons or positions within an organisation. This may be necessary due to confidentiality, non-disclosure or just to avoid overloading of unrelated functions with information.

RECOMMEND

‘Recommend’ is a decision supporting action. A prior detailed analysis and study usually precedes recommendation. The use of recommendation is where a high level (CxO level etc. ) approval is necessary. The CxO level positions cannot afford to spend time on studying the whole proposal, sometimes running into hundreds of pages with technical details, before approving it. The recommending position is usually a domain expert who studies the proposal with all the alternatives and recommends the most suitable option to the approver.

EXECUTE/PERFORM

Execute or Perform denotes implementing the decisions once approved. In procedures, this entails responsibility for execution of the process.

INPUT

Input is the responsibility of a position to provide necessary input such as information, specialised knowledge etc. for the process or decision. This is more of an advisory role, however, the inputs provided are not binding on the approver.

DECIDE

This role is ultimately responsible and accountable for the final decision. The accountability also involves enduring its implementation and compliance.

INITIATE

This role is responsible for starting the action on approved decisions. Generally, the initiator is also responsible for executing.

PARTICIPATE

This is a role in collective or group actions such as team or a committee, where the members participate in all deliberations and are collectively responsible and not individually.

ENDORSE

Endorsing is confirming the validity and suitability of a proposal or action based on the specialised knowledge or domain expertise of a person or role. This typically involves studying the proposal in detail and often providing specialised inputs during the process and finally confirming to the approval authority that the proposal or document is suitable for approval.

CONCUR

Concur is to agree with a proposal. This is useful in cross functional processes where there are several functions involved in the process. The procedures are developed by the process owner, who has a major role in the process. Other functions concur with the process or the procedure, before it is finally approved by the approver.

SHALL or MUST

Indicates required tasks or actions.

SHOULD

Indicates recommended tasks or actions.

MAY

Indicates permissible tasks or actions.

CAN

Indicates the ability to do, make, or accomplish (something).

WILL

Indicates anticipated or future tasks or actions.

Guidelines for developing standard templates

This section provides some guidelines for developing standard templates for governance documents. The illustrations provided are meant for printed documents, however, the information contained therein is also required for documents in any other format, including online documentation. A thorough study needs to be carried out before designing the templates as it is very difficult to change them once several documents are developed and published.

Header

Header generally contains the metadata of a document, useful in its identification, organising, accessing and other document management related actions. The following illustration provides a typical sample. A brief explanation of each field follows.

Logo

The company logo is placed in this location. Some organisations prefer to place it on the right hand side, but it’s all a matter of convenience and standardisation.

For external documents I would recommend placing the logo on the right hand side so that when it is filed by an outside entity, while flipping pages, from the logo the document origin can easily be identified and thereafter other details such as document title etc.can be identified.

For internal documents, there is no need for identification of the organisation, but the document title and document ID are more important and therefore this information should be more visible while flipping the pages in a file..

Organisation Name

Your organisation name goes here. If the logo itself has the full organisation name, this field may be ignored.

Do not use any short forms of name as the policies and procedures are likely to be used by external stakeholders like suppliers, dealers etc.

For documents that are strictly for internal use, the logo itself denotes the organisation and therefore, writing the name may be avoided if you want to conserve space.

Department / Strategic Business Unit

This is the second level of organisation structure and generally considered as the owner or custodian of the document.

In our example only two levels of organisation structure are considered, which is adequate for most of the cases. A third level may be added only if it is absolutely essential.

Document Title

This is the title of the document such as ‘Preventive Maintenance Procedure’, ‘Purchase Requisition Procedure’, ‘Recruitment Procedure’ etc. Use industry standard terms and make the title self explanatory.

Document Type

The document type may be identified by the ID or the document title. If you need a separate classification, enter the document type in this field. The content of this field could be ‘Policy’, ‘Procedure’, ‘Guidelines’, ‘Work Instructions’ or any other such document type. It is a good practice to keep this information for facilitating search, reporting and document management purposes.

Review Frequency

In this field indicate how frequently the document needs to be reviewed. Examples: 1 year, 3 years etc.

Once a review frequency is set, it does not mean that earlier reviews are not to be done. When the work environment, related policies or other factors affecting the policy and procedures change, the document needs to be reviewed and updated. When improvement initiatives are implemented, the policy and procedures are generally reviewed and necessary changes are incorporated. The review and update may also be triggered by audits related to finance, marketing, QMS or other certification standards,

In an automated document publishing environment, a provision may be made to track the next review and send notifications to key stakeholders and the document owner function well in advance.

Document ID

This is a unique identification assigned to the document. It may be a simple sequential number or a smart ID consisting of the organisation element, document type and a sequence number.

Consider the following example:

UW-FM-PR-001 where

UW = Unique Widgets (Company Name)

FM = Facilities Management (Name of the Department)

PR= Procedure (Document Type)

001= Unique ID (Sequence Number)

Revision Number

Revision number is used for version control of the document. Revision number may be written simply as ‘Rev.’ or ‘Rev. No’ as may be convenient to conserve space.

Some applications allow for auto incrementing revisions, in which case it is recommended to leave the versioning to the system.

Manual revision numbering may be done in various forms. Ultimate purpose is to easily identify the latest version and trace back previous updates.

A document undergoes several stages of development before it is finally approved and published. For practical purposes I would recommend a clear distinction be made between versions during initial drafting and development state and versions after approval. Personally I prefer using A, B, C, D, A.1, A.2…. etc. for version control of the initial draft during development, which will be reset to Rev.0 during its first approval and publishing. After the first approval and publishing, subsequent updates can be versioned as 1, 2, 3, 4 etc. and if required, minor revisions as 1.1, 1.2, 1.3 etc.

Page

I would recommend using nn/NN pagination format to help the reader to know the page number as well as the total number of pages. The document title page need not be counted.

Page numbering is not applicable for online documentation unless the application used for documenting displays one page at a time in the print page layout format. Even in online documentation, when a print option is available, use page numbering in the printed document.

Document Title

State the document title in large bold font on the front page. Try placing it at the centre of the page so that the printed document looks professional. However, there is no hard and fast rule. An organisation engaged in graphic design or marketing may like to be more creative and artistic with the front page. It does not matter how it appears, as long as the front page has the document title.

Approvals

Approval is part of the document control mandated by almost all certification standards and is also a legal requirement for several documents. The following illustration shows various types of reviews, endorsements and approvals organisations enforce. This panel is for illustration purposes only. Not all are necessary in a document.

Approval must be by the appropriate level of authority as per the delegation of decision authority and financial authority. As a thumb rule, the policy approval must be at least at one level higher than the corresponding procedure approval.

The approval authority’s designation (job title), date and signature must be attested, unless the document is electronically approved, in which case the electronic approval must be reflected.

If a ToDA/ToFA document exists, make sure that the approvals within the document are in compliance with the delegation contained therein.

Footer

The following is the typical illustration of a governance document footer.

In spite of best efforts, it is almost impossible for a policy to address every aspect of business and for a procedure to address every conceivable situation. Always state in a policy and procedure “if in doubt, ask <the function or contact details>”. Wrong outcomes are often a result of assumptions where the document lacks clarity. To be authentic, a person knowledgeable with a policy and procedure and its interaction with other processes should be the one assigned with the responsibility to provide clarifications. The person so assigned, should maintain a list of all clarifications provided for including them in the next revision.

If the documents are hosted on a server and accessible from a portal, provide a link to such a portal stating that any copies other than those found at this location are not authentic.

Provide a table of content for easy navigation, but keep the table of contents simple and try to fit it on one page. The following is an example:

Multi level table of contents with titles, sub-titles, sub-sub-titles are to be avoided.

Body

Various sections that form the main body of a document are described below.

Record of Amendments

The following is a typical illustration of the record of amendments.

This provides an overview of what changes a document has undergone over a period of time.

Introduction

Provide a brief introduction of what this document is and the context in which it has been prepared. For cross functional processes, it is important to define here the custodian of the process, who is responsible for interpretation, implementation and updating the document.

For documents meant for external use, provide a brief overview of your organisation. For documents meant for compliance with the certification standards, provide a brief context of compliance with the standards.

Purpose/Objective

State briefly the objective or purpose of the document. Also explain what is meant to be achieved in terms of outcomes by implementing or by compliance with this document.

Scope

Explain briefly the scope and boundaries of the applicability of this document. It may be a specific activity, function or section of an organisation. It is also important to include exclusions and exceptions if any.

Terms and Abbreviations

Any special terms used should have the same meaning as assigned in the related higher level documents. The lower level document cannot define a different meaning for them. Clearly define special terms and acronyms used and standard terms that may have a different contextual meaning. They must be defined before their use in the document.

Do not create too many abbreviations and confuse the reader. It is difficult for the reader to flip pages or scroll on the screen to find out what the meaning of an abbreviation is.

Key Risks and Mitigation Controls

A policy and procedure must address key risks and put in place controls for mitigation. The table illustrated below may be used for documenting identified key risks and controls that are in place for their mitigation.

Roles and Responsibilities

It is important to clearly define the roles and responsibilities within a document to establish accountability and ensure compliance. There are several responsibility assignment tools and charts used for documenting policy and procedures. A few prominent of them are briefly addressed below.

The following is an illustration of the RACI Matrix.

Responsible:

Refers to a person or a role that is responsible for executing the task . There must be at least one such position identified for a task. Although there is one position or person designated as ‘Responsible’, there can be several others to assist that position or person, either directly or indirectly reporting. Unfortunately there is no role as ‘Assist’ or ‘Support’ in RACI Matrix.

Accountable:

Refers to a person or position that has the overall responsibility of achieving the objectives, outcomes and deliverables of the task. There can be only one person or position with this role. Generally this role also has the approval authority for the process or the taks.

Consulted:

Refers to the person, position or function that is consulted for specialised inputs and domain expertise during performance of the task. The ‘Consulted’ entity may be internal or external to the organisation. Based on the complexity of the task, there can be multiple entities ‘Consulted’.

Informed:

This refers to the persons or positions that are not part of the execution process, nevertheless they are required to be kept informed because they are key stakeholders and have an approval authority or interest in the outcomes.

RASCI, RACI-VS, and RAPID are some of the variants of the RACI matrix with expanded and more granular responsibilities. The additional responsibilities of these tools are discussed below:

The ‘S’ in RACI-VS and RASCI refers to ‘Support’. Under the RACI matrix we have seen that there can be several persons or entities that Support the Responsible person or role in executing a process or task. The support may be in the form of providing input, knowledge, or executing part of the task. Unlike ‘Consulted’, support is part of the execution team.

The ‘V’ in RASCI-VS stands for ‘Verify’. The verification is for accuracy and compliance. In a sense, this is a quality assurance role. The verification generally precedes the approval.

Tools & Equipment

This section is important for procedures where tools, equipment, and instruments specific for given activities are necessary. Examples are assembly work, plant maintenance, healthcare etc.

List all the tools, equipment and instruments required with their identification number, name, range, tolerance limits etc. as may be necessary for executing the procedure. The end user can use this list to make sure that these are available before commencing work, request them from the store and can carry them to site.

Process flow diagram

For procedures it is important to include the process flow diagram - a graphical representation of the process, in the document.

Including the process flow diagram provides a quick overview of the process and at the sametime brings in more clarity to the procedure. The process flow diagrams are of immense help during brainstorming for developing or improving the process.

The following is a process flow diagram for illustration

As seen from the illustration, the activity boxes are numbered, which helps in linking the procedure narrative to the activity boxes for easy reference. The numbering must be in the logical sequence of process flow. Where there are multiple parallel paths, start numbering the most common flow first and continue in that order until you complete the least common. Activity boxes 5 and 6 in the illustration are sub-processes.

There are various tools, notations, and methods available for creating process flow charts. Some business process modelling tools also provide features for navigating between the process flow activity box and the narration with hyperlinks. There are also process modelling tools that allow workflow management. Select the most appropriate for your requirement. The basic notations shown in the illustration meet most of the process flow needs. Keep them minimum for simplicity.

Too many steps in a process flow diagram with crossover connecting lines going to and fro can create a nightmare for the reader. Avoid such ‘spaghetti’ process flow diagrams. Combine related basic tasks into one single meaningful task to reduce the number of boxes. Where there is a distinct sub-process (like activity boxes 5 and 6 in the above illustration), make a separate process flow diagram for it.

Procedure narrative

The procedure narrative describes each activity in the process flow diagram. The following is a sample format that may be used for documenting the narrative.

Describe clearly how an activity must be carried out. In the narrative include what should be done, who does it, how much and what type of inputs are to be used, what is the quality check to be carried out for the inputs before processing, what equipment and measuring devices to be used, what process and output measurements are to be carried out and the acceptance criteria for the output.

When a task involves a series of activities, use numbered or bullet lists and state the activities in their logical sequence. This can reduce errors while executing the procedure.

Where there is a computer interface for data entry, it is a good practice to include a screenshot with numbered data entry fields and include those numbers (IDs) in the narrative to make the data entry error free.

Where a form or template is required to be used, include the title and document ID of the form and template.

Where there is an inherent risk or possibility of unexpected outcome, include a warning in red colour and with a caution warning sign to draw the attention of the reader to the inherent danger.

Where some actions required are different from normal logic or general understanding, provide notes explaining why it needs to be done in the way described.

For time, use a 24hr clock to avoid confusion. Any misunderstanding can result in serious consequences in critical organisations such as healthcare, utility etc.

For numbers use numerals (like 4 ) and not ‘four’. This improves the readability and registers in the mind of the reader more easily. If at all writing in words is necessary, write the numbers first and write the words in brackets, like 4 (four).

SIPOC

Although not necessary, some organisations prefer including a SIPOC (Suppliers, Inputs, Processes, Outputs, and Customers) table in the procedures. This tool is more useful for mapping a process rather than as part of a procedure. If you wish to use it, the following format may be used.

Annexures

Use this section to include documents that are important in the context of the current document. An example may be a memorandum of understanding with an external organisation or a board decision that necessitated this policy or procedure.

Avoid making forms, templates and other policies as part of the annexure.

Search This Blog

Operational Excellence