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)

Whose Job Is It Anyway?

One of my favourite maxims is "vision without execution is hallucination".  Not sure who coined the phrase but I like it.  It's all very well saying "let's do something" and it's something else to actually get it done, especially if it involves people.

It's helpful to have some "getting stuff done" tools in your toolkit and one tool that I've found helpful in the past is "RACI".

To get from an idea to reality, we need to know who is going to do the work.  This is where RACI comes in.

RACI stands for "Responsible, Accountable, Consulted and Informed".  It's a usually framework to understand the roles of all the actors in a system required to get a task done.

Responsible
The responsible person is the doer.  (Or doers, i.e. those that actually do the work and deliver to the agreed standards, time frames or expectations).

Accountable
The buck stops here.  This person is answerable for the correct and thorough completion of the task.  It can only be be one person.  The accountable person may well delegate their tasks to a responsible person but they cannot delegate their accountability.

Consulted
Their opinion is sought, these are experts whose skills or knowledge can influence the success of the task.  It's a two way communication flow between the Responsible and Consulted parties. It can be more than one person.

Informed
(Or - told). Those who need to know what's going on.  Not necessarily during task, more likely on completion.  It's a one way communication and it's usually many people.

In any project, you write down all of the tasks down as the rows in your matrix.  In the columns, write either names or job titles.  In the grid, type R, A, C or I in each cell. 



If you do this with all of the people involved you can then get consensus on who does what.

It provides a good grounding for the next part of organising - what interactions (e.g. meetings) and documents are required during the project to make sure everyone gets what they need from the others involved.

To Scale Or Not Scale?

I was at an event earlier this week with a room full of tech start-up and growth company COOs.

One word that was used often in conversation was "scaling". 

"As the business scales", "When you're scaling up", "scaling the business", "scaling the team", "bringing scale to the team"... these were all typical soundbites.

I've heard people use the term so much over the past few years.  In a start-up it's easier to talk about "growth" and "scale" than trickier subjects such as "revenue" and "profit".

So, to clear things up, just what is "scaling".

Well, in my opinion, it's something more than just "size".

It's about efficiency of resource utilisation.

Here's a simple example.  You have £100,000 in revenue.  You have 5 people.  You have 2 web servers.

What happens when you double the revenue?  Do you double the team and double the number of servers?  If you do, you are not scaling.  You are just growing. 

Scaling would mean that you doubled the revenue, but the team size and web servers did not need to double.  Maybe the team went to 6 people and the web servers stayed the same.  Now you're starting to scale.

Scaling come from the term "economies of scale". 

The more transactions that take place, the cost per transaction comes down.

So - are you scaling or growing?  Ideally both!

What's For Tea?

In our household there's sometimes a discussion that starts late morning or early afternoon with the question, "what shall we have for tea?" 

(Tea by the way meaning evening meal).

I usually say, "I don't know, it depends what's in the fridge".

My wife on the other hand likes to know what it is she is going to look forward to.

She'll think of a dish that she'd like and then asks what's missing to make it. If we need one or two ingredients, she'll buy them.

I on the other hand prefer to freestyle and make do with what we've got. Where she sees an empty cupboard, I see three or four alternative dishes. As I am the one cooking in these situations, I prefer to go with the flow.  It's not that I don't plan. I do plan. I plan by putting in place a lot of ingredients in our weekly shop. The cupboard is always stocked with lots of flavour and base items.

I however am less likely to imagine a meal in advance. I will perhaps look in a recipe book for ideas if we're having guests. My wife will think of lots of alternatives.

What about you? Who are you most like?

Both personality types serve a purpose. To be able to envision a future and make it happen is a great trait for entrepreneurs. Let nothing get in the way, get what you want.

Equally, the ability to adapt, optimise and deliver based on limited resources (making sure there are the right ingredients in place) is a great trait needed by teams who are working to build businesses.

Both tendencies have their advantages. Put both together and you get a formidable team.

By the way, it's no coincidence that my wife comes from a sales background and that I come from an operations background.

Just don't ask me what we are having for tea. Trust me, it'll taste great.