Skip to content

Progressive Commitment

A buyer who can only purchase a whole project, a team or a block of hours has to commit before the information that would justify the commitment exists. A buyer who can stop at any time without consequence leaves the provider unable to plan. The model needs a way to let commitment follow knowledge, in steps that are real in both directions.

Progressive Commitment is the mechanism for expanding or revising commitment as the demand becomes better defined. A commitment establishes the work or result assumed and the conditions for carrying it out: scope, resources, time, price, responsibilities and criteria for closing, as the relationship requires. The mechanism lets that scope be set and revised along the route. An initial intention may authorize clarification; later information may support a commitment to implement. For the buyer, it means purchasing a first useful advance and choosing whether to continue on the basis of what was received and learned.

Progressive does not mean always expanding. A commitment can be kept, reduced, suspended or ended, depending on the decision in the conditions available. Nor does it mean renegotiating every activity: one agreement can cover several stages and include tolerances or conditions for revision. The mechanism preserves that agreement rather than creating decisions nobody needs.

AI is the enabling hypothesis for this experience across a wider range of demands: obtaining and evaluating information, preparing alternatives and coordinating continuation could cost less. Progressive commitment organizes the commercial consequence of that gain. It does not produce the gain merely by splitting a contract into parts.

A poorly defined demand may need investigation before a wider delivery can be bounded, and the first commitment should match the purpose of that exploration. A feasibility analysis can be accepted even when it concludes that the solution does not fit the constraints: its result is information for deciding, not a promise that implementation will be authorized or succeed. Concluding the purchased analysis can completely fulfil that first commitment even if construction is never chosen. Accepting it does not create an obligation to continue with the same provider, resource or solution; the conditions for continuing and for using the artifacts must be understood in the agreement.

Progression does not make every earlier commitment provisional. Work already authorized and obligations assumed remain relevant, and revising continuation requires acknowledging their effects.

Dimension Question to settle
Result What is expected from this commitment?
Limits Which work is covered, and which parts stay out?
Resources and spending Which consumption is authorized, within what limits?
Time and dependencies Which conditions support the expected or promised timing?
Acceptance How will fulfilment of the result be recognized?
Responsibilities Who provides inputs, decides and handles divergences?
Change Which situations call for revision or new authorization?
Closing What happens to work done, pending items and obligations?

In a simple relationship these may take a few conditions; between companies, distinct dependencies and authorities may need more detail. The model proposes no standard legal instrument; it deals with the information the operation needs to know what it may do and what must be decided before continuing.

The authorized scope has to be related to the Delivery State to guide continuation. A unit can exist before implementation is authorized, or hold an accepted output while waiting for a decision on the next step. These conditions must be visible so that registering a demand, or a technical acceptance, is not read as buying the whole thing.

A stage is not a commitment. A Delivery Stage is a transformation. Its Stage Contract can be well defined while the economic commitment has not been made, and technical criteria do not authorize mobilizing resources. One commitment can also cover several stages. Coordination routes only work covered by the commitment in force; a finding that changes the scope needed goes to the relevant decision before it becomes extra execution.

A revision should say what changed and how it affects the agreement. Not every variation calls for changing the commitment: there may be a tolerance, a responsibility already assumed, or flexibility within the scope. When the change exceeds the scope in force, the parties decide how to continue. Progressive Estimation provides an updated forecast; it does not determine the new commitment. The record keeps the link between old and new conditions, so it is clear which outputs are still usable, which work needs revisiting and which obligations stand.

Recognized uncertainty, an execution error and a requested change are different situations. If an output misses a criterion in force, correcting it may be part of the delivery commitment; if the expected behaviour is widened later, the scope may have changed. How this is treated depends on the agreement. Progressive commitment must not become permission to sell a narrow commitment and keep widening the cost without justification, and it must not require the provider to absorb any uncertainty without limit either. The model makes the distribution of responsibilities visible so that price, execution and acceptance are understood together.

Authorizing a future stage and reserving capacity to carry it out are related but distinct. Work can be authorized and waiting for availability, or capacity can be reserved under conditions still to be confirmed. A promised deadline may depend on keeping a window of execution open or on the buyer providing inputs. Reservation can create obligations or costs even when work never starts, so postponing or cancelling is not free by assumption. Internally, committing resources to one demand reduces what is available to others, and that decision should stay visible even without a commercial transaction.

The customer can select a useful and feasible subset, defer other components, or stop after an intermediate delivery, as long as dependencies are respected: removing an indispensable integration can make the retained feature unusable, while deferring an independent report may not. Three situations must not be confused:

  1. an accepted discovery can conclude the commitment that was bought;
  2. declining a future offer simply leaves that new work unauthorized;
  3. interrupting a commitment already under way requires dealing with obligations, costs and outputs under the conditions in force.

Intermediate outputs need a purpose and understandable conditions of use, and their commercial usefulness does not depend on becoming construction. Reducing a scope already contracted requires a recognizable decision; it cannot appear as an incomplete delivery under another name.

At the barbershop, the first commitment covers clarifying and designing booking. After accepting those outputs, the customer receives conditions for building booking and for adding reminders. It chooses the main feature first, keeping advance payment out of scope while relevant questions remain open. That choice creates a commitment to implement, evaluate and deploy; the provider organizes the means and answers for the scope assumed. A correction needed to meet the agreed behaviour stays distinguishable from a request for a new feature.

In another configuration, the customer has already delegated buying the continuation within a ceiling and criteria for scope, acceptance and commercial terms. An authorized system can select the admissible alternative and record the commitment without a new human answer. The provider must also have made a valid offer, or have authorized its own mechanism to assume one: the buyer’s mandate does not bind the provider unilaterally. If no alternative satisfies the conditions, the system can ask for revision, defer or route the exception. See Mandates.

The composition of execution does not change the commitment. Human, automated or hybrid execution can change the expected cost of the work without changing what was assumed or how benefits and risks are shared. If a change of execution affects relevant conditions of access, evaluation or responsibility, it may need authorized revision.

Progression has a cost of its own. Producing information, forming offers, deciding and negotiating cost something at every boundary. When that cost is high relative to the advance, grouping commitments may be economically better. AI could reduce part of it by supporting interpretation, comparison and the preparation of decisions, which would make smaller choices more viable without forcing maximum fragmentation. Many small commitments can still increase waiting; a few very broad ones can concentrate uncertainty. The model does not guarantee lower cost, does not transfer risk universally to either party, and defines no legal clauses, free cancellation or mandatory renegotiation per stage.

Software Delivery as a Service is a proposed model by Renan Deves and Marcelo Scheidt, Independent Researchers. See the paper for citation and license.