What the practice asks of a customer
A statement of done, time with the people who handle the packet, an appliance in the rack, a named posture, named roles, a named corpus, and the team who will take it over. Nothing unusual, all of it necessary.
· 4 min read
IN SHORT
E31 Consulting asks a customer for a clear statement of what done means, time with the people who handle the work today, a Czar in the rack, a plainly stated posture and a segment to work in, named roles for publishing and approvals, a named set of materials the agent may read, and the team who will own the use case afterward, present from the start.
An engagement with E31 Consulting is built on the customer's appliance, inside the customer's posture, with the customer's people. That means the practice needs some things from the customer before and during the work. None of them are unusual. All of them matter.
A clear statement of done
The first thing the practice asks is a sentence that describes what should be true when the work is finished. A desk that drafts replies and waits for a person to send them. A corpus of maintenance manuals that technicians can question in plain language. A product customers run under the customer's own name.
The practice will help sharpen the sentence, but the customer has to own it. An engagement without a statement of done cannot end, and the practice will not start one.
Access to the people who do the work
For a forward-deployed engagement the engineers need to sit with the desk. That means time from the people who handle the packet today, not a summary from their manager. The engineers need to watch what arrives, see what a good result looks like, learn which step a person still has to take, and know which system it has to land in.
For an in-house project the ask is lighter but not absent: the people who own the materials, the approvals, and the systems of record in scope need to be reachable to answer questions and to take the handoff.
An appliance in the rack
The work runs on Czar. The customer has the appliance, or has it on order under the subscription, before building starts. The practice does not build somewhere else and move the result in later, because the result would then have been somewhere else, and the posture would have been broken on the way.
Where a site has several Czars as a Czar Grid, the practice builds for that. Where a site has one, it builds for one.
A named posture and a segment to work in
The customer decides whether the site is air-gapped, connected only to systems they already secure, or a mixed estate. The practice builds inside that choice and does not ask to change it for convenience. What it does ask is that the posture be stated plainly at the start, and that IT provide a segment the engineers may work in. The question of access is treated in do engineers need access to our network.
Named roles
Agency governs by named roles: who may publish, who approves at each marked point. The practice needs the customer to name those roles with real people behind them. A role that nobody holds is a bound nobody can satisfy, and the agent will stop there and wait.
This is often the most useful conversation of the engagement. Deciding who approves a disposition before it is written back is a decision the site should make on purpose, and the engineers will ask for it to be made.
The materials the agent may read
If the use case retrieves over the site's documents, the customer identifies which documents. Not a data lake; a named set. The practice does not go looking for material and does not read anything outside what is named. Expanding the corpus later is an ordinary change the site team learns to make.
People who will take it over
Finally, the practice asks for the team who will own the use case after the handoff, from the start. Not to be trained at the end, but to be present during the building. In a forward-deployed engagement they are the people the engineers build with. In a project they are the people who receive the handoff and perform each change in scope before it is signed off.
An engagement ends when those people can publish the next version themselves. The practice cannot produce that outcome without them, and does not pretend otherwise. What they hold afterward is described in what the customer keeps.
Questions this raises
- Do we need the appliance before the engagement starts?
- Yes, in the rack or on order under the subscription, before building begins. The practice does not build somewhere else and move the result in, because that would mean the work had been somewhere else and the posture would have been broken on the way.
- What if we have not decided who approves?
- Deciding is part of the engagement, and often the most useful part. Agency enforces approvals by named roles, so a role nobody holds is a bound nobody can satisfy. The engineers will ask for the decision to be made on purpose rather than by default.
- How much of our team's time does this take?
- The practice does not quote figures, because it depends on the use case and the form of engagement. What it can say is that the people who handle the packet and the people who will own the result are both needed, and that a project asks less of them than a forward-deployed engagement.
KEEP READING