The Wiredcraft Way describes how we approach product work. A project also needs a clear way to move from an agreement to a working team, through delivery, and eventually to a handover. This page covers those practical transitions. The details vary by engagement, but the questions should not be left unanswered.
Hand over the work
Before delivery begins, the people who shaped the project share its context with the team doing the work. The team needs to understand the client’s goal, the agreed scope, the main constraints, and any promises or open questions that could affect the plan. Existing research, product documentation, technical information, and relevant access should be brought together where the team can find them.
A handover is complete when the team can explain what it is being asked to deliver, who is involved, and what it still needs to learn. If an assumption is uncertain or a dependency sits outside the team, make it visible before it becomes a missed commitment.
Kick off together
We align within the delivery team first, then with the client. An internal kickoff gives the people doing the work room to question the brief, raise risks, and agree on how they will collaborate. A client kickoff establishes a shared starting point rather than simply presenting a plan.
By the end of kickoff, both sides should know:
- the goal, major deliverables, and important milestones;
- who is responsible for decisions, feedback, and acceptance;
- what input or access is needed, from whom, and by when;
- how progress, questions, risks, and decisions will be shared; and
- when the client will review work and take part in user acceptance testing.
Capture these agreements in a place both sides can use. The format matters less than having a reliable reference when people, priorities, or circumstances change.
Keep the plan honest
During delivery, make progress and decisions visible. Show working material regularly, ask for feedback while it can still shape the result, and keep the current scope and next milestones clear. A risk is something that may happen; an issue is already affecting the work. Raise either early, with its likely impact and a proposed response, so the team and client can decide while there are still options.
Changes need the same clarity. When a request alters an agreed deliverable, acceptance criterion, or active delivery cycle, describe what is changing and assess its effect on effort, timing, and other priorities. Agree on the trade-off with the people authorized to decide, then update the plan and the relevant user stories. A new request should not quietly become an extra commitment.
Agree what is ready to release
Acceptance is not a single conversation at the end. Agree early on who can approve important deliverables and what they will review. As work is completed, compare it with the agreed expectations and record the outcome. For releases that need it, user acceptance testing gives the client or intended audience a chance to validate the result before it goes live.
Before release, confirm the scope and version being shipped, the approval to proceed, the people responsible, and how the team will validate the result. The release plan should also say how to respond if something goes wrong. After deployment, check the important journeys and system health, communicate the outcome, and stay available for issues that only appear in real use. Shipping is complete when the result has been checked, not merely deployed.
Close the project well
When the agreed work is finished, confirm the final deliverables and any remaining items with the client. Hand over the documentation, training, and access needed to use and maintain the product. Make ongoing ownership and support arrangements explicit; do not leave them to be inferred from the last project meeting.
Then close the working arrangements that are no longer needed, including project access where appropriate. Give the team space to reflect on what worked and what should change next time. A good close leaves the client able to move forward and the team able to carry its learning into the next project.
Throughout the lifecycle, transparency, traceability, and accountability help keep those transitions clear.