project efficiency

Is the Project Process the Point? Re-reading the Case for Efficiency

Ian Clarkson, a project management trainer, makes an argument that is easy to nod along to and hard to do in practice. His point: if you only care about the result, skip project management. The discipline exists to run the journey well, not just to stumble across the finish line.

That framing is worth stealing. It is also worth pressure-testing, because most working PMs have inherited organizations that do exactly the opposite.

At a glance

  • Ian Clarkson argues that project management exists to deliver work efficiently, not just to deliver it.
  • Major bodies, including PRINCE2, APM, MSP, and PMI, define project and program management without explicitly naming efficiency.
  • The proposed fix is to mentally append "in the most efficient and effective way" to any standard definition.
  • The piece uses a travel-planning analogy to show why upfront routing beats improvising on the road.

Background: why "process as the purpose" is a hard sell

The bodies that publish canonical definitions, PRINCE2, APM, MSP, and PMI, all describe project management as planning, delegating, monitoring, and controlling. None puts efficiency at the center. That gap shows up in practice. Teams read these definitions, build scorecards around scope, time, cost, and quality, and quietly treat "how we got there" as a feel-good extra.

The result is familiar. The project ships. The retrospective is a shrug. The next one starts the same way. Nobody gets fired, and nobody gets better.

Our analysis: the trade-offs nobody talks about

There is a reason the formal definitions avoid the word efficiency. It is awkward to measure on a single project. You can compare two ways of building the same thing, but you cannot easily compare the way you built this thing against the way you might have built it. So the bodies punt. That punt has costs.

The real lever is not the definition. It is the operating cadence. Teams that treat process as the point run tighter stand-ups, sharper retros, and cleaner decision-making. Teams that treat process as overhead get the opposite. The difference shows up long before any cost variance report.

But here is the honest trade-off nobody mentions: an efficiency-first culture can slide into a bureaucracy-first culture if the leader is not watching. Discipline is not the same as ritual. Watch for the moment your retro becomes a checkbox exercise.

The other uncomfortable truth: this logic does not privilege any single methodology. Whether you run Waterfall, Agile, or a hybrid, you still have a responsibility to execute the method well. A poorly run Agile sprint is not more efficient than a poorly run Waterfall phase. The process is not the purpose if the process is broken.

The analogy that lands

Clarkson uses a travel example. Imagine planning a trip. Option one: go to the airport and figure out your route as you go. Option two: plan the route in advance, build in stops and contingency, and know when you are off track.

You chose option two. Why is a project different?

A decision guide for delivery leaders

Question Process-as-overhead answer Process-as-point answer
Why does this retrospective exist? Because the template says so Because the next sprint depends on what we learned
Who owns the working agreement? The PM The whole team, and it changes when it stops working
What makes a stand-up good? Everyone spoke We know exactly where the work is blocked
What does "done" mean? It shipped It shipped and we could repeat this
How do you handle scope creep? Fight the sponsor Question whether the original plan was right

What to watch next

Whether your team treats process as overhead or as the product of the work. If you cannot answer that question from the last retro, the post has a point.

Bottom line

Appreciate the destination. Run the journey like it matters, because it does.

Key takeaways

  • Standard definitions from PRINCE2, APM, MSP, and PMI underweight efficiency on purpose, and that has real consequences in practice.
  • Process-first teams produce sharper retros, cleaner decision-making, and more honest forecasts.
  • Discipline is not the same as ceremony. Watch for the moment your process becomes theatre.
  • The same logic applies across Waterfall, Agile, and hybrid approaches. Execution quality matters regardless of the label.

Frequently asked questions

What is the main argument of the original post?

That project management should be understood as the efficient delivery of work, not just the achievement of an outcome, and that "the process is the purpose."

Why does the post criticize existing definitions of project management?

Because PRINCE2, APM, MSP, and PMI all describe the activities of running a project without explicitly calling out efficiency or the quality of the journey.

What analogy does the author use?

Planning a trip, and choosing between improvising the route on the way versus planning the route, stops, and contingency in advance.

How does this map to agile or scrum work?

The same logic applies: the value of a sprint is not only what shipped, but what the team learned about how they work together, and whether the next sprint is more predictable than this one.

Does this critique only apply to Waterfall approaches?

No. A poorly run Agile sprint is not more efficient than a poorly run Waterfall phase. The method matters less than how well you execute it.

Related