---
author: "[[Bob Marshall]]"
tags:
  - blogpost
publish: 2026-06-03
sources:
  - https://flowchainsensei.wordpress.com/2026/06/03/a-deep-dive-into-noprojects/
---
## A Deep Dive Into #NoProjects

### The Memeplex That Refuses to Die

The project model has been failing software organisations for decades. This is not a controversial claim. The evidence is overwhelming, long-standing, and widely cited — the Standish Chaos Reports, the graveyard of late and over-budget enterprise programmes, the endless parade of post-mortems that reach the same conclusions and recommend the same remedies that were ignored after the last post-mortem. And yet the project model not only survives but dominates. It remains the default organising logic for software delivery across industries, sectors, and geographies. Most governance frameworks assume it. Most finance functions require it. Most executives think in it.

This is worth pausing on. Why does a model that demonstrably underperforms persist so stubbornly? The answer is not ignorance, or not primarily. Smart, well-intentioned people have been arguing against it for years. The agile movement spent two decades attacking its worst manifestations. #NoProjects has been a live conversation in the delivery community for long enough to have its own hashtag.

The project model persists because it is not just a process. It is a _memeplex_ — a self-reinforcing cluster of assumptions, attitudes, vocabulary, roles, incentive structures, and governance artefacts that hang together and mutually defend each other. Attack one element and the others close ranks. Replace the methodology and the assumptions remain. Adopt agile ceremonies and waterfall thinking reasserts itself within months. The memeplex is robust precisely because it operates largely below the level of conscious examination. It does not present itself as a set of contestable beliefs. It presents itself as how things are done.

Richard Dawkins coined the term meme to describe a unit of cultural transmission that replicates, spreads, and persists through minds and institutions the way genes persist through organisms. A memeplex is a collection of mutually supporting memes that travel together and reinforce each other’s survival. The project memeplex has all the hallmarks: it recruits practitioners into roles that depend on it, generates language that makes alternatives hard to think, creates career structures that reward fluency in its practices, and produces governance systems that require project-shaped inputs. It is, in the most literal sense, self-perpetuating.

This matters because it means that arguing against the project model at the process level is insufficient. You can win every argument about methodology and lose the war because the assumptions underneath the methodology were never touched. The alternative to the project model has to be as coherent, as mutually reinforcing, and as capable of generating its own attitudes and practices — or it will simply be absorbed and neutralised.

The #NoProjects movement is a provocation in the right direction. But a provocation is not yet a system. Building a genuine alternative requires going deeper — to the assumption layer where the memeplex actually lives.

### The Provocation

There is a movement in software and business circles that goes by the hashtag #NoProjects. At first glance it sounds like the kind of contrarian positioning that the industry occasionally falls in love with — a catchy slogan that dissolves on contact with reality. Look closer, and it turns out to be pointing at something real and important. Not a complete answer in itself, but a necessary provocation that opens a much bigger conversation.

That conversation, followed to its conclusion, leads somewhere genuinely radical: a coherent alternative management philosophy for software delivery, grounded in systems thinking, lean product development, decision theory, and a clear-eyed view of what knowledge work actually is.

But the conversation is harder than it first appears, because the project model and its alternatives are not simply different processes. They rest on incompatible assumptions about the nature of software work — and most of those assumptions are never made explicit. They are just baked in. This matters enormously, because attitudes and choices follow from assumptions unconsciously. You cannot change how an organisation behaves without first surfacing what it believes.

This post follows that thread.

### The Assumption Stack of the Project Model

The project model arrives with a hidden set of assumptions that rarely get examined because they feel like common sense. Requirements are knowable upfront. Solutions are designable before building begins. Estimates are meaningful. The future is sufficiently predictable to commit to in advance. Delivering to plan is a reasonable proxy for delivering value.

None of these are argued for. They are simply inherited from industries — construction, engineering, manufacturing — where they hold reasonably well, and transplanted into software where they largely do not.

The entire governance apparatus of the project model exists to defend these assumptions rather than interrogate them. Scope documents assume knowable requirements. Change control boards exist to police deviations from a plan that was always somewhat fictional. RAG status reports convert messy, uncertain reality into a simple signal that everything is under control. The apparatus is coherent — it just coheres around the wrong assumptions.

What makes this particularly difficult to dislodge is that attitudes follow assumptions unconsciously and feel like judgement rather than belief. A project manager who genuinely assumes requirements are knowable upfront will experience a team saying ‘we need to change direction based on what we have learnt’ as a failure of discipline — not as healthy adaptation. A finance director who assumes delivery is fundamentally an execution problem will read a request for incremental funding as a lack of commitment rather than intellectual honesty. The assumption is invisible. The attitude it generates feels like obvious good sense.

This is the real reason #NoProjects provokes such strong reactions. It is not arguing about process. It is threatening assumptions that people have built careers and identities around.

### What #NoProjects Is Actually Arguing

The #NoProjects position is not that work should be unstructured, unaccountable, or ungoverned. It is that the _project_ as the organising unit of software delivery is a poor fit for the nature of software work, and that the assumptions it imports cause predictable, systemic harm.

Software is not a bridge. You do not design it, build it, and walk away. It is a living system that requires continuous investment, adaptation, and ownership. The assumption that it can be delivered by a temporary team assembled for a fixed term and then disbanded destroys institutional knowledge, forces expensive ramp-ups, and incentivises people to cut corners to hit an artificial deadline rather than build something maintainable.

The assumption of fixed scope is equally damaging. Requirements written upfront are mostly intelligent guesses made before anyone has done the work that would generate the knowledge needed to write good requirements. The project contract pretends otherwise. The result is waterfall-in-disguise — teams going through agile motions whilst remaining accountable to a plan written before they understood the problem.

The critique is sound. What is less common is a genuinely coherent alternative — one that addresses the legitimate governance needs that projects serve without importing the dysfunctions (Marshall, 2023a). Building that alternative requires replacing not just the processes but the assumptions underneath them.

### Whose Needs? The Antimatter Principle

The Antimatter Principle, articulated by Bob Marshall — FlowChainSensei (Marshall, 2013) — operates at the deepest assumption level of all. It questions the assumed definition of success itself.

The project model assumes success means delivery against plan. Marshall’s Antimatter Principle assumes success means _needs served_— attend to the needs of the people. These are not compatible assumptions, and no amount of process change bridges the gap if the underlying assumption is not shifted first.

As a governance frame this recentres everything. Most governance frameworks ask ‘are we on plan?’ The Antimatter Principle asks ‘whose needs are we actually serving, and are we serving them?’ The user or customer becomes the constant reference point rather than a document written before work started. Scope drift becomes less threatening when you are continuously checking against actual needs rather than a frozen specification.

The assumption shift also has teeth in directions most governance ignores. The team’s needs — sustainable pace, psychological safety, meaningful work — are needs too. Burning a team out to hit a project deadline is a governance failure on this framing, not merely an HR concern. That feels radical only because the project model has quietly assumed for decades that team welfare is not a governance matter.

The Antimatter Principle does not tell you how to organise work. It tells you what you are organising work _for_. That is the evaluative criterion that everything else in this system needs to serve.

### Incremental Funding: Assumptions About When You Know Things

The most direct structural replacement for project-based funding is incremental funding — committing capital in smaller tranches, contingent on demonstrated progress, at defined decision points.

The assumption shift here is about _when_ knowledge exists. The project model assumes you know enough at the start to justify a large upfront commitment. Incremental funding assumes you do not — and that this is normal and expected rather than a planning failure.

Instead of funding a predetermined output, you fund knowledge creation and validated progress. Each gate is a forward-looking question: given what we now know, is continued investment a better bet than stopping or redirecting? This is a more honest question than ‘are we on track against the original plan?’ and it rewards different behaviours. Honest discovery is rewarded; gaming estimates is not.

Incremental funding also dissolves the sunk cost trap that the project model makes almost inevitable. When you have made a large upfront commitment, stopping feels like failure and waste. When each gate is a new bet made on current knowledge, the prior investment has no logical bearing on whether to continue. The assumption that past commitment justifies future commitment — pervasive and deeply felt in project cultures — is simply not imported.

The practical challenge is cultural rather than structural. Many organisations adopt the language of incremental funding whilst retaining the project model’s psychology underneath. The funding gates become mini project reviews. Leaders still feel that changing direction is failure. The vocabulary changes; the assumptions do not.

### Thinking in Bets: Making Assumptions Visible

Annie Duke’s _Thinking in Bets_ provides the decision theory that makes the assumption problem explicit and offers a practical discipline for addressing it.

Duke’s central argument is that we habitually judge decision quality by outcome quality — she calls this _resulting_. A bad decision that worked out gets remembered as good. A good decision that did not work out gets punished. This is ruinous for any learning system because it destroys the feedback signal.

The underlying assumption she is attacking is that outcomes are a fair reflection of decisions. In uncertain environments they are not. Outcomes are jointly determined by decision quality and factors outside anyone’s control. Conflating them means you learn the wrong lessons, reward the wrong behaviours, and systematically fail to improve.

The practice she advocates — treating every significant decision as a bet, stating your confidence level explicitly, committing to what would change your view — is at root a practice of making assumptions visible. When you say ‘I believe this will work because I assume X, Y, and Z, and here is what would lead me to revise that belief’, you have done something most project governance never does: you have separated the assumption from the conclusion, and created the conditions under which the assumption can be tested and updated.

This is the epistemic foundation the whole alternative system needs. Without it, you can have all the right structures — incremental funding gates, learning reviews, continuous delivery — and still corrupt them by allowing hidden assumptions to drive decisions whilst visible evidence is ignored or reframed.

### Theory of Constraints: Assumptions About Where the Problem Is

Eliyahu Goldratt’s Theory of Constraints adds a systems thinking layer that challenges one of the project model’s most persistent assumptions: that improving parts improves the whole.

The project model measures and manages at the level of individual projects — on time, on budget, on scope. The implicit assumption is that if each project performs well, the portfolio performs well, and the organisation performs well. Goldratt demonstrated this is simply false. System throughput is governed by a single constraint at any given time. Optimising non-constraints does not improve throughput; in many cases it makes things worse by adding inventory and complexity that makes the constraint harder to manage.

The attitude this assumption generates is visible everywhere in project-driven organisations: teams optimising their local metrics whilst the organisation struggles to deliver anything of consequence (Marshall, 2023b). Individual projects green on every RAG report, yet customers not getting what they need. The measurement system is coherent; it is measuring the wrong things.

Throughput Accounting, Goldratt’s financial framing, replaces the cost-efficiency assumption with a flow assumption. The question is not ‘are we under budget?’ but ‘what is the rate of value moving through the system?’ This aligns naturally with incremental funding — you are not tracking spend against a plan, you are tracking whether the system is improving its ability to deliver value.

The Five Focusing Steps — identify the constraint, exploit it, subordinate everything else to it, elevate it, repeat — provide a governance loop that embeds a different assumption about improvement: that it is systemic, continuous, and focused on what actually limits performance rather than what is easiest to measure.

### The Toyota Product Development System: Assumptions About Knowledge and Commitment

The Toyota Product Development System, developed through the work of Allen Ward amongst others, challenges perhaps the most deeply held assumption in the project model: that early commitment is a sign of good planning.

In the project model, locking down requirements, solution design, and delivery plan as early as possible is considered rigour. The assumption is that early commitment creates focus, accountability, and efficiency. What it actually creates, in knowledge work, is the systematic suppression of learning. Having committed early, the system now has strong incentives to defend that commitment rather than update it when evidence suggests it was wrong.

Set-Based Concurrent Engineering, the core practice of TPDS, rests on the opposite assumption: that early commitment made in ignorance is not rigour, it is risk (Marshall, 2022; Marshall, 2015). Multiple design alternatives are maintained in parallel. Inferior options are eliminated as knowledge accumulates, rather than as a result of an upfront decision. Convergence happens when you have the knowledge to justify it.

The attitude this generates is entirely different. Not-knowing in early stages is the normal and expected condition of good work, not a planning failure to be concealed. Maintaining options is discipline, not indecision. The team that can articulate what they do not yet know, and what they are doing to find out, is performing well.

The Chief Engineer role in TPDS embodies an accountability assumption that differs sharply from the project manager model. The Chief Engineer owns the customer value proposition — deeply knowledgeable about customer needs, technically capable, authorised to make trade-offs. Accountability here is assumed to belong to someone who knows the work and owns the outcome, rather than someone who tracks adherence to a plan. The attitude that follows is one of craft and responsibility rather than compliance and reporting.

### Toyota Kata: Assumptions About How Improvement Happens

Mike Rother’s Toyota Kata addresses perhaps the most operationally consequential assumption of all: that organisations improve by implementing best practices.

The best-practice assumption is deeply embedded in how most organisations approach change. Find out what works elsewhere. Document it. Train people on it. Measure compliance. The assumption is that improvement is a matter of adopting the right procedures.

Rother observed something different in Toyota. The competitive advantage was not in any specific practice — competitors could copy practices — but in a _thinking pattern_ that generated continuous improvement in any situation. The Improvement Kata is that pattern made explicit: understand the direction, grasp the current condition, establish the next target condition, experiment towards it.

The critical assumption embedded in the Kata is that you do not know how to get to the target condition when you set it. If you knew, it would not be an experiment. The discipline of committing to a prediction before running the experiment — stating what you expect to happen and why — is the practice of making assumptions visible at the operational level. The honest retrospective that follows is how those assumptions get updated.

This is exactly what incremental funding gates need as their operational heartbeat. Without the Kata discipline, funding reviews default to the project model’s assumptions regardless of the language used. With it, each cycle is genuinely about learning: what did we predict, what happened, what do we now believe? Building improvement into the rhythm of the work — rather than treating it as a separate initiative — is the mechanism by which an organisation makes this real (Marshall, 2024).

The Coaching Kata is equally important and often neglected. It addresses the assumption that changing individual behaviour is enough to change organisational behaviour. Rother recognised that the Improvement Kata would remain a local practice unless leaders and managers adopted a coaching pattern that made the scientific thinking approach contagious. The Coaching Kata is how the assumption shift propagates rather than remaining the personal practice of a few enthusiasts.

### The Core Theme

Step back from the individual frameworks and a single theme emerges across all of them.

Software and product development is a _knowledge problem_, not an execution problem. You do not know enough at the start to plan your way to a good outcome. The question is whether your organisational system is designed to learn fast enough to navigate that uncertainty well — or whether it is designed to pretend the uncertainty does not exist.

The project model pretends. It converts uncertainty into a plan and then defends the plan. But this is not merely a process choice — it is the logical consequence of a set of assumptions about the nature of software work that happen to be wrong. Requirements are knowable. Estimates are meaningful. Early commitment is rigour. Delivery against plan is success. Change is failure. These assumptions generate the attitudes, choices, and governance behaviours that follow as night follows day.

Every element of the alternative system works with uncertainty rather than against it, and does so by resting on a different set of assumptions:

The Antimatter Principle assumes success means needs served, not plan delivered. Incremental funding assumes knowledge is created during delivery, not before it. Thinking in Bets assumes decisions should be evaluated on the quality of reasoning given available information, not on outcomes. Theory of Constraints assumes system performance is what matters, not local efficiency. TPDS assumes early commitment made in ignorance is risk, not rigour. Toyota Kata assumes improvement comes from developing thinking patterns, not implementing best practices.

None of these assumptions are self-evidently correct. They can be argued for, tested, and refined. What they have in common is that they are honest about the nature of knowledge work in a way the project model’s assumptions are not.

### What This Means in Practice

The remaining challenge is real and should not be minimised. Finance functions, audit teams, regulators, and boards often need project-shaped artefacts for reasons that have nothing to do with software delivery — capital versus operating expenditure treatment, regulatory compliance, board-level reporting. Abolishing projects entirely is not available as an option in most organisations.

But the key insight is that you can decouple the artefacts from the delivery behaviour — and more importantly, you can decouple the governance assumptions from the delivery assumptions. You can satisfy the legitimate needs of finance and governance with project-like documentation whilst running the actual delivery system on entirely different principles: continuous teams, set-based thinking, Kata cycles, incremental funding gates framed as bets.

The art is in making that decoupling explicit and conscious. Many organisations have accidentally done the reverse — adopted agile delivery language whilst remaining psychologically committed to the project model’s assumptions underneath. The result is the worst of both worlds: the overhead of agile process without the benefit of genuinely adaptive thinking.

The harder work — and the more important work — is the assumption shift itself. That means making assumptions explicit in governance conversations, building funding gates around learning rather than plan adherence, rewarding teams for honest discovery rather than confident prediction, and developing leaders who can coach the scientific thinking pattern rather than just demand results.

That is what #NoProjects, followed to its logical conclusion, is pointing towards. Not a slogan, and not merely a different set of processes. A different set of assumptions about what organisations are doing when they try to build software — and a recognition that until those assumptions are surfaced and examined, no process change will hold.

### Further Reading

The following works informed the arguments in this post and are recommended for readers who wish to explore the underlying ideas in depth.

Dawkins, R. (1989). _The selfish gene_ (2nd ed.). Oxford University Press. (Original work published 1976)

Duke, A. (2018). _Thinking in bets: Making smarter decisions when you don’t have all the facts_. Portfolio/Penguin.

Goldratt, E. M., & Cox, J. (1984). _The goal: A process of ongoing improvement_. North River Press.

Goldratt, E. M. (1997). _Critical chain_. North River Press.

Leybourn, E. (2013). _Directing the agile organisation: A lean approach to business management_. IT Governance Publishing.

Morgan, J. M., & Liker, J. K. (2006). _The Toyota product development system: Integrating people, process, and technology_. Productivity Press.

Reinertsen, D. G. (2009). _The principles of product development flow: Second generation lean product development_. Celeritas Publishing.

Ries, E. (2011). _The lean startup: How today’s entrepreneurs use continuous innovation to create radically successful businesses_. Crown Business.

Rother, M. (2009). _Toyota kata: Managing people for improvement, adaptiveness and superior results_. McGraw-Hill.

Ward, A. C., & Sobek, D. K., II. (2014). _Lean product and process development_ (2nd ed.). Lean Enterprise Institute.

**Online resources**

Marshall, R. W. (2013, October 12). _The Antimatter Principle_. Think Different. [https://flowchainsensei.wordpress.com/2013/10/12/the-antimatter-principle/](https://flowchainsensei.wordpress.com/2013/10/12/the-antimatter-principle/)

Marshall, R. W. (2015, August 20). _Meeting folks’ needs at scale_. Think Different. [https://flowchainsensei.wordpress.com/2015/08/20/meeting-folks-needs-at-scale/](https://flowchainsensei.wordpress.com/2015/08/20/meeting-folks-needs-at-scale/)

Marshall, R. W. (2018, September 6). _Solutions demand problems_. Think Different. [https://flowchainsensei.wordpress.com/2018/09/06/solutions-demand-problems/](https://flowchainsensei.wordpress.com/2018/09/06/solutions-demand-problems/)

Marshall, R. W. (2022, January 13). _Quintessential product development_. Think Different. [https://flowchainsensei.wordpress.com/2022/01/13/quintessential-product-development/](https://flowchainsensei.wordpress.com/2022/01/13/quintessential-product-development/)

Marshall, R. W. (2023a, September 24). _Ditch the project mindset?_Think Different. [https://flowchainsensei.wordpress.com/2023/09/24/ditch-the-project-mindset/](https://flowchainsensei.wordpress.com/2023/09/24/ditch-the-project-mindset/)

Marshall, R. W. (2023b, June 17). _Beyond the agile trap_. Think Different. [https://flowchainsensei.wordpress.com/2023/06/17/beyond-the-agile-trap/](https://flowchainsensei.wordpress.com/2023/06/17/beyond-the-agile-trap/)

Marshall, R. W. (2024, February 19). _The why of FlowChain: Deliberate continuous improvement_. Think Different. [https://flowchainsensei.wordpress.com/2024/02/19/the-why-of-flowchain-deliberate-continuous-improvement/](https://flowchainsensei.wordpress.com/2024/02/19/the-why-of-flowchain-deliberate-continuous-improvement/)

The Standish Group. (2020). _Chaos report 2020_. The Standish Group International. [https://www.standishgroup.com](https://www.standishgroup.com/)