HOW WE WORK

Six stages, and you can see all of them

The backlog, the burn rate and the risk log are shared from week one. There is no phase where we go quiet and come back with a document.

Principles (4 cards, before the stages)

• Working software beats described software. Every sprint ends with a demo in your org, with your data.
• Decisions get written down. Including the options we rejected and why, so nobody re-litigates them in month five.
• Constraints are surfaced early. We’d rather tell you something is hard in week two than in week ten.
• The client can see everything. Backlog, estimates, burn, risks, test results. No filtered status report.

Stage 01 · Discover — 1–2 weeks

Purpose: Understand the work as it happens, not as it’s described.

We shadow the roles that will use the system, map the real decision sequence, inventory the systems people alt-tab to, and profile the data. We also agree what “better” means numerically — a baseline and a target — because a project without one can only be judged on feelings.

Activities: Role shadowing · Process mapping · Systems and integration inventory · Data profiling · Stakeholder interviews · Success metric definition You provide: Access to 4–8 people for 60–90 minutes each; a read-only system user; sample data Output: Discovery report · Baseline metrics · Prioritised problem list · Draft scope

Stage 02 · Design — 2–3 weeks

Purpose: Decide the shape of the system before anyone builds it.

The data model, the security and sharing model, the automation map and the integration contracts all get designed and reviewed together, because they constrain each other. You approve a solution design document, not a slide deck — and it stays live as the reference through build.

Activities: Object and field design · Security and sharing model · Automation map · Integration contracts · UI/task design · Migration approach · Estimation and sprint plan You provide: Sign-off from a named decision-maker; input from IT security Output: Solution design document · Integration contracts · Estimated backlog · Sprint plan · Risk log

Stage 03 · Build — two-week sprints

Purpose: Ship working configuration continuously.

Declarative first; code where it earns its place. Every sprint has a goal, a demo and a decision point where you can re-prioritise the remaining backlog. Work goes into source control from day one and deploys through a pipeline, not by hand.

Activities: Sprint planning · Configuration and development · Peer review · Automated testing · Sprint demo · Backlog re-prioritisation Cadence: Planning Monday · Demo alternate Friday · Async standup notes daily Output: Working org, sprint by sprint · Release notes · Updated backlog and burn · Test results

Stage 04 · Migrate & validate

Purpose: Move the data that matters, and prove it arrived.

Profiling drives an explicit migrate / archive / drop decision. Then two full rehearsals: the first to find problems, the second timed to size the cutover window. Nothing loads into production without a reconciliation report and a tested rollback point.

Activities: Cleansing · Deduplication with survivorship rules · Mapping · Rehearsal one · Fix cycle · Rehearsal two (timed) · Reconciliation Output: Migration specification · Two rehearsal reports · Reconciliation report · Cutover runbook · Rollback plan

Stage 05 · Launch & enable

Purpose: Make the first week uneventful.

Training is role-based and delivered in your org with representative data. Go-live has a runbook, a freeze window, a named decision-maker and a comms plan. Then thirty days of hypercare — daily check-ins in week one, floor-walking, and a fortnightly fix release.

Activities: Role-based training · In-app guidance · Cutover execution · Comms · Hypercare rota · Daily triage Output: Training materials and recordings · Cutover log · Hypercare issue log · 30-day stabilisation report

Stage 06 · Improve — ongoing

Purpose: Stop the slow decline that follows most go-lives.

A monthly release train, adoption reporting against the baseline set in Discovery, and a quarterly review that asks what the org should stop doing as well as what it should start. Salesforce ships three releases a year; we check readiness before each one.

Activities: Monthly release · Adoption reporting · Quarterly health review · Seasonal release readiness · Backlog grooming Output: Monthly release notes · Adoption report · Quarterly review pack · Refreshed roadmap

What we ask of you (honesty section — keep this)

Projects fail on client-side capacity more often than on technical difficulty. To be straightforward about it, we need:

• A decision-maker who can approve design without a committee for routine calls.
• Access to the people doing the work, not only to their managers.
• Roughly a day a week of an internal owner’s time during build.
• Timely data decisions. Migration scope questions block more sprints than anything else.
• Willingness to hear “that’s the wrong requirement”. Occasionally it will be, and we’ll say so.

Process FAQs

Can you work fixed-price? Yes for well-defined scopes, typically after a paid discovery. For open-ended work, sprint-based pricing gives you better control and us fewer reasons to argue about change requests. What if we already have a delivery process? We work inside it. We’ve delivered in client-run Scrum, SAFe and stage-gate environments. How much of your team is on site? Whatever the work needs. Discovery and go-live benefit most from being in person; build rarely does. What happens if a sprint misses? It gets said in the demo, with the reason and the revised plan. Missed sprints happen; hidden ones are the problem.