What if our team cannot maintain it?

Then the engagement is not finished. E31 Consulting measures the end of an engagement by whether the site's own people can publish the next version themselves. If they cannot, the practice has not met its own standard, and the work continues until they can. The question is a fair one to ask before starting, and the answer shapes how the work is done.

The standard is built in

Training is not a course appended to the end of the work. In a forward-deployed engagement the operators publish versions alongside the engineers from early on, write the notes in their own words, and make each ordinary change with their own hands before the engineers withdraw. In an in-house project each change in scope is performed by a member of the site team at handoff, on the real appliance, before the handoff is signed off.

The test is specific: a named member of the site team publishes a version, alone, that changes something real. Until that has happened, the engineers have not left.

What maintaining actually involves

Customers who worry about maintenance often picture something larger than the reality. The appliance itself, the sealed Czar, is covered by its subscription, which includes sustainment of the hardware and platform. The site team does not maintain Czar.

What the site team maintains is the use case: the version, the corpus, the approvals, the routes. The ordinary changes are small and are described in the notes. Add a document set. Move an approval to a different role. Declare a route to a new system. Tighten a bound after reading the record. These are the changes the team has already done, and the notes say what to open, what to change, who publishes, and what to check.

If the team is small or turns over

A small team is not a problem; the roles that matter are the ones named in the version, and there may be only a few. Turnover is handled by the version history and the notes: a new operator learns from what the previous one published and from the notes written for exactly that purpose. The method the engineers used to train the first team is one the site can use to train the next.

When a change is too big

Some changes are beyond the notes: a new desk, a different kind of material, a result that should now land directly in a system of record. That is not a maintenance failure. It is a next version, scoped as a new engagement and built from what the site already holds. The path is described in after the engagement: support and the next version.

What the practice will not do

It will not hand back a use case to a team that cannot change it and call the engagement complete. It will not substitute a managed service for the training, because a managed service would leave the site dependent on someone outside the building, which is the thing the practice exists to avoid. What the site holds at the end is set out in the operating picture you keep.