Back to InsightsNext article

Project Delivery

Why Nobody Follows Your Project Process (And What to Do About It)

Christine Weileder ·

Already know you have this problem? Skip straight to the fixEmail this to me for later

This document covers:

Most businesses I speak with have a process. It lives somewhere, a shared drive, an intranet, a folder someone set up a few years ago. It was built with good intentions. It might even look comprehensive. But if you asked the people actually delivering projects whether they use it day to day, you'd get a very different answer.

This is a pattern I see consistently in small and mid-sized businesses: the project process exists on paper, but in practice it's invisible. And the frustrating part? It's almost never a people problem. It's a system problem, one that's entirely fixable once you know what you're looking at.

What "Process Non-Conformance" Actually Means

Process non-conformance is the gap between how a project is supposed to be delivered and how it actually gets delivered. It's not about people being lazy or difficult. It's what happens when a process is designed without enough input from the people who have to use it every day.

In smaller businesses, this gap tends to grow quietly. Nobody announces that they've stopped following the process. They just find workarounds, rely on personal experience, or default to whatever the most senior person on the team happens to prefer. Over time, every project gets delivered slightly differently, and the business loses the consistency it needs to scale. It shows up across industries: construction, IT, professional services, event planning. Any business that delivers projects or client work is exposed to it.

Why Project Processes Break Down: The Root Causes

The process wasn't designed around how the work actually flows

A process built in a meeting room often reflects how someone thinks a project should work, not how it actually moves through a business. When the steps don't mirror the natural lifecycle of a project, people have to mentally reorder things as they work. That friction builds up, and eventually people stop engaging with the process altogether.

One person owns it, so nobody else does

In many businesses, the project process is seen as the Project Manager's responsibility alone. If the wider team has no stake in it, they won't engage with it. A process that only one person feels responsible for is fragile, and it doesn't survive handovers, growth, or that person leaving.

It's mandatory but not supported

Instructions exist. Guidance on how to apply them in real situations often doesn't. People are expected to comply with a process they weren't meaningfully involved in developing and aren't being actively helped to understand. Mandatory without support creates avoidance, not compliance.

There's no feedback loop

When a process isn't working, people adapt quietly rather than raising it formally. Without a structured way to surface those adaptations, the business never finds out why conformance is low, it just keeps seeing the same audit findings, year after year.

How to Spot a Project Process Problem in Your Business

The signals show up in different parts of the business at once. Here's where to look.

In how people talk about their work

  • You hear phrases like "that's just how we do it here" or "I didn't realise that was in the process." Workarounds get described as normal, not as exceptions, and the process itself gets called confusing or backwards more often than it gets followed.
  • People describe jumping back and forth through steps rather than following a clear sequence, second-guessing themselves at points where the document should have made the next step obvious.

In how the business is structured

  • The process was written by a specialist or central team with little input from the people delivering projects.
  • Ownership of the process sits with one job title, usually the Project Manager, rather than the wider team. If you asked the rest of the team who owns a given step, most wouldn't know, and the ones who do would tell you it's the PM's problem.

In the day-to-day work itself

  • Workarounds and personal judgement routinely stand in for the documented steps.
  • The process visibly breaks down whenever the Project Manager changes or is unavailable, and if you've had more than a couple of different people in that seat in the last two or three years, that turnover is itself a symptom, not just a coincidence.

In your outcomes

  • Project handovers feel inconsistent, what one person produces looks nothing like what another delivers.
  • Project quality noticeably dips whenever there's a change of Project Manager.

In your knowledge base

  • New team members take a long time to get up to speed because knowledge lives in people's heads, not in the system, and nobody trained them on the process, they picked it up by watching whoever happened to be nearby.
  • Nobody has ever mapped what's actually being done against what the document says should happen.

In how it's governed

  • Internal reviews or audits keep flagging the same gaps, but nothing seems to change. People have stopped bothering to raise it, because raising it hasn't led anywhere before.
  • There's no cross-role sign-off built into the process, only the Project Manager's.

In what it's costing financially

  • Your most experienced people are indispensable, because they are the process.
  • You can point to real delay or rework costs tied to a step being skipped or reordered.

If two or three of these feel familiar, across more than one category, you're likely looking at a process conformance problem, not a performance problem.

What Poor Project Process Conformance Is Costing You

The costs are rarely dramatic. They accumulate quietly, which is part of why the problem persists.

Time

Rework is the most direct cost. When a project step is missed or done inconsistently, someone has to go back. If a senior person spends even two or three hours a week fixing things that a clear process would have prevented, that's over 100 hours a year spent on avoidable problems.

Quality

Inconsistent delivery affects outcomes and client confidence, even when the end result is technically acceptable. In my experience, once a clearer process is embedded, audit findings at critical project stages, such as the tender phase, begin to decrease noticeably. The discipline that a well-designed process creates has a real effect on the quality of what goes out the door.

People

Teams that operate without clear process tend to rely on a small number of individuals who carry institutional knowledge. That creates pressure on those people and fragility in the business. When they leave, and eventually they do, the knowledge goes with them.

Growth

Informal knowledge works at a certain size. It stops working when you grow, take on more complex projects, or bring in new team members who don't have the same background. A consistent project delivery process is what makes your capability transferable, and your business scalable.

Five Things You Can Do Right Now

  1. 1Ask your team, not your process document. Sit down with the people delivering projects and ask them where the process feels unclear, counterintuitive, or simply ignored. You'll learn more in an hour of honest conversation than from any audit trail.
  2. 2Map what's actually happening, not what should be happening. Walk through a recent project step by step and note where the team deviated from the documented process, without judgement. The deviations are the data. They tell you where the process doesn't fit the work.
  3. 3Identify who owns what. For each stage of your project delivery process, ask: who is responsible for this step, and do they know it? If the answer is unclear, that's a gap worth closing before anything else.
  4. 4Check whether your process has a logical sequence. Read through your process documentation in the order it's written. Does it follow the natural flow of a project from start to finish? If you find yourself jumping back and forth, your team probably does too.
  5. 5Build in a simple review cycle. Set aside time every six months to ask: what's working, what isn't, and what have people stopped doing? A process that gets reviewed regularly stays relevant. One that doesn't gets quietly abandoned.

A Real Example: From Paper Tiger to Practical Process

I encountered this problem firsthand in a previous role. I was handed an electronic project delivery framework that was, on the surface, mandatory and comprehensive. But within a few months of observing day-to-day operations, it was clear that almost nobody was following it, and internal audits were consistently flagging the same gaps.

The instinctive response from management was that this was a people problem. The process had been developed by a specialist group. It was considered functional. If people weren't using it, surely that was a training or attitude issue? I wasn't convinced.

Over four months, I ran a structured audit programme alongside two colleagues, sitting down with six Project Managers to observe how they actually navigated the process. We weren't just checking boxes, we were asking why. Where did the workflow feel natural? Where did people stop, second-guess themselves, or quietly skip a step?

Three issues kept surfacing: the layout didn't follow the natural lifecycle of a project; ownership sat with one role rather than the whole team; and the process was mandatory but unsupported. I compiled these findings into a formal audit report, shifting the conversation from "is this process good?" to "why isn't it working?" That distinction matters. A process nobody follows isn't a process. It's a document.

I was tasked with leading the redesign and became the owner of the company's project delivery process. It was restructured around how projects actually move through their lifecycle, with distributed ownership and a proper training rollout. A year later, I developed and delivered a two-day Project Manager training programme built directly around the new process. The feedback was clear: people found it logical, practical, and easy to follow. The process was subsequently shared across the wider organisation as a model for structured project delivery.

The Bigger Picture

A well-designed project delivery process isn't a bureaucratic overhead. It's what allows a business to deliver consistently, onboard people faster, and grow without everything depending on the same two or three individuals.

The businesses I've worked with that have the most process problems are rarely short of effort. They're short of structure. And structure, done well, doesn't slow people down, it gives them a clear path to follow so they can focus on the work that actually matters.

If your process is sitting in a folder somewhere, largely untouched, it's worth finding out why. The answer is almost always fixable.

Next Steps

Reach out for an informal chat about what this looks like in your business. Just a straightforward conversation about where you are and what might help.

Or try the mini diagnostic at theknowledgeroom.uk/friction. It takes a few minutes and shows you where the friction in your business is coming from.

Four months. Six Project Managers. One finding, repeated in every single audit. I've written up what I found when I asked why a mandatory process was being quietly ignored, and the training programme that turned it into one people actually used. Drop your details below and I'll send you the full case study. Christine

Back to InsightsNext article