When a project needs a second version

A project returns one version, built to one scope, checked against it, and handed back running. That is a clean deliverable, and it is also a snapshot. The desk will change. A system on the other end of a route will be replaced. The customer will see the version working and want it to do more.

The answer to all of those is a second version. This article covers how to recognize when one is needed, how it is scoped, who builds it, and why the first version does not go away.

Change within the scope versus change to the scope

The site team makes many changes without a second scope. The scope named a corpus; the team adds the new procedure to it and publishes. The scope set a bound; the desk finds it too tight and the team loosens it and publishes. The person holding the approving role moves on; the team reassigns the role and publishes.

These are changes within the four lists of the scope, and the operator notes handed over at the end of the project exist precisely so the team can make them. Each one is a published version in the strict sense, with its own identity and its own entry in the run record, but it is not a second project.

A second version in the sense this article means is a change to the scope itself. The use case should read material the scope did not name. It should reach a system the scope did not declare. It should land its result somewhere new. The approving role should sit somewhere else in the flow, or a new action should wait for approval. Any of those is a new scope, and the project form handles it as a new project rather than a patch.

Signals that a second version is due

The desk's packet has moved. What arrives has changed shape or channel. A good result now needs something the first version was never told about. The step that stays human has shifted.

A system on a route has been replaced, and the new one wants something different from the old one. Updating the route may be enough; if the new system changes what the use case has to do, it is a new scope.

The first version has worked well enough that the customer wants it to cover the next desk, the next document set, or the next kind of request. That is growth, and growth is scoped, not bolted on.

The run record is showing a pattern: the version stopping on an exception more often than it should, or the approver sending the same kind of draft back repeatedly. That is the use case telling the team what the second version should learn.

Writing the second scope

The second scope is written the same way as the first. What should be true when the work is done, this time. The four lists: material, calls, the approving role, systems of record. The difference is that the first version and its run record are available as evidence, which makes the second scope easier to write than the first.

A good second scope says explicitly what changes from the first version and what stays. That makes the check at the end sharper, because the team can confirm the new behavior and confirm the old behavior still holds.

Who builds it

The site team can. The operating picture is in the version, the notes are with it, and the team has run the loop at least once at handoff. A second version that stays close to the first is well within reach of a team that has done that.

The practice can. If the second version is large, reaches new systems, or involves adaptation on new material, the customer may prefer to scope it as a new in-house project and have the same kind of engineer build it. The customer initiates that; the practice does not reach into the appliance uninvited.

Sometimes it is both. The team builds the parts inside the first scope and the practice takes the parts that extend it.

The first version does not go away

Whoever builds the second version, the first stays on the appliance. When the second is published, the first becomes the previous version: still there, still identifiable, still available to roll back to. The run record shows which version did what, so if the second version misbehaves the team can see it and return to the first cleanly.

This is why the practice delivers versions and not deployments. A deployment is replaced. A version is superseded, and the one before it is kept. What a project delivers describes the first version's deliverables, and finished when your people can publish alone describes the loop the team runs for every version after it. The engagements page at /engagements covers how a new project is scoped.