The problem, in one paragraph
Most EHR integration projects do not fail during the build. They fail in the weeks before anyone opens an editor — and the symptom is an estimate that can be off by a factor of two. Two hundred percent variability, on a project that already has a date attached to it.
What discovery is actually for
Not producing a document. Narrowing the range. Done properly, discovery takes that two hundred percent down to ten, fifteen, twenty-five percent. It does not eliminate the risk and was never going to. What it does is make sure that whatever variability is left will not substantially move your timeline or your budget.
Discovery is finished when the remaining unknowns are isolated and small enough to say that.
What is in the training
The three sessions, and the job each one has. The first is high level — business people and technical leaders, the shape of the project, the areas that will need access and decisions later. The second is the technical session, where screens get opened and workflows get walked as they actually happen. The third brings everyone back to the visualisations, the testing plan, the timeline and the budget.
Who has to be in the room. Three groups: the people who know how the work actually happens, the people who can grant access, and somebody who can make a final decision. Miss the second and it becomes a waiting problem — and waiting is expensive in a way that is easy to miss, because it is invisible on a status report.
What discovery has to produce. Field-level mappings for the things that matter. A message inventory. An exception list — what happens when a message fails. Test data that exercises the edges rather than the happy path, because an environment with no representative data passes everything and surprises you later.
Agendas and checklists you can use as they are, including for a mini discovery on a single new requirement.