Basic Policies and Procedures



By Alberto Nothnagel



Published by



Copyright 2016 Alberto Nothnagel


This e-book is licensed for your personal enjoyment only. This e-book may not be re-sold or given away to other people. If you would like to share this book with another person, please purchase an additional copy for each recipient. If you’re reading this book and did not purchase it, or it was not purchased for your use only, then please return to Shakespir.com and purchase your own copy. Thank you for respecting the hard work of this author.


[email protected]







To many people “policy” is a swear word.




In many instances we don’t like policies because the policies constrain us from implementing a specific solutions or taking a specific actions. Often we don’t like a policy because it prevents us from doing what we want.


If you are a direct action type like me, you will identify a problem, a solution and implement. Unfortunately I also tend to be unconventional in my drive to achieve outcomes – and that often rocks the boat and ruffles feathers. So like it or not, often the limitations imposed are for my own good as they curb my exuberance and to ensure I play nice.


But often the frustration is usually the result of a constraint created by a policy that was still chiselled by a stonemason, now quoted by a dinosaur or a slinkydink in order to prevent us from progressing to the use of the wheel, or for him or her to weasel out of being fired for incompetence.


And so we are introduced to rule 1 – policies and procedures are supposed to make things better – not worse. If you are drafting a policy for any reason other than to make thing s work better, you are off to a bad start.


If you are charged with the responsibility to develop a policy, it will be important to consider certain commonsense aspects:


1. What are you trying to make better?


2. Is there enough of that happening to make a policy worth the effort?


3. What other constraints and structures are already in place? Remember your policy will be constrained by other policies and regulations of parent organisations, umbrella organisations, regulatory bodies, legislation etc.


4. Have you involved the right people in the development of the policy?


5. Do you have buy-in from the business?


6. Can you implement successfully?


7. Who will be the custodian of this policy and maintaining it?


Good policies and procedures are about identifying the issue, identifying the solution and documenting those for consistent application.


Policies and Procedures are not about having an excuse not to think and having an excuse to avoid the responsibility to lead, to manage or to take responsibility – they are about creating a framework for consistency in performance and execution.



What are policies and what are procedures?


1. Is there any difference?


A policy is a defined system of principles used to make decisions and achieve predictable outcomes.


A procedure is a series of actions that are done in a certain way or order or an established or accepted way of doing something.


The policy sets the framework – the procedure defines “the how” in how things are done.


From the above, it should be obvious that the policy is the high level document that sets the tone or approach – the procedure is the “nuts and bolts”.


The leadership in larger organisations will be looking at things on a strategic level – they have the bird’s eye view, they decide a battle plan, give direction and the ship sets sail.


The managers and supervisors are the guys to make sure that the ship stays the course, the engines keep running, the shoals are avoided etc.


Policy is set at the strategic level – it is about goal, direction, intended outcome. These things should not be changed willy-nilly – the policy sets these parameters.


Procedure is an operational issue – what inputs are required to the process, what actions are taken when, how are outputs channelled – these are things that change much more regularly – processes adapt to changing variables etc. The guys at the top are usually not aware of these “minor” elements – and they do not need to be in order to decide the battle plan.


Procedures are there to give consistency in dealing with specific variables, providing direction in how exceptions will be channelled etc. In order for the ship to start firing its guns, you need to be within a specific range, there are processes to load the guns correctly, checklists before the trigger is pulled etc.


If you had to wait for a change to the battle plan to contend with these changes, the battle would never be fought.


The ship cannot stop for strategic guidance if you have to adjust for the effect of the current, wind etc – and the guidance from above would not be the best as the helmsman is the best guy to adjust course for the current drift – that is where procedure and protocol makes way for managerial discretion.


2. Why not just combine the two?


Policies and procedures are not combined as their focus differs, the level at which they are decided differs, the frequency at which they have to be updated differs and the nature of their effect differs.


Inside businesses, the processes required to adopt or amend a policy are different from those pertaining to a procedure:


Policies are usually adopted by the Board of Trustees / Directors (or delegates) of a company.

Any amendment needs to go through the same process; any review needs to go through the same process.

The process to get the big dogs to do anything is tedious – usually it requires scheduling presentations on why a change is required, what the scope of the change will be, securing permission to explore the possible changes, presentations on the alternatives, business cases supporting the suggested alternative, passing the suggestions through sub-committees and then having it approved – after the mandatory cosmetic changes the Board will insist on in order to earn their keep.

Bearing in mind that these guys are not in office 24/7 and you are usually just one of the items on the agenda for the monthly meeting – getting anything done on a policy can take several months.


Procedures on the other hand are operational tools and are adopted and amended on operational level i.e. the procedures are more flexible – within the parameters of the policy that governs the particular procedures.


Procedures are usually drawn up and updated by the supervisors and junior or middle management, before final signoff by the senior management in the specific area (as the accountable parties)


Changing a policy is a much more time-consuming exercise as it is born from strategy – procedures are living documents – the approach to changing it is not as formal, less time consuming and more responsive to immediate need.


But remember the policy is the enabler to the procedure – if you wrote a bad policy, your procedure will be stillborn.


3. So how do we make the policies and procedures binding?


Making Policies and Procedures binding is part of the deployment of policies and procedures – but since this is a question that always crops up early in the conversation, let’s briefly touch on it now.


It is imperative to always come back to the “why?” of the policy.


The purpose of a policy or procedure should always be to improve what we are doing – it should have the intent to structure, guide, control, organise or similar.


If you put a policy in place for the right reason and your policy is well written, the business at large will welcome it – problem solved!


Unfortunately as humans we are inherently lazy though, so reading policies and adhering to prescripts is often a bit of a challenge, so we need to be sure the staff read, understand and adhere.


Obviously it would be best if your contract of employment specifically refers to adherence to all policies and procedures – but it is not a legal requirement for the contract of employment to state that an employee is subject to the company policies and procedures.


It is sufficient if you have proof that employees have been made aware of the policies and procedures – and this you can do by means of an attendance register to a meeting where the policies have been introduced, or any other means such as to put your policies on the company intranet, and then to link your sign-on protocol to a confirmation that the employee has familiarized him or herself with the new/changed policy and/or procedure.


When it comes to disciplinary and labour issues, we will always prefer to have the signature of the employee on a statement that they subject themselves to the particular policy or procedure – but it is implicit to the employment contract that you are subject to all reasonable policies and procedures that you reasonably should have been aware of. (The reasonable expectation of awareness has to do with how long you have been there, how familiar you are with the work, what training you have received etc. Disciplining Johnny on the first day is ridiculous – but to claim you didn’t know after working in the unit for three years is equally ludicrous)


The key issues for enforcement are that:


1) the policies and procedures are reasonable and executable;


2) the policies and procedures have been properly introduced to the business;


3) the policies and procedures are immediately accessible and continuously and consistently applied;


4) that there is some method by which it can be confirmed that the employee was aware, or should reasonably have been aware of the content of those policies and procedures.


If a policy requires an employee to act in a certain way, or prohibits certain actions, it is to be expected that a contravention will be followed by disciplinary action – make sure that these are in place and that they are applied consistently.


The seriousness of the contravention will decide the nature of the discipline exercised – progressive discipline is ideal, but some contraventions warrant sanctions such as dismissal i.e. theft, sexual harassment etc.


It is good practice to issue an employee manual to an employee on commencement of service, but in most instances it will not be practical to issue a new manual to each employee every time there is a change to a policy or procedure.


One option is to publish and distribute the amendments, but in this electronic age the most practical is probably to make all the amended policies and procedures available on the company intranet, with some kind of confirmation protocol to ensure that there is a record that the employee was made aware of the changes.



Why do we need policies in an organisation? What are their purpose?


1. How is a policy going to address an issue? Identifying the need for a specific policy.


1.1 Do I need policies and why?


You want to have the necessary policies and procedures to ensure an efficient, safe, organized, empowering, work place – yet, you do not want to write a policy for every exception to accepted and expected behaviour.


Policy development is for the many employees/processes/procedures – not for the few exceptions.


A policy is not a tool to absolve management of its responsibilities, it is not intended to take the place of using your healthy mind and judgement – it is about setting frameworks to deal with the majority of situations – nothing more and nothing less.


1.2 As a general guideline a policy is necessary in the following circumstances:


1. If the actions of employees indicate confusion about the most appropriate way to behave, or if abuse of privileges is apparent.


Examples here will be disagreement on the minimum criteria or standards on doing something or when you note slacking on things such as dress codes with client facing staff in a professional environment coming to work in shorts and T-Shirts.

Typically there is a need for control on E-Mail and Internet usage or else the time spent for private use can become a problem (and even a risk).


2. When there is a need to protect the company from legal action (i.e. charges of sexual harassment, discriminatory hiring and promotion are very real threats in this day and age).


3) To keep the company in compliance with governmental policies and laws (again the risk of litigation and fines are very real here – think in terms of BEE, Employment Equity etc.).


4) To establish consistent work standards, rules, and regulations (progressive discipline, safety rules, break rules, smoking rules, grievance procedures etc.).


5) If guidance is needed about the most suitable way to handle various situations (standards of conduct, travel expenditures, purchase of company merchandise).


6) To provide consistent and fair treatment for employees (benefits such as paternity and maternity leave, tuition assistance, principles on transfers, promotions etc.).


There may be other reasons, why you may want to develop a policy, dependant on the working environment – financial institutions are an example of an environment requiring strict policies, processes and procedures for security and service level purposes.


Usually policies will be supported by a procedure document that will provide more details of how things will be done, and this document will also be subject to more regular change.


The procedure will not necessarily be directly linked to the policy – you will not have a Procedure on Sexual Harassment – but a transgression of the Policy on Sexual Harassment will be dealt with in the Disciplinary Procedures and the Policy will usually state that transgressions will be dealt with in the manner set forth in the Disciplinary Code or Disciplinary Procedure.


Once you have determined that a situation warrants intervention, determine the goal you want to accomplish in writing the particular policy.




You may want to protect the image of the organisation, so you may have a policy on the engagement in the social media.


If you want to protect the company image, formulate the policy around that – do not try to formulate a policy to curb free speech – you will lose as it is a constitutional right.


What do I mean?


You cannot tell people that they may not express themselves freely – but you may limit them from expressing negative sentiments about the organisation they work for, or engage in hate speech or similar that will reflect negatively on your organisation, if the action of the person is linked back to your organisation. (If their Facebook profile clearly states that they work for your company and they engage in hate speech, it will impact the image of your company or organisation.)


The key is formulating the problem and crafting a solution for that. Be clear and concise – the time spent formulating the problem and solution statements will save you hours of work and tons of embarrassment, later.


Get as much input from the role-players and stakeholders as possible – but remember – you can never hope to cover every potential situation addressed by the policy.


Good research is imperative if you want to avoid the pitfalls of a badly written or ineffective policy – look for examples of policies written to deal with similar situations and adapt those policies, subscribe to HR and Legal services that deal with the area in question or bring in consultants that can provide you with specialist skills.


2. So what else is a policy going to do?


2.1. Aligning processes, procedures and conduct with the strategic objectives of the organisation:


The primary purpose of a policy is to ensure that the strategic objectives of an organisation are realised. However unlikely it may seem, it is very easy to lose sight of the original objectives of an organisation amidst the day to day operations.


Of course it is important to remain dynamic, but when a strategic objective changes, it is no small thing – hence the separation of policy and procedure as indicated earlier.

The policy provides the framework – or track – along which the operation will be conducted – procedures stipulate the specifics of how things get done.


Without policies and procedures, processes and objectives will in all likelihood become misaligned and the organization will not function optimally – but this is very much environment dependant.


Production environments are usually very reliant on set procedures, processes and the like.


Bureaucratic institutions will always have tons of policies and typically they will even have policies on policies and procedures to decide procedures. This is because such environments have clear hierarchical structures, everybody needs to be told what they must and may not do and the policies and procedures are usually aimed at forcing a specific outcome.


Creative environments will have the minimum structure – these environments rarely need rules about when to do what, as you are dealing with high performance teams and highly motivated individuals who know what needs to be done and how to get it done – not only will there be very little repetition (which makes policy and procedure near impossible) but rigid structure will be in the way of outcome.


2.2. Satisfying governance and legal requirements:


Corporate governance is about the processes, policies, laws and related instruments that direct the administration and control of a corporation.


Corporate governance also includes the relationships among the role players (for example the stakeholders, Board of Directors, Management, etc.) and the corporate goals.


Policies bring legal requirements home –obvious examples being personnel policies relating to leave, working hours etc. Minimum requirements or parameters are provided by legislation, but a policy makes it easily understandable for the layman.


The need for policies to satisfy governance and legal requirements are another reason why they are set at Board level – must countries have legislation in place that holds board members accountable for certain transgressions and deliverables.


2.3. To improve consistency and eliminate discrimination or differences in management ethics between managers:


Managers (at any level) are as individual as the employees they lead.


Individualism is a valued asset in any organization, but it can lead to discrepancies and misalignment in basic operational and management approach.


Policies and Procedures provide a framework within which managers operate and the ensure that basic management ethic and principles are adhered to.


Policies and Procedures also provide a valuable guideline to new managers who are still finding their feet in the organization, or who are new to the management role.


Policies and Procedures also protect managers against malicious complaints of staff when parameters are enforced.


2.4. To manage and regulate change in the organisation:


To survive in the modern business world, an organization needs to be dynamic and adaptable.


The downside to this is that being too “dynamic” will leave an organization chasing its tail with everybody pulling in a different direction – which brings us back to the need to have strategic objectives (one or more of which will pertain to change and direction) backed by policies and procedures that provide the required framework within which change and development will take place.


Many organisations these days not only rely on policies and procedures in this regard – they may even have a manager in the HR department specifically tasked to oversee the change process in the organisation.


2.5. To stimulate a culture of continuous improvement, define a standard of performance and conduct and to regulate processes around this:


There is an old saying in business – if you are not going up, you are on your way down.

Processes such as Six Sigma provide for tools and strategies that focus on continuous improvement in a production environment.


Such approaches are usually brought into an organisation by means of policy.


A policy on continuous improvement does not have to bring a brand name approach into an organisation – but the policy can provide a framework for a procedure that will ensure that work is done in such a way, and targets are stepped up regularly, to ensure that an organisation keeps going upwards, rather than stagnating or slipping backwards.


2.6.To comply with company rules:


No employer can realistically expect his or her employees not to test the envelope – be that starting time or leaving time, the length of a coffee break or the time spent on private calls.


While many aspects of conduct can be considered obvious (i.e. pilfering, sexual innuendo etc.) an employer will always be wise to address those aspects that relate to conduct (pilfering is theft and sexual innuendo is sexual harassment if the recipient rejects or feels uncomfortable with the advances), incapacity etc. in a policy.


In certain instances a procedure may be required as well (i.e. there may be a policy on claiming overtime but the procedure will dictate the criteria that must be adhered to), but compliance to company rules usually just requires a policy that provides a clear framework.


2.7. To build organisational culture, employee enthusiasm and loyalty:


Organisational culture may start with something as simple as a dress code – as specified in a policy.


In larger organisations policies on performance recognition, promotion and similar measures will provide an objective methodology to recognise the top performers in an organisation and not only reward them, but provide targets for the other employees to aspire to.

Such policies also provide employees with a degree of security and comfort knowing that there is benefit in being an “insider” – examples will be a policy to consider internal candidates first when it comes to the filling of promotion positions, favourable consideration for transfer requests etc.


A word of caution here – employers who insist on candidates applying for higher positions instead of at least considering promotions, are setting themselves up for a negative response from their staff – and losing experienced staff.


In the majority of organisations insisting on this approach, internal candidates quickly pick up that the process is abused to bring in buddies or they resent the fact that they have to teach the new boss how to do the job, or that they are considered part of the furniture – after all, Jack is there to provide backup to the new guy…


So I need a policy – what now? The process of developing an effective policy.


1. Articulate the Goal of the Policy


Is there a problem?


Does the problem occur regularly enough – or pose enough of a risk – to warrant a policy?


Once you have determined that a policy is necessary, you need to answer the following two questions clearly:


1. What is the problem?

2. What is the solution?


Your problem statement must be crystal clear – and all the major role players must agree on it. If you cannot clearly articulate the problem you cannot formulate the solution.


To determine the solution to the problem is to formulate the goal of the policy. Use common sense as you determine the outcome you want from your policy.


This is possibly the most critical step in the process, as you must ensure that the role-players all agree on what you want to accomplish if you want to have any hope of agreement and cooperation.


This is where negotiation skills come into play.


The key will be to have the parties reach a compromise that satisfies the majority and still realises the goal of the policy.


When you negotiate here remember that the “how” is negotiable – if the goal becomes the topic of negotiation, you have a problem – either the purpose of the policy was not articulated properly or you are slipping off target.


2. Gather Information


Get all the parties who can make a contribution talking to each other and then get those ideas, points of contention and agreement on paper.


Get all the relevant legislation, directives, rules, best practice info and any other information(such as samples and examples) together and sorted.


Make sure you get inputs and buy-in from the management and staff as early as possible – their inputs will be invaluable.


3. Develop and Write the Policy


3.1. Secure the buy-in for the concept from management;


3.2. Start with the core of the policy – the content that you want to convey in simple words and concepts;


3.3. Speak directly to the people who will be reading, enforcing, and living by the policy – their inputs are key;


3.4. After each paragraph, ask yourself “what if” questions to make certain the policy is covering the basics and the normal exceptions and questions.

Do not obsess over this, however – no policy ever covers every possible contingency – focus on the rule, not the exception;


3.5. Once you have the meat around the bone, add all the extras such as the table of contents, list of abbreviations, background, environment etc.

In larger organisations there will be a unit or experts who know all about the standard structure etc – leave all the look and feel bits in their hands;


3.6. Review the Policy using a small pilot group – fresh faces will be best for this exercise as the SME’s who constructed the policy will be looking at the document through the same eyes;


3.7. Obtain Legal Review of the Policy;


3.8. Keep repeating the process until the everybody – or almost everybody with the exception of one or two persons – are satisfied with the merits of the product.


3.9. Obtain signoff on the Policy;


4. Train staff on the policy


Ideally training should be conducted by the Policy Owner or Policy Reviewer – the attendance register can be used as proof that the staff were trained and conversant with the new policy.


Make sure the staff understand what the policy maker intended – not all trainers are created equal.


Don’t be surprised if questions come up during training that your policy does not make provision for. If the scenario is a genuine exception, deal with it as an exception – but if it identifies a genuine gap in the policy, go back and fix the problem – rather identify and fix now, than have egg on your face later.


5. Deploy the Policy


Deployment will require publication of the Policy and implementation of some form of confirmation that the staff have received and understood the new policy.


Be innovative and try to use at least two or three channels of deployment – and keep that policy available!


6. Monitor implementation and do maintenance


Once the policy is deployed you need to make sure that it is actually implemented – remember people tend to stick with what they know, so there is a good chance people will ignore the new policy if they are not monitored.


Implementation may also run into hiccups – so be ready for those and deal with them immediately.


If the policy is up and running, you will also need to do maintenance from time to time – things change and as they do, you will need to respond to that.


Structure and characteristics of a good policy.


A policy can be a one pager or it may be several hundred pages long (ideally you would not do that though as policies should be concise – if you have so much to put into a policy, rather consider breaking it up into several policies, or if it contains operational information, move that info into a procedure manual)


The one-pager is usually more of an instruction than a policy i.e. a smoking policy – by law you are not allowed to smoke in public places, so no smoking in the office – end of story.


A policy may also have several addendums containing standards referred to, matrixes, measures, protocols, histories etc.


These instruments are usually initiated within the policy, but they will be much more flexible and will need more regular maintenance than the policy, hence they are made addendums that can be maintained in the same manner as a Procedure document.


Operational policies are usually accompanied by stand alone procedure manuals that provide all the details alluded to in the policy.


A procedure manual is also more dynamic than the policy – the authority to make changes to a procedure manual is usually delegated to the operational level as well.


1. So what would we see in the typical policy?


1.1. Letter/Vote of confidence from the Owner or CEO of the Organisation


1.2. Statement of Code / Purpose


1.3. Statement of core beliefs


1.4. Statement of guiding principles


Points 1 to 4 are not prerequisites, but they are a nice touch.


1.5. Document versions:


Policies rarely are drafted and deployed at the first go – hence a record is kept of all the phases of development.


Once deployed, all amendments will be listed – and it will be good practice to archive older versions for the purpose of litigation etc. that may pertain to incidents that happened under the auspices of an earlier version of the policy.


1.6. Document description:


This provides the reader with a concise summary of what the policy is about – the purpose is to allow the reader to establish immediately whether the policy is pertinent to his or her enquiry or situation.


You would for instance not want somebody to study the entire Code of Good Conduct, only to find that sexual harassment is dealt with in a separate and specific policy.


1.7. Business Areas impacted by the policy:


Is the policy applicable to my unit or area of work?


Policies pertaining to matters of employment are usually applicable to everybody in the organisation – but not so with operational policies – these usually only affect specific units or persons and we want to identify those parties immediately.


1.8. Regulatory Framework:


Which Acts/Laws or other industry standards, directives, etc. are applicable to the policy in question?


Typically this would be the “no-smoking” scenario – but again this can become much more complex as there may be several Acts, Directives etc. that may have bearing on the policy – consider for instance a call-centre agent employed by a Financial Institution – any policy pertaining to operations will have to take into account a slew of Acts and Codes of Good Practice.


1.9. Descriptions of Abbreviations, Concepts and Terms:


Always bear in mind that the lingo may be familiar to you – but a policy is supposed to be easily understandable to the layman – a table of abbreviations, concepts and terms ensures that the layman understands what you are saying.


If practically possible, avoid the lingo and slang.


1.10. Purpose and aim of the policy:


No policy should be drafted or deployed unless a very specific need has been identified – bear in mind that no organisation needs to be burdened by unnecessary admin or activity – it is about economy of effort.


If the purpose and of the policy cannot be outline in a few lines, it is probably not a good idea to draft the policy.


Be careful though not to oversimplify or stereotype when outlining a policy – you may end up shooting yourself in the foot in the process.

1.11. Background to the policy:


Where did the need originate?

What will the policy try to achieve?

How will it achieve it?

Any history or other pertinent aspects to consider/note?


These aspects often put the policy into perspective – avoid retelling the Tale of Two Cities here but make sure the context is clear.


1.12. Policy environment:


To which processes, areas etc. will the policy apply and what is the implementation date? (A policy is rarely if ever deployed retrospectively)


Which parties are to be consulted during development and deployment?


A policy may have been deployed prior to the take-over of a company by another – this may void the policy environment or necessitate the recall of the policy and deployment of the policies of the takeover company.


1.13. Policy content:


This is the meat around the bone – in fact it is the bone and the meat and the reason for the existence of the document you are drafting.


Set out whatever you want to state in your policy in a structured manner i.e. if the policy is about the handling of a grievance, state the purpose and application, the process management (who, when, where, how), timeframes, provision of information, further referral, special provisions etc.


Given that this is the most important part of the policy, specific care must be taken that it is unambiguous and complete.


The issue that usually arises when dealing with operational policies is the tendency to address the procedural and operational issues within the policy – this is wrong.


A policy must stand apart from the procedures that flow from it.


A typical example will be where an organisation needs to establish the marital status of a person as part of a business transaction.


Firstly there would be reference to the legislation governing marriages in the policy;

Secondly there would be reference to any Organisational Rules or Directives as noted in the procedure manual.


The Procedure Manual will provide the details of what is to be done with the specifications found in the Legislation, Rules and Directives, how they are to be used, what exceptions will be considered and how they are to be dealt with etc.


If you are dealing with the ranking of sources of data as an example, or you are referring to a risk matrix, you will attach those as addendums in order to ensure the policy remains as a clean framework and that the variables that require regular maintenance are easily accessible as addendums – which operate under the same maintenance rules as the SOP’s.


1.14. Implementation and deployment:


When will the policy come into effect and how will it be introduced to the persons affected?


Outlining the deployment methodology will be of value should there be any dispute around whether or not an employee was aware of the policy in question.


A policy should always be easily accessible to anybody affected by it – and there should be some means to confirm that the policy was brought to the attention of the parties affected.


Make sure that the implementation and deployment makes provision for training, leaves enough time for adjustment to the new policy and that everybody knows what to do, when, where and how.


1.15. Roles and Responsibilities:


This usually refers to the responsibilities assigned to specific individuals, units, organisations, parties or such like – a policy only serves it purpose if the parties affected know what they are supposed to do.


Often this is listed in the RACIS format(Responsible, Accountable, Consulted, Informed, Supporting)


1.16. Limitations and conditions (if any):


This may refer to cases prior to the implementation of the policy or a perfect example will be the limitation of the right to strike of the police and other essential services in the old days.




Methods to deploy policies.


It is imperative to come back to the “why?” of the policy when we consider deployment.


A policy should never have punitive intent – it should have the intent to structure, guide, control, organise or similar.


If you put a policy in place for the right reason and your policy is well written, the business at large will welcome it – problem solved!


As strategy is dependant of execution for success, policies and procedures need to be deployed effectively.


The process of drafting a policy is the start of deployment as the buy-in and involvement of management, subject matter experts, review groups and the like already put the new policy or procedure out there in the populace that will be using the instruments.


We however still require the policy or SOP to be formally adopted – and in the case of a policy, there should be reference to deployment in the document itself.


Formal training sessions and introduction of the policy to the people affected is critical – it allows for familiarisation, questions and a record that staff have been trained – implying they understand and that it is executable.


The next step in deployment will be formal implementation as of a certain date. Retrospective implementation is always an issue – unless you are providing a benefit retrospectively. Implementing a punitive measure retrospectively will never stand up in a court of law.


Where you are implementing changes to a policy or SOP, it is imperative to retain record of the previous versions as those versions will still be applicable to historic cases.


Bear in mind that as humans we are inherently lazy – so reading policies and adhering to prescripts is often a bit of a challenge, as reading through the policy and changing our ways is not something we do eagerly – but for a policy to work we need to be sure the staff read, understand and adhere to the new prescripts – hence the sessions to train and familiarise..


Ideally your contract of employment specifically refers to adherence to all policies and procedures – but it is not a legal requirement as adherence to reasonable prescripts is an implied condition of service.


What you need is proof that employees have been made aware of the policies and procedures and that the employee could have adhered.


Many a disciplinary has failed because the employer failed to prove that the employee knew of the policy requirement, or could reasonably have adhered to the prescripts.


The key issues for enforcement are that:


1) the policies and procedures are reasonable and executable;


2) the policies and procedures have been properly introduced to the business;


3) the policies and procedures are immediately accessible and continuously and consistently applied;


4) that there is some method by which it can be confirmed that the employee was aware, or should reasonably have been aware of the content of those policies and procedures.


5) If a policy requires an employee to act in a certain way, or prohibits certain actions, it is to be expected that a contravention will be followed by disciplinary action – make sure that these are in place and that they are applied consistently.


A word on the application of disciplinary measures:


The seriousness of the contravention will decide the nature of the discipline exercised – progressive discipline is ideal, but some contraventions warrant sanctions such as dismissal i.e. theft, sexual harassment etc.


Ensure that staff are aware of the measures and how they are to be applied – as well as their rights and options available during such a process – and when they feel aggrieved.


Ensure that new employees are introduced to all the existing policies and procedures when they join.

It is good practice to issue an employee manual to an employee on commencement of service and/or to have some form of induction program and record of that.


While it is fairly easy to issue employee manuals to new employees, it will not be practical to issue a new manual to each employee every time there is a change to a policy or procedure.


One option is to print and distribute the amendments, but in this electronic age the most practical is probably to mail amendments to everybody and to make all the amended policies and procedures available on the company intranet, with some kind of confirmation protocol to ensure that there is a record that the employee was made aware of the changes.

Another option is the distribution of a hardcopy of the policy or amendments to everybody concerned and having them sign for receipt.


Other innovative options include linking the notification to the personnel logon process – thus forcing staff to read the policy, and ensuring that there is, by implication, confirmation that the staff member acknowledged awareness of the new or amended policy.


The world changes and policies need to adapt – policy maintenance.


Policy Maintenance is not as straightforward as the maintenance of a Procedure Manual, since the authority for maintenance/approval resides at a higher level.


What remains unchanged is the need to update and maintain the Policy.


If an organisation is big enough to warrant a Policy on Policies, the Policy on Policies will usually outline the process and frequency to update a policy.


In most instances the procedure to update a policy will be similar to the procedure followed to draft a policy, with the exception that some of the steps and content may already have been covered (typically the abbreviations, limitations etc.)


When should the maintenance take place?


Typically any change to the legislation, rules, directives and such like will mandate a revision of the policies that are dependent on them.


Any major change to the operating environment will also necessitate review – here we think or mergers, restructuring etc.


It is also good practice to evaluate policies on a regular basis to ensure that they are still current and effective/applicable – do not become complacent because the environment is seemingly unchanged – global warming should be enough of an example of subtle and consistent change that we are ignoring.


Do we need a policy on policies?


The short answer to this question is: Do you issue, amend or repeal enough policies within your organisation to create a requirement for the standardisation of the structure and deployment of your policies ?


This is usually not the case with smaller organisations where a policy could be a one-pager, but the bigger the organisation, the more probable the need for comprehensive policies that follow a standard development and deployment process and that has a standard structure.


What would the Policy on Policies state?


A process and framework for drafting policies will be provided, usually referring to the following as minimum requirements:

- Document versions;

- Document description;

- Business Areas impacted by the policy;

- Descriptions of Abbreviations, Concepts and Terms;

- Purpose and aim of the policy;

- Background to the policy;

- Policy environment;

- Policy content;

- Implementation and deployment;

- Roles and Responsibilities;

- Limitations and conditions (if any)


The aim of a Policy on Policies is to ensure that policy development is efficient and effective, that there is transparency and accountability in all phases of development and implementation/repeal and that legal and procedural requirements are met in a consistent manner.


As with all other policies, the Policy on Policies must state from which date it is to be implemented – it is not practical to the implementation of this policy for the policy to be implemented retrospectively.


What will be different between the Policy on Policies and the other policies, is that a Policy on Policies will place emphasis on delegation of authority and the framework that must be followed in the other policies (This basic framework was extensively discussed earlier) and it should outline issues such as reviewing cycles and procedures as well as how implementation and rollout should be dealt with


Criteria for the evaluation of a policy


The most important question to be answered to establish whether a policy is any good, is whether the policy is practically executable and adds value to the operation of the organisation – as originally intended.


1. Policies must be developed with a specific end-result in mind.


This means the policymakers must have a clear vision of what they want to achieve – which implies a clear understanding of the problems or issues, facts, limitations, legal and other requirements, and a practical and to-the-point solution that will become the core of the policy.


The intended end-result will decide the nature and content of the policy.


2. Practical


There is absolutely no sense in drafting a policy that cannot be executed because you do not have the required resources or technology or any other elements required to execute the policy.


Often the shortcoming will not be that obvious during the planning phase but you will run into a brick wall during implementation (if you do, you may want to go back to your pilot and even the SME’s and ask yourself why you picked the wrong people here or why your methodology failed)


A typical example is usually found in a risk mitigation measure that is implemented that slows production to the point of standstill – either the wrong SME’s, or the SME’s did not actually agree on the measures and impacts, or the review/pilot was a failure.


3. Executed


Again this seems to be stating the obvious, but a policy that is not executed is a waste of time. Be careful that you do not draft policies for the purpose of completing the tick boxes.


If you draft and implement a policy and nothing changes, you just wasted your time as your policy was either not needed or flatly ignored.


4. Improvement


The issue of improvement is two-fold:


1. Did the policy improve the situation?


If things work better after implementation, you have moved in the right direction.


2. Can there be further improvement?


Hopefully not immediately – if you can immediately improve on the policy, you need to do so – but we will hope that for a while after implementation at least, things will be optimal.


Bear in mind however that policies must be reviewed from time to time – and even the best of policies are updated and upgraded from time to time.


Our environments change – and that means that the policy needs to change as well. Legislative changes will typically necessitate a change in policy – but as your processes improve you will need to update your policies as well.


When you review a policy, take the opportunity to relook the policy from scratch – you may well find that the policy is not even required anymore.



Causes of Poor Policy Development.


Causes of poor policy development include:


1. A failure to consult the people who will be affected by the policy or who will implement the policy;


2. A breakdown in communication between parties who are involved or should be involved in the policy formulation process;


3. A failure to define the problem accurately, or an oversimplification of the problem/issue(s);


4. Policy makers are unable to reach agreement over basic facts;


5. Policy makers are biased in their research for the policy formulation process (remember the legal department?);


6. Policy makers take a different and conflicting position on key aspects of the policy (split down the middle);


7. Prejudice and stereotyping by policy makers – this is usually because the problem/issue is being oversimplified or due to lack of proper research;


8. A change of key players in the policy development process before it is completed (hence the need for version control);


9. A lack of understanding of the importance of policies in organisation management (this is usually a failure at executive level)


So how do I ensure the policy will work?

1. Write a good policy.


Before you start writing, know why you need the policy, what you want to achieve with the policy and how you intend to do that.


Know the existing frameworks – you cannot write a policy that clashes with the legislation governing your business.


Involve the right people to give the right inputs from the start. You need subject matter experts to tell you what can and what can’t work, you need the governance and admin boffins to make sure your policy passes all the tests, you need to know how the staff affected are going to respond.


More often than not a poor policy finds its birth in the ego of the person drafting the policy.


The moment you think you know it all, you are in big trouble…

2. Review the policy in-house.


Select a small pilot group to read the policy, ask any questions they might have about the policy and confirm what they understand the policy to mean.

Don’t get annoyed or discouraged if they kick holes in your baby – the idea is to test thoroughly so that the product doesn’t fail when it hits the real world.


If necessary, rewrite the policy based on the feedback.


Fill the gaps, clarify the grey areas and cut the fat.


Remember that when the policy gets tested, any weakness will be exploited.


A policy has no value if intent and understanding don’t match. Very importantly, keep it short and sweet – the more you ramble, the more opportunity you create for confusion and creating loopholes – cut the fat.

3. Obtain Management Support for the Policy.


Review the policy with the managers who will have to lead and put into effect the policy (the manager may not have been the SME you involved during formulation).


You will want to have their support and ownership of the policy – in fact, you should have secured their buy-in at the identification of the need for the policy.


If the manager is calling BS on your policy, you will never get the staff to support it.

4. Obtain Legal Review of the Policy.


If the policy has legal implications, or can lead to litigation, have an attorney review the policy.


This may be a good idea even if you have an in-house legal team as they may be looking at the policy in a one-eyed manner (please just avoid the lawyers who specialise in giving you the feedback they think you want to hear).


Legal implication is a broad concept – we are talking labour disputes, contractual disputes, legislative contraventions etc – often things we would never even have dreamt of.

5. Deploying the Policy.


Ensure that you have a deployment strategy that ensures that all employees / stakeholders are made aware of the new policy, that the employees have an opportunity to familiarise themselves with the content and have been trained on it, and that all their questions pertaining to the policy are answered. (remember the idea of a policy is to make things easier for all – if the employees are negative, it is imperative to understand why)


It is a good idea to include the policy in your employee handbook and to make it part of your New Employee Orientation.


As indicated earlier it is always a good idea to place policies in your Intranet or in a policy folder on the computer network’s common drive, or by any other means such as hardcopy distribution.


Determine whether you will want to distribute the policy by additional methods.


You will also want to archive and date former policies that this policy replaces. You may need them for legal or other reference in the future.


Remember that a deployment is only a success if the majority of the staff understand and buy into the policy.


Putting together a good Procedure document.


1. Procedures are about details


A good procedure manual allows a layman with no experience to perform an operation simply by following the step by step instructions in the Procedure Manual.


The purpose of the Standard Operating Procedure or SOP is to ensure consistent and quality output.


2. How to write a good SOP


1. Format


There is no single format for a SOP, but the most common options are usually either noting the steps or, noting steps hierarchically or, using a flow chart.


So which to use?


Noting simple steps are ideal for simple processes. The rule of thumb here is that if the process or procedure is less than ten steps, noting and outlining the steps is fine.


Hierarchical steps work better when the process is more complex and you need to clarify subroutines and processes, define terminology etc.


Typically this is used where there are multiple options per step, different actions are taken based on different outcomes etc.


Flowcharts are ideal if you want to visualise the process – it is also standard to most software used to generate SOP’s.


A combination of options is also fine – remember that we do not process information in the same way – some people are fine with reading, some need to hear, some need to do and some need to see – so using a combination of approaches will have definite benefits.


2. Audience


Considerations here will include the size of the audience, experience, language and technical abilities.


It is critical to pitch the SOP at the right level.


The SOP for a simple cleaning operation on the factory floor will be pitched very differently from the SOP used to assemble complex electronic equipment by hand.

You do not want to lose your target group because you bore or irritate them, nor do you want to pitch over their heads.


3. Skill and understanding


Make sure the right people are writing the SOP.


Too often drafting something like an SOP becomes a contest of ego’s – it becomes a tussle about who is right and who knows the most.


Remember why you are drafting the SOP – it is about ensuring something is done in a consistent and efficient manner – so don’t take anything for granted and focus on achieving that purpose.


If one person is questioning something you can be sure that there will be others – but at the same time do not try to deal with every exception – remember that the Policies and SOP’s deal with the rule – not the exception.


Drafting a SOP is about nuts and bolts, so ensure that the SME’s are 100% satisfied with the document – if you do not have the correct level of skill, get the right people involved.


4. Purpose


Why are you drafting the SOP?


Start with the basic questions:


Is the SOP going to make something better?

What is it going to make better?

How is it going to make it better?

Does whatever the SOP is about, happen enough to make writing a SOP worthwhile? (we do not write policy and procedures for exceptions – human minds, discretion and experience will deal with the exceptions).


Understanding the problem is critical to writing a policy or an SOP.

Without a clear problem statement you cannot start working on the solution.


Always come back to the question “what are we trying to achieve?”.


If the answer is not crystal clear, you are in trouble – start over!


5. Core elements


5.1. Form


The basic elements you will expect to see in any SOP are the following:


5.1.1 Title page:


Keep the front page clean and concise. If somebody looks at the front page you want them to know whether this is the SOP they are looking for within 20 seconds or less.


Display the following:


The title of the SOP;

An identification number if SOP’s in the organisation are catalogued;

Date of this revision;


5.1.2 Review Record:


Keep this short and sweet – the date of the revision and who revised the document. If you want to record the reason for the revision, do so in an addendum.


5.1.3 Approval Page:


Who, when and title – we need to be sure that the changes were properly authorised.


Usually there will be three people involved – an SME, supervisor and manager.

5.1.4 Table of Contents:


Always have a table of contents so that a reader can identify where they will get what they are looking for.


As a rule of thumb make sure you list at least the sections and sub-sections in the SOP but try to keep to a page at most.

5.2 Content


This is the meat and potatoes.


5.2.1 Scope and applicability:


Who does this apply to? When? Why?


Ensure that this section clearly outlines the purpose of the process, limitations (legislation, policies etc). It must be clear who this SOP applies to and what the SOP wants to achieve.


5.2.2 Methodology and procedures:


This is the nuts and bolts of when, where, what, how, why.


Remember the intention is that a layman must be able to execute the procedure following the SOP – or rather the auditors must be able to do so without a list of 20 findings.


You may want to use a flow diagram and couple that to a table of detailed instructions, expected outcomes and responses.


5.2.3 Equipment, Supplies, Health and Safety, Exceptions etc:


Make sure that the SOP clearly records what you need, where to get it, all cautions, deviations etc that the user may encounter.


You may want to link this to your table of instructions – step, instruction, elements required and where to get those, cautions, expected outcome, responses, exception handling.


5.3 Measurements and QA:


If you can’t measure it, you have wasted your time. If you cannot establish improvement, you have wasted your time.


The purpose of an SOP is to improve a process – there must be clear measurements of what, when, how much, how well etc.


You SOP must clearly define measures and there must be reference to QA – even if you are referring to the QA policy and SOP.


5.4 Reference Page:


Ensure that all applicable legislation, policies, procedures, measures, models, matrixes etc that are applicable to your SOP or referred to, are listed here – and ensure that if you refer to it, it is available to the user to access.

This means that you must have a central repository for all your policies and SOP’s – and that all the legislation etc that will be applicable, is there as well.


Remember that the SOP is the bible the user will have in hand – make sure it is comprehensive. A user will not go and study the legislation – that is a fact of life – ensure that what they need to do in terms of the legislation is clearly outlined in the content.

5.5 Glossary:


Ensure that all the abbreviations, acronyms, role-players, measures, matrices etc are clearly referenced so that when the user comes across it in your procedure, they can come to the glossary and understand what you were referring to.


The more technical the procedure, the larger your glossary will be – don’t take shortcuts here – make sure it is complete and accurate.


A word of caution:

If you are using terminology defined elsewhere such as in legislation do not deviate from that definition!


5.6 Addendums:


Anything that needs to be fleshed out, but will bloat the SOP unnecessarily, can be placed in the addendum.


The reasons for revising the SOP may be recorded in an addendum – this would include legislative changes, process changes etc – often recording the reasoning behind changes can be critical in understanding the change itself.


The measures used, QA processes applied etc are perfect candidates to be included in addendums.


6. Do your homework


Make sure that you have gathered all the relevant information before you start drafting – this means make sure you have every scrap of legislation, regulation, policy, SOP, guideline etc that you can lay your hands on.


Make sure you know the existing processes and challenges, the strategy, the plans for the future, that you have the inputs from all the SME’s and anything else that will impact the SOP you are drafting.


7. Short and sweet


Remember that nobody reads a SOP for enjoyment – make sure it is easy to read, makes sense as pertains to structure and content, it must be complete but keep it lean – don’t waste words or time.


Remember that we do not all process information in the same manner – use all the options at your disposal – use diagrams, pictures, descriptions – make sure the message gets across clearly.


8. Review and revise


Have as many people as possible go through the document and provide feedback – I prefer the draft to be put to the test as well, so have people of varying skill apply it in practice and see whether you get the result you want. I also suggest that you do positive and negative testing here – don’t just check that it works correctly – throw a spanner in the works and make sure that your SOP catches the exceptions and routes them correctly.


Do not skimp on the review and revise phase – if you rush past this, your SOP will fail and you will be doing everything over – and your credibility will have suffered.


9. External review


Run your SOP past people outside the process – make sure your legal department signs off on it so that you have confirmation it is aligned to the existing frameworks, get the internal auditors and your risk and forensic guys to give their stamp of approval – you will rather deal with them when you are planning than when they are taking shots at you.


Make sure you are aligned with whatever strategic and other initiatives are in the pipeline.


10. Train and implement


The same rules that apply to the implementation of a policy, apply to the implementation of a new or revised SOP.


Make sure that all staff affected are thoroughly conversant with the SOP and make sure there is a record of some kind of their awareness.


Implement the SOP from a specific date and monitor for effectiveness and any changes that may be required.



3. Procedure Manuals are living documents


By implication this means that a Procedure Manual is a living document that requires regular updating, effective version control and effective archiving.


The operational managers and supervisors are the custodians of the procedure manuals. They need to make sure that the procedure manuals are current and that all staff are thoroughly conversant with the manuals and the updates.


If the environment or processes change, the procedure manual must change to reflect that.


It is good practice to record the changes and the reasons for the changes in an addendum to the SOP and archive the previous versions.


This may seem obvious, but make sure that all changes to the procedures are clearly communicated to the staff affected and make sure they understand the changes and from when they will be in effect.


4. Procedure Manuals cannot contradict what the Policy states


The Policy usually gives birth to the Procedure Manual.


Using the earlier example of the policy on the establishment of marital status, the Policy provided the parameters – the relevant legislation, directives and rules were referenced – now the Procedure Manual opens those documents and details what they say and how it should be applied.


Practical rule:

If the Procedure Manual is properly drafted, the operator will never need to refer to the legislation etc. him or herself – all the required references will be in the Procedure Manual, as will be an explanation of the wherefore and why in layman’s terms.


Reality check:

People almost never read the policy and even less are going to read the legislation – that is a fact of life. If you want to make sure they do what they are supposed to do, make sure that you communicate all the wherefore’s and why’s in some way – and that is why we draft our SOP’s to be user-friendly.


If you set requirements in the SOP that are contrary to that in the Policy or any other superseding document, your SOP will either be void on that point, or void in totality.


If you have an issue with what the policy states, you need to review that policy – you cannot fix the shortcomings of a policy with the content of a SOP – the SOP can at best compliment the Policy and put meat around the bone.


5. Maintenance of Procedure Manuals is usually a delegated authority


As indicated previously, Policies are approved on Executive level.


Procedures are not about the framework – they are about the nitty-gritty – and if you want details on that, you go to the people doing the job.


As a rule the supervisors will maintain the SOP, while the Managers will sign off on the changes as they will remain accountable for the procedures that are followed and the results thereof.


Maintain the SOP regularly – preferably keep it up to date on a continuous basis – a dated SOP is not worth the paper it was printed on.



Applying policies and procedures to ensure things get done right.


Policies and Procedures mean nothing if they are not implemented successfully.


When policies don’t get off the ground it can be because of several reasons such as:


1. Writing a policy simply because that was the administrative requirement.


This happens far too often.


There is a governance requirement that there must be a policy in place, so we write a policy in order to sign off that good governance has been adhered to. The result is a repository full of policies that nobody ever looks at until it hits the fan – and more often than not we then realise that the policy is BS and all too often the policy gets used against us.


2. Non or token consultation with the people who will be affected by the policy or who will implement the policy.


Often this goes hand-in-hand with the “administrative requirement” blunder.


When we write a policy because we must according to our Policy on Policies or some other bureaucratic requirement, we often only consult because we need to show an healthy audit trail and we involve the people who will not be difficult.


Big mistake…


As mentioned earlier, ego can also be an obstacle here – if you want to prove you are clever, do not do it writing an SOP or a Policy – do a thesis – it will allow you to expound on your own theories.


If you are not going to remain objective and focussed on resolving the problem statement through providing a consistent and efficient solution, the result will be a the policy is either a white elephant or it cannot be implemented effectively.


3. A failure to define the problem accurately, or an oversimplification of the problem/issue(s), or failure by the Policy Makers to reach agreement over basic facts, or they are biased or short-sighted in their research, or they different and conflicting position on key aspects of the policy.


This mostly happens because the wrong people are driving the process for the wrong reasons – so they disregard the issues in order to get the policy signed off and we have a worthless document that will in most instances complicate matters exponentially.


Clearly define the problem;

Get the right people onboarded to define and implement the solution;

Complete the cycle;


There are no shortcuts – do it right or don’t waste the time doing it at all.


4. Resistance


Resistance can – and should – be expected whenever we talk about change.


What is important is to understand the reasons for resistance.


If SME’s tell you that the policy or SOP will cause critical failure, it is time to listen.

If “the masses” demur proper control, you are probably doing something right.


4. Procedures more often than not fail if they are not practical or outdated.


Audits usually pick this up and then you have egg on your face.


In order for Policies and Procedures to work, they must be current – Policies must be sleek and to the point, Procedures must be detailed and easy-to-follow.


Make sure that there is a clear requirement in your policies and procedures that state when they must be reviewed – if you review earlier that is fine – but make sure that there is a minimum review window that is adhered to.


Be open to input on the content of the Policy or Procedure – despite the best efforts of the best minds you may still get it wrong – it is better to fix the problem than to stubbornly disavow yourself from the problem.


5. Failure to train and deploy properly


You cannot deploy a policy before you have trained all the staff involved in what needs to be done, when, where, why etc.


If you fail to train, or if the training fails, you cannot implement – end of story.


If you cannot show that staff have been properly trained, any attempt to enforce the policy or procedure will fall flat on its face when challenged in labour procedures.


The proper deployment of policies and procedures are key to success – make sure that everybody is aware of the Policy or Procedure and that they familiarise themselves with it – and have some record or proof that everybody did familiarise themselves with the content.


Make sure it is clear from when the policy or procedure comes into effect, monitor the implementation, ensure any adjustments that may be required, are implemented.


6. Bad admin


Retain your version records and archives.


When it comes to audits or litigation you want the historical information available to show what was applicable when and also to show the history and thinking behind changes.


Keep record of the meetings held with SME’s, review meetings etc. Keep the records of training sessions and feedback following deployment – when you get put on the spot you will value the time spent on proper admin.


7. Not applying your policies and procedures


Policies and procedures mean nothing if you do not apply them consistently.


Ensure that you have mechanisms in place to monitor that standards are adhered to, do your QA and follow up on deviations.


Unfortunately deviations will sometimes require disciplinary intervention.

Apply your discipline progressively where applicable and always ensure you are consistent in your discipline or your corrective measures will fail when challenged in labour structures or litigation.





If you write a Policy or a Procedure for the right reason, identified the problem and the solution and you completed the cycle properly, your Policies and Procedures will add value to your organisation and improve efficiency.


Remember the purpose of these documents – they are there to make things better – if they are not clearly understandable and the organisation doesn’t want to buy into them, your efforts are a waste of time – and always remember – there is not replacement for the application of the human mind – even if you do not have a Policy stating that you must use yours!

Basic Policies and Procedures

  • ISBN: 9781310323768
  • Author: RadixalX
  • Published: 2016-04-02 15:20:10
  • Words: 11723
Basic Policies and Procedures Basic Policies and Procedures