Policy and procedure structures

Ross Woods. 2018. Rev. 2020
With thanks to Tony Buchannan

Policy development and implementation is a system like other organizational systems such as human resources, finance, and safety.

Policy and procedures are hierarchical; authority flows downward and accountability flows upward. Lower level items must comply with those at higher levels. The higher in the hierarchy, the more requirements tend to be broader statements of principle; an organization's internal policies are more difficult to change because they must be approved in a board meeting. Conversely, the lower in the hierarchy the more requirements tend to be specific statements of implementation and relatively easy to change. Local managers need to be able to devise local systems and improve them to get better efficiency, without getting board approval.

Highest levels

All approaches to policy have the following hierarchy of highest levels:

1. Legislation: federal, state, and local. (International law seldom affects organizational policy.)
2. Government regulations (issued to implement legislation)
3. Parent organization, existing contractual obligations, accreditation requirements, etc.
4. Articles of Incorporation
5. Bylaws

Court decisions can affect all the upper levels. Courts can rule an item of legislation unconstitutional, and that a government regulation is unsupported by legislation. Courts can also rule that a contractual arrangement does not apply. In some legal systems, a court precedent becomes enforceable as a part of case law.

Courts do not rule against Articles of Incorporation, because governments approve them as a condition for incorporation. Courts usually have nothing to do with bylaws because they are an internal matter of the corporation.

Board meeting procedures

All approaches need procedures for boards to hold meetings. These answer questions such as: How often does the board meet? Who calls meetings? Who is responsible for keeping minutes? How many is a quorum? How many needed to pass a motion? Who presides? What if the chairperson can’t attend?

The bylaws usually contain them although incorporation laws in some jurisdictions require that the Articles of Incorporation contain them. Organizations have several other options. Some boards have handbooks of board policies or "standing orders" that include meeting procedures.

Other meetings within the organization need written meeting procedures if they have significant powers. For example, educational bodies have academic councils, and large corporations delegate significant powers to divisions or regional governing bodies.

General procedures

Procedures describe implementation and are normally written as sets of steps. They are also hierarchical:

1. Written procedures: Procedures should be written when they have obvious legal or insurance implications, such as safety procedures for high-risk tasks. In the most legally sensitive cases, they should be approved as Standard Operating Procedures (SOP) as if they were policy.
2. Other written procedures
   1. Training and induction manuals. Training or induction manuals set forth procedures as staff should follow them. This is quite common for procedures that have legal or insurance implications.
   2. Written procedures on signage. Some kinds of procedures are given as signs on doors and fire equipment, safety signs, and posters of evacuation procedures. Some procedures are legally required to be presented this way.
   3. Instructions on forms. The procedure is to fill in a form and submit it to someone or file it as a record. In these cases, the instructions at the top of the form are part of the procedure. This is an excellent practice because the instructions are located where users are more likely to notice them and to follow them.
   4. Staff meeting minutes. These are (or should be) periodically collated into a coherent staff handbook.
3. Oral procedures. This approach works best for work for local procedures with minal legal risk.

 

Different approaches

Below are a range of different approaches to the presentation policies and procedures, listed as hierarchies. Some have only one level while others have more.

Approach 1: Policies include procedures.

1. Policies and procedures: The policies are highly procedural, so policy does not need to be separated from procedures.

Comment: This approach suits small organizations because policies and procedures are easy to change. It is difficult in a large organization because it becomes more difficult to change procedures. It is impractical in a large organization because it presumes that the board or owner must approve every change of procedure.

Approach 2. Policies are principles and have implementation steps.

1. Policies and procedures: Each policy is a statement of a general principle. Under each one is set of steps for implementation.

Comment: This is adequate in small organizations, especially if the CEO is the owner or Managing Director. The policy statement is broad enough to guide practices, but it still has a procedure. Policies and procedures are easy to change in a small organization. It is impractical in a large organization for the same reason as Approach 1.

Approach 3: Board sets policy. management set procedures

1. Policies set by the Board
2. Procedures set by management

Comment: This is generally an excellent approach. It is easy to use, but often impractical in more complex organizations.

Approach 4: Tiered authority

1. The Board sets overall policy.
2. CEO approves organizational policies.
3. Senior staff or branch managers under the CEO set policies for their area of authority.
4. Local managers set procedures.

Comment: Large, complex organizations usually need this approach because it is impractical for the board to approve all policies.

Approach 5: CEO issues all policy and procedures.

The Board authorizes the CEO to issue all policy and procedures.

Comment: This is potentially dangerous because the board is excluded from policy approval, although it is responsible.

Approach 6: Policy is embeded in the software.

Policy-based software only does what the policy allows. What the policy says is the same as what people may do. For example:

1. The software follows the structure of an organization, with each level having a different level of authority.
2. People can see only what they are entitled to see, and can do only what they are authorized to do.
3. The stages in performing tasks are clearly defined in terms of what is to be done and who is to do it.
4. If a required field on a form is not filled in, the software wil not accept the form.
5. People cannot make unauthorized "adjustments" of information submitted by other people.
6. The software only allows permitted responses.

Policy-based software has the following advantages:

1. Although it requires a complete and consistent definition of a business' processes, guidelines and procedures, it re-uses and duplicates an expert’s knowledge and processes.
2. When problems occur, the software intervenes at computer speed, not at human reaction speed.
3. It prevents depending on humans to remember to do tasks.
   • When a task can be automated and must be done on time, the computer can do it without human input.
   • Some tasks must be done on time but cannot be automated, usually because they require human judgment or personal authorization. In these cases, the computer can issue a timely reminder to the human operator to do it.
4. The software can respond to trends in data or user inputs. (It can apply “if-then” conditions to operational data.)

Comment: Where possible, policy-based software is an excellent approach and highly recommended.

It does, however, carry operator risk. Even if the software works perfectly, it won't help if people put in bad data. For example, an operator might assume, It can't be important if it's easy to do, so it doesn't matter if we make a mistake. This is a case of Garbage in, garbage out. This in turn gives rise to the question of how easy will it be to undo an error.

Adapted from "What Is Policy and What Can It Be?" Andrea Westerinen, VP of Technology, Senior Architect and Manager, Cisco Systems, IEEE Policy 2003 Conference.