The process
04 / 04
Deploy.
Deployment introduces the conditions that belong to the business: live information, real schedules, existing permissions, everyday interruptions, and people who need the tool to make sense.
Move into normal operations
Deployment is the controlled move from a working build into normal operations.
I treat that transition as part of the work, with enough care to protect the business and enough attention to learn what only real use can teach us.
01 · Introduce the tool with control
Introduce the tool with control
The right rollout depends on what has been built and what it touches. A contained internal tool can be ready for a small group immediately. A deeper integration calls for staged access, a limited data set, a parallel run, or a planned fallback when the consequences warrant it. I match the rollout to the consequences of getting something wrong.
Before launch, I confirm the connections, permissions, data paths, and recovery expectations established during Design. I also verify that the people responsible for the tool know what it does, what it does not do, and where to turn when its behavior is unclear. Documentation should support that understanding. It should not be expected to create it on its own.
Training follows the work people need to perform. I focus on the decisions, exceptions, and practical habits that make the tool useful in context. A person using one part of the system does not need a tour of everything behind it. The person responsible for administration, security, or maintenance needs a different level of access and explanation. Deployment accounts for both.
Editorial image
a controlled transition into use
02 · Learn from real use
Learn from real use
Launch gives us evidence that a development environment cannot. We can see where people hesitate, which exceptions arrive first, whether information moves as expected, and whether the tool removes the friction it was built to address.
Some adjustments belong to deployment because they help the approved solution settle into its intended role. I define those boundaries as part of the engagement. If live use reveals a different problem or a new capability worth building, I will separate that work clearly so a launch does not become an open-ended project by accident.
This is also where adoption becomes measurable in practical terms. The relevant signal follows the original problem: time returned to a team, fewer manual handoffs, more consistent information, or simply confident use without repeated intervention. I use the measure established during Diagnosis rather than inventing a success story after the fact.
Signals from the original problem
USE
Where people hesitate
FLOW
Whether information moves
EXCEPTIONS
What arrives first
OUTCOME
Whether the friction is reduced
Launch gives us evidence that a development environment cannot.
Every client receives the clarity needed to operate the completed work. The exact handover depends on the system and on who will own it. It includes the combination of operating guidance, technical documentation, access records, maintenance requirements, recovery procedures, and direct training that its owners need.
For some clients, that is the natural end of the engagement. The tool is stable, the team understands it, and there is no reason to keep paying for support it does not need.
Other clients prefer continued support on retainer. In that relationship, I can monitor and maintain the build, refine its existing capabilities, strengthen security, and help it adapt as local and cloud models change. The retainer is optional and scoped to the system already delivered. A separate build or a materially new business problem begins a new engagement, which keeps ownership and expectations clear for both of us.
Deployment is complete when the tool has a responsible place in daily operations and you know what happens next. For one client, that means a clean handoff. For another, it means an ongoing relationship. Either way, you are left with capability your business can use and a support path you understand.
03 · Choose the right handover
Choose the right kind of handover
Image placeholder · 02
A clear owner and support path
Replace with Garrett’s supplied rollout map or handover image.
