Policies, Processes and Procedures: When Each Matters
A project gets told it cannot do something because of policy, and the conversation stops there, because policy sounds immovable. A useful proportion of the time the obstruction is not a policy at all, and knowing the difference is worth a great deal in an organisation where everything defensive gets described with the same word.
Section 2.2.3 of The Standard for Project Management sets these out as three distinct kinds of organisational rule, and the practical value of separating them is that each is owned by different people and changes on a completely different timescale.
Three different kinds of rule
A policy says what must be true and usually why. All personal data is held within a stated jurisdiction. No lone working in confined spaces. Capital above a threshold requires board approval. Policies are short, they are owned at a senior level, they are frequently driven by law, regulation or insurance, and changing one is a governance exercise measured in months.
A process describes how work flows: the sequence of activities, the hand-offs, who is responsible at each stage. The change control process, the recruitment process, the release process. Processes are owned by a function, and changing one is a conversation with that function, usually measured in weeks.
A procedure is the instruction for performing one task: the steps, in order, for a person doing the work. How to isolate the machine, how to raise a purchase requisition, how to run the month-end reconciliation. Procedures are often owned close to the work, they are the most numerous, and many of them can be changed by a team leader in an afternoon.
Why the distinction saves time
It tells you who to ask. A policy question goes to whoever owns the policy, and the answer is frequently a considered no with good reasons behind it. A procedure question goes to a supervisor who may well say yes on the spot. Directing a procedure question at a governance board wastes six weeks and a great deal of goodwill.
It tells you what is possible inside the window. Projects have dates, and knowing that something takes months rather than days changes the plan rather than the request. Where a genuine policy stands in the way, the project designs around it. Where a procedure does, the project asks.
A line change held up by a laminated card
A manufacturer was changing a sub-assembly line to introduce a new fastening method. The change needed operators to perform an additional check at one station, adding about eleven seconds to the cycle, which was acceptable to everybody.
The change was refused, and the reason given was policy: the company's safety policy prohibited operators from reaching into the fixture area, and the new check appeared to require that.
The policy said something narrower. It prohibited access to the fixture area while the machine was energised, which was a sound rule with an obvious basis. What prohibited the new check was a procedure: a laminated card wired to the guard handle, written when the station was commissioned, that set out the isolation steps and did not contemplate any operation between cycles.
The card had been there for nine years, greasy and curled at the corners, and had acquired the authority of a policy through nothing more than age and lamination. The project manager took about twenty minutes to establish where it came from, and the procedure was revised by the shift engineering supervisor, reviewed by the safety adviser and reissued inside a fortnight, with the check performed between cycles under the existing isolation rule.
The original refusal had been sincere. Everybody on the floor genuinely believed the card was policy, because nobody had looked at the policy itself in years, and it hung framed on the office wall where people stopped noticing it.
Asking the right question
Ask what the rule is called and who owns it. Two questions, both innocuous, and between them they establish which kind of rule you are facing and who can change it. Where nobody can name an owner, that is informative in itself, and it is often the point at which something turns out to be a habit rather than a rule.
Read the actual document before designing around it. Rules get summarised as they pass between people, and the summary is usually more restrictive than the original. Reading the source takes ten minutes and frequently reveals a narrower prohibition than the one you were told about.
For a PMP® candidate, what matters is that the three differ in scope, ownership and how they change, so a scenario about an organisational constraint is asking what kind of rule it is. A response that redesigns the solution around an unexamined prohibition may be designing around a procedure. A structured PMP exam preparation course takes apart situations where a project is blocked by something nobody has looked up.
The next time you are told something is not allowed, ask for the document. Not to challenge anybody, simply to read it. The answer that comes back will either give you a genuine constraint to plan around or a short conversation with somebody who can change it, and both are better than a refusal with no source.
Interested in going further?
A great deal of what blocks projects is a rule of the smallest kind wearing the authority of the largest. Omega's PMP® Exam Preparation works through organisational constraints and what can actually be changed.
Policies, processes and procedures are described in The Standard, published with the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A081: Tailoring Processes Without Losing Discipline
A008: Why Processes Came Back in PMBOK 8
A037: Quality Is Designed In, Not Inspected In
A160: Qualitative vs Quantitative Risk Analysis
A007: The Standard for Project Management vs the PMBOK Guide
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
