Most projects that go wrong were never really understood. A discovery week is the cheapest way to find that out before anybody writes production code. It is five days, run by the same senior people who would build the thing, and it ends with a written scope you could hand to your board.
Monday: the decision, not the feature list
We start with the people who own the problem. Not the wish list, the decision. What has to be different in twelve months, and who will be judged on it. Everything the week produces has to serve that one sentence.
Tuesday and Wednesday: the real system
We map what already exists, including the spreadsheet nobody admits to and the process that lives in one person head. This is where estimates usually break, so we spend two full days on it.
- —Every system the new work has to read from or write to.
- —Who signs off, and how long a sign off actually takes.
- —The busiest hour of the busiest day, and what breaks in it.
- —Records, access and audit obligations.
- —What you want to run yourselves after handover.
Thursday: shape and sequence
We sketch the thing on paper and on screen, in enough detail to argue about. Then we sequence it, so the first release carries real value rather than a login page and a promise.
Friday: the scope
You get named phases, named deliverables, the people on each one, the sequence, and an explicit list of what is out. That last list is the one that saves projects.
If a scope cannot survive being read aloud to the people who have to live with it, it is not finished.
How we close a discovery week
Sometimes the honest answer on the Friday is that the work is smaller than you thought, or that you do not need us at all. We would rather say it in week one.