Why Process Development Matters, and Why Most of It Starts in the Wrong Place

Ask ten companies whether their processes are documented and most will say yes. Ask to see the documentation and you will generally be handed something written two or three years ago, by someone who has since left, describing how the work was supposed to be performed at the time. Ask the person actually doing the job to walk you through it, and the account will differ. Not because anyone is being difficult, but because the work changed and the document did not.

That gap is what process development is for. It is also why so much of it fails to produce anything anyone uses.

What process development actually means

The term gets used loosely enough to be almost meaningless, so it is worth being specific. Process development covers the full sequence of establishing how work gets done in an organization, finding where that is inefficient or ambiguous, agreeing what it should look like instead, and producing the documentation and training that let people work the new way consistently.

Read that back and notice how much of it is discovery rather than design. Four of those five components are concerned with the process you already have. Only one is about the process you would like.

The industry has this backwards. Most process engagements open with a workshop about the target state, produce a set of standard operating procedures describing it, and treat implementation as a communication problem. This is comfortable work. It requires no interviews with people who might contradict you, and it produces a deliverable that looks impressive. It also tends to describe a company that does not exist.

A word about the statistics you will see quoted

If you research this topic you will quickly meet a set of confident figures. Employees waste a fifth of their week hunting for information. Poor documentation costs the average business some precise-sounding sum per employee per year. Companies with documented processes grow faster than those without.

These are worth treating carefully. A great many of them trace back through blog post after blog post to a survey nobody can locate, or to vendor research with an obvious interest in the answer, or to a study from the mid-2000s about paper filing. The habit of citing them is one of the reasons process consulting has a credibility problem, and we would rather not add to it.

What can be said with reasonable confidence is narrower, and still enough to make the case.

McKinsey's 2012 study of social technologies estimated that interaction workers spent around 28 hours a week writing email, searching for information and collaborating internally, and that cutting information-searching time by roughly a third would return about 6 per cent of the working week. The figure is now well over a decade old and predates the current generation of collaboration tools, so treat it as an indication of scale rather than a current measurement. It is a real published estimate from a named source, which already distinguishes it from most of what circulates.

On the risk side, SHRM puts the cost of replacing an employee at 50 to 200 per cent of their annual salary depending on seniority. That number is about recruitment and lost productivity rather than documentation, but it is the right order of magnitude for what a departure costs before you account for the knowledge that leaves with the person.

The quality standards moved in the same direction. The 2015 revision dropped the mandatory quality manual and the six required documented procedures that the 2008 version specified, replacing them with a general obligation to maintain the documented information necessary for the system to be effective, with the organization deciding what that means. The standards body concluded that mandating volume produced documentation for its own sake. That is a reasonable inference to carry into your own business.

Why documentation-first engagements fail

The failure is mechanical rather than mysterious. A procedure written from leadership's account of the process will be wrong wherever the real process has drifted, and the real process has always drifted. The people who perform the work read the document, recognize that it does not describe their job, and go on doing what works. The document is now both inaccurate and ignored, and because it exists, the organization believes the problem is solved.

The second failure is length. We have inherited procedures running to eighteen pages that were technically complete and practically useless, because nobody under time pressure reads eighteen pages to settle a question. Length is not thoroughness. A procedure nobody opens documents nothing.

The third is sequencing, which is the one that matters most and gets the least attention. Training built alongside documentation drifts away from it immediately, because two people writing two things at two times produce two different accounts. Training built from the documentation cannot drift, because there is only one source.

The order the work should go in

There is a sequence that holds up, and each stage exists because the next one needs its output.

1. Map the current state

   Interview the people who perform the work and document what actually happens, including the workarounds and the informal approvals. This produces a map a room full of people can stand in front of and argue about productively.

2. Identify the gaps

   With the real process visible, the bottlenecks, the duplicated effort and the steps with no clear owner become obvious. They are usually obvious to the people doing the work already. What they have lacked is a way to show anyone.

3. Define the learning needs

   Establish what each role must actually be able to do, before a word of documentation is written. This determines the scope and depth of everything that follows, and skipping it is why so much corporate documentation manages to be simultaneously too long and insufficient.

4. Write the procedures

   Now the SOPs, written to the specification the previous stage produced. Authoritative enough to settle a question, short enough that someone can find the answer without reading a chapter.

5. Build the training from the procedures

   Build it from the procedures rather than alongside them. When the training is derived from the documentation the two cannot contradict each other, and a change to the procedure has an obvious consequence for the training.

Documentation sits fourth, not first. This is the part clients find counterintuitive, and it is the single largest determinant of whether the work produces anything durable.

When it is worth doing, and when it is not

Process development earns its cost under fairly specific conditions. It is worth doing when a departure or an extended absence would remove capability nobody else has; when onboarding depends on who happens to be free to explain things; when the same question keeps being escalated because no one can point to an answer; when you are about to change a system and need to know what the current one is actually doing; or when you suspect a bottleneck but cannot demonstrate where it is.

It is not worth doing because a certification requires a binder, or because a competitor has an operations manual, or because it feels like the responsible thing for a company of your size to have. Documentation produced to satisfy an obligation gets read by the auditor and nobody else.

It is also worth being honest about scale. Below roughly twenty people, most of this can be handled by the founders writing things down as they go. The value builds somewhere between fifty and a hundred employees, when the founders stop being able to hold the whole operation in their heads and the informal transmission of knowledge starts dropping things.

What good looks like

The test is not whether the documentation exists. It is whether a new hire in week two can find the answer to a real question without asking a colleague, and whether the answer they find is correct.

That standard is unforgiving in a useful way. It cannot be met by a document nobody has read, or by a map that describes an intention, or by a training deck assembled independently of both. It is met when the sequence was followed and the material describes the work as it is genuinely performed.

One client, a print and supply chain business in the San Francisco Bay Area, came back to us two years after their engagement closed to say the mapping had been among the most valuable exercises they had undertaken. They had arrived with procedures already written, eighteen pages of them, too detailed to consult at a glance. What they had been missing was not documentation. It was a picture of the workflow, with responsibilities, document handoffs and system dependencies visible on a single page.

They had the answer written down the whole time. It simply was not in a form anybody could use.