Get something into production early
The most useful thing a project can do is put one working workflow in front of real users within a few weeks. Everything after that is informed by how they actually use it.
A system that reaches users in week six and is extended for three months produces a better result than one designed completely and delivered in month four.
A typical twelve-week shape
| Weeks | What happens |
|---|---|
| 1–2 | Discovery: process, data, systems, access |
| 3–5 | Core workflow built and reviewed |
| 6 | First release to a small group |
| 7–10 | Extension based on real use, plus integrations |
| 11 | Reporting, permissions, edge cases |
| 12 | Full rollout and handover |
What we need from you
- Week 1: access to every system, requested immediately
- Weeks 1–2: two to three days from whoever knows the process
- Week 5: half a day reviewing the core workflow with real users
- Weeks 7–10: feedback within a day or two, consolidated
- Week 12: a decision to go live, and someone available on the day
Access is the most common cause of delay and it is entirely preventable by requesting everything on day one.
Feedback from one voice
Four people giving contradictory feedback separately is the second most common cause of delay. One person collecting and resolving it internally, then sending one response, keeps a project moving.
That person also needs authority to decide, or the consolidation just moves the disagreement rather than resolving it.
Scope additions go into phase two
Things will occur to people during the build. That is healthy and it should not silently expand the current phase.
We record them, price them, and they go into a phase two list. Nothing is lost and the current date holds.