Policies and Procedures 5 of 5: TEMPLATE

In this mini-series on policies and procedures I am covering;

1. WHAT is a policy and procedure
2. WHY should you document a policy and procedure
3. WHEN and WHO should document a policy and procedure
4. HOW to document a policy and procedure
5. TEMPLATE for a policy and procedure

[04.03.14 - After I published this blog I had positive feedback. COO Danny Mash recommended that I add a point 6.... “ Assembling, indexing, referencing and evolving the P&P binder”.  I agree.  Whether it's physical or digital, a definitive checklist of all P&P's in circulation is a useful help]


This post shows a TEMPLATE that you can use for a policy and procedure

Policy and Procedure Template 

[Process / policy name here]

Process authored by:     [Name]

Last updated:                   [Date]

Version:                             [Number]

Introduction

In this section explain

1 – why this policy / process is needed

2 – explain the context, background information so that a new team member can understand the detail

Terminology

Describe any relevant terminology / vocabulary or abbreviations

Policies

State any policies relevant to this process.  These are company decisions which shape the policy

Process

Describe the process, step by step in numbered points

Measures

State any measures or reporting that is done (by whom and when) to ensure that this policy and procedure is being followed

Policies and Procedures 4 of 5: HOW

In this mini-series on policies and procedures I am covering;

1. WHAT is a policy and procedure
2. WHY should you document a policy and procedure
3. WHEN and WHO should document a policy and procedure
4. HOW to document a policy and procedure
5. TEMPLATE for a policy and procedure

This post is on HOW to document a policy and procedure...

Whenever I document a policy and procedure I tend to 

- put them in one document together

- use words to clearly explain everything 

- use numbered points for structure

- use diagrams if need be

- publish the document on "the path most travelled" so that is is easily accessible by all team members (e.g. Intranet, CRM system, Yammer, email, notice boards). Wherever it will get seen. 

In terms of structure there are 5 main sections;

1. Explain the context
2. Define vocabulary and jargon 
3. State the policies
4. Describe the procedure
5. State how compliance will be measured

A few details on each of the above...

1. Explain the context

Why is this policy and procedure important? What benefit is there (to the team, to customers, to suppliers, to the company) if this policy is followed? To whom does it apply? Who is responsible for making us sure it us followed? 

2. Define vocabulary and jargon 

If there any words in here your Mum wouldn't understand, define them. If the are any abbreviations, define them. A complete newcomer to the company should be able to understand thus document. 

3. State the policies

Try keep it simple. What are the main policies. Put them in bullet points. 

4. Describe the procedure

Step by step describe the procedure. Explain who does each part of the process. Explain how to use the relevant systems. If the supervisor were unable to show the team how to do their job, they should be able to follow these instructions. 

5. State how compliance will be measured

If you can, find relevant metrics to measure whether it not this policy is being adhered to. Measure. Share. Improve. 

Every policy will need reviewing on a regular basis to improve and keep up to date. 

Tip: if you can publish your policies as a "live" document such as a web page, it's much easier to ensure everyone has access to the latest version of the policy at the click of a mouse. So much easier than emailing out attachments. 

Next: TEMPLATE for a policy and procedure (coming 15.02.14). 

Policies and Procedures 3 of 5: WHEN and WHO

In this mini-series on policies and procedures I am covering;

1. WHAT is a policy and procedure
2. WHY should you document a policy and procedure
3. WHEN and WHO should document a policy and procedure
4. HOW to document a policy and procedure
5. TEMPLATE for a policy and procedure

This post is on WHEN and WHO should document a policy and procedure...

I'm coming at this topic from the perspective of high growth tech startups as that's my background. 

A startup let's remember is an organisation whose purpose is to uncover a viable and repeatable business model. Once a viable and repeatable and business model is understood and proven the task is to exploit that opportunity and become profitable. 

In this context a team may grow from the founding team to 10 people to 30 people to 100 people to 200 people very quickly. 

In the earliest stage of a startup, policies can be controlled by direct real time decisions by the founders. Procedures are not yet known as the business model is in flux and the whole team is in experimental mode. 

There's little point in creating a body of policy or procedure until..

i) the business model is understood

ii) the team is growing and more than 2 people are doing any one job

iii) processes and methods start to become stable and repeated 

The WHEN dimension therefore coincides with the point at which the company starts to scale. That's what makes it challenging. Studying the policies and procedures at the same as growing a team is a demanding task.  There's enough to do (interviews, training staff, setting up office space and tools) without having to worry about writing down policies and procedures. There comes a point at which the payback in the medium term is worth the sacrifice in the short term. The task of a COO is to judge that moment and prioritise creation of policies and procedures appropriate to the stage of the company. 

Not everything needs doing at once. There are customers to serve and revenue to generate. Inevitably some policies and procedures are more important than others. There's no formula for that, only good judgement. 

WHO should write the policies and procedures?

This will depend on the organisation of course. The way I think about it, the person accountable for the quality of the work should draft the policies and then delegate the drafting of the procedures to the person responsible for the team carrying out the majority of the activity. 

(For more details on the difference between accountable and responsible see this post. In short, accountable = "the buck stops here" and responsible = "the do-er"). 

By asking the person responsible to write up the procedure it achieves 3 things;

1. That gaps of knowledge are uncovered and details are added 

2. That the person writing the procedure will more likely adhere to it

3. That the person writing the procedure will more likely make others adhere to it

The accountable person needs to read, question, review simplify and/or elaborate upon the draft and approve it for publishing. 

Both people need to then create a plan to instill the policy and procedure within the team with education, training and controls. 

In the example of a customer care team, the customer care manager (responsible) might draft the procedures based on policies provided by the COO (accountable). 

Next: HOW to document a policy and procedure

Policies and Procedures 2 of 5: WHY

In this mini-series on policies and procedures I am covering;

1. WHAT is a policy and procedure
2. WHY should you document a policy and procedure
3. WHEN and WHO should document a policy and procedure
4. HOW to document a policy and procedure
5. TEMPLATE for a policy and procedure

This post is on WHY should you document a policy and procedure...

There's a few good reasons. 

1. The obvious reason: so that people have instructions to follow. It's a good reason and certainly makes a lot of sense to document instructions, especially when you have lots of different people involved in making something happen - or when you have lots of people doing the same job and you are looking for consistency. However, just because you wrote it all down doesn't mean people will follow the policy. 

2. The less obvious reason: by writing everything down it becomes clearer what the procedures are, any uncertainties are uncovered and discussed. The act of writing is an act of clarification. You may think you understand everything but until you've written down all the details you won't know for sure. Writing uncovers gaps. 

3. The unspoken reason: to cover your arse. Sometimes a company will publish policies and procedures to show they are compliant with legislation. By asking staff to sign a declaration that they are gong to adhere to published policies and procedures, the liability of the company might be reduced in the event of a rogue employee defying the policy. In this case it was the employees fault m'lud, not us. Don't fine us. We're the good guys. A lot of HR policies seem to have this concern underpinning them. 

4. The most important reason: to improve the process. This for me is the key reason. By writing something down you can start to measure it, observe it and improve it. In fact, I'd go so far as to say that it is a failure if policies and procedures do not change. They must change, especially the procedures. A set of procedures that have not changed for years mean only 2 things; either i) that they are perfect and therefore require no changes or ii) that they are imperfect and there is a failure to improve them. I generally have a disbelief in the existence of perfection because the environment in which we exist is continually changing. Perfect would mean a constantly adaptive and predictive system. A written set of policies and procedures can be measured, understood, improved and changed. Unwritten ones cannot. 

Next: WHEN and WHO should document a policy and procedure

Policies and Procedures 1 of 5; WHAT

In this mini-series on policies and procedures I am covering;

1. WHAT is a policy and procedure
2. WHY should you document a policy and procedure
3. WHEN and WHO should document a policy and procedure
4. HOW to document a policy and procedure
5. TEMPLATE for a policy and procedure

This post is on WHAT is a policy and procedure...

I thought I'd share some basic practical tips on Operations Management that I've learnt.  None of what I will describing is from a textbook.  It's all from real life experience from more than 20 years of testing things out in the real world.

A policy and procedure is a basic building block of the operation manager's toolkit.

A POLICY is a series of decisions made by the company about how they intend to handle certain situations.  It's a decision made by and endorsed by the managers of the company and you can think of policies as being like principles upon which actions are taken.

Examples;
- We will always attempt to acknowledge a customer complaint within 24 hours of receipt
- We will match any competitor price for the same goods if we receive notice within 2 weeks of purchase
- We will / will not cover shipping costs for returns
- We will ensure all new starters have a desk, computer and email account set up prior to their start date

A PROCEDURE (or process) however is a set of repeatable instructions that explain how individuals, teams and systems act out the policy. A procedure will describe step by step what is required in a particular scenario.  It's usually a scenario that repeats itself or that can be predicted.  People carry out tasks by following the procedures.  It usually explains who is responsible at each stage of the process.

Examples;
- How to process a cancellation
- How we recruit people
- How we handle complaints
- What we do when someone leaves the company

To describe a procedure without explaining the policies that underpin it risks that people following the instructions don't appreciate the context in which they are working.  Blindly following instructions means that should the instructions be missing a small point of detail or should the circumstances be so unusual that the instructions are incomplete, the team member would not know how to act.  However, if they can also understand the principles upon which the instructions are based, then they are more able to act in the interests of the company.

So, consider policies as a set of written principles and procedures (or process) as a set of written instructions.

Next: WHY should you document a policy and procedure (coming 11.02.14)