Choosing a Software Delivery Model: Match It to Uncertainty and Ownership

Most delivery model decisions get made by habit. A fixed quote feels safe, so the project is fixed. A previous supplier worked on a retainer, so this one will too. A colleague mentions staff augmentation, and suddenly that is the plan.

The model then shapes everything that follows: who writes the scope, who sets priorities, how changes are handled, and what happens at the end. When it does not fit the work, the project fights its own structure, and the friction usually gets blamed on the people.

Choose around uncertainty and ownership instead. Two questions do most of the work.

#The two questions that decide a delivery model

The first question is how settled the work is. Could you describe what needs building completely today, including what is out of scope? Or will you learn what is needed as you go?

The second is who will direct the work day to day. Do you want to hand over an outcome and have the supplier run delivery? Or do you have someone who will set priorities and make technical calls, and need capacity rather than direction?

The answers point to one of three models, which our engagement models page describes in full: a fixed scope project, retained ongoing capacity, or an embedded team.

#Settled work you want delivered: fixed scope

If the work can be described completely today and you want someone else to deliver it, a fixed scope project fits. Typical examples are a first version whose features are already agreed, a move from one system to another that both sides know well, or a connection between two systems with documented interfaces.

Its strength is certainty: an agreed deliverable, a finish line, and acceptance against criteria written at the start. Its weakness is change. Once the scope is fixed, every new idea becomes a written amendment with a consequence to approve. That is a feature when requirements are stable, and a constant source of friction when they are not.

#Work that keeps moving: retained capacity

If the product is live and the roadmap keeps shifting as you learn from real usage, retained capacity fits better. The next few months are clear in direction but not in detail, and you want to reorder priorities each cycle rather than renegotiate a scope.

What it needs from you is someone who sets the order. The supplier plans and delivers each cycle against the priorities you choose. Without that person, retained capacity turns into busy work: things get built, but not necessarily the things that matter most.

#Known work, not enough hands: an embedded team

If your team can decide what gets built and lead the technical work, but does not have enough people to deliver it in time, an embedded team fits. Engineers work inside your process, your tools and your code review, and your team keeps the knowledge as it goes.

Its condition is direction. An embedded engineer does what your backlog and your leads say. Where nobody on your side is setting technical direction, the work drifts, and adding more people makes the drift faster rather than smaller.

#The mismatches, and what they feel like

Most unhappy engagements are a mismatch between the model and the work, and each one has a recognisable feel:

• Fixed scope on moving requirements feels like constant change requests and a supplier who seems inflexible. The scope was fixed before the thinking was finished.
• Retained capacity for a one-off build feels like a project with no finish line. Nobody defined when it would be done.
• An embedded team without technical direction feels like capable people producing little. They are waiting for decisions nobody is making.

If an engagement feels like one of these, the fix is usually to change the model at a natural boundary, not to replace the people.

#Uncertainty can be reduced before you choose

Uncertain work does not have to go straight into an open-ended model. A short discovery phase can turn a vague requirement into a settled one, and a settled requirement can then be delivered as a fixed scope. Many projects start that way: discovery to reduce the unknowns, fixed scope for the first release, retained capacity once the product is live.

That sequence is often better than picking one model for the whole life of a product. The right model at the start is rarely the right model a year later.

#Ownership should not decide the model

Ownership of the output is sometimes treated as a reason to prefer one model over another. It should not be. Whichever model you choose, the code should live in repositories you own, accounts and services should be set up in your name, and documentation should transfer with the work.

If a supplier ties ownership to a particular model, that is a question about the supplier rather than about the model. The questions that actually decide the model are the two at the top: how settled the work is, and who will direct it.

If you are weighing up how to structure a project and none of the options quite fits, explore our engagement models: each one sets out what it suits, how it is scoped, and how it ends.