Requirements matrix
Phase 1 · DiscoverAn excerpt of twelve requirements gathered across seven departments during Discover workshops, each traceable to the session where it was raised.
| Ref | Dept | Requirement | Type | Priority |
|---|
Two of the twelve requirements have no current state at all — not a manual workaround, nothing — which is a different order of gap than the ten that are merely being done by hand.
Technical health scorecard
Phase 2 · DiagnoseSix dimensions rated against evidence gathered during Diagnose, not against a generic maturity model.
Two dimensions score red for different reasons — one because a vendor withdrew support, the other because nobody built the reporting layer. The fix for the first is a platform decision; the fix for the second might not be.
Integration boundaries
Phase 2 · DiagnoseSix points where the current platform exchanges data with another system, and what happens at each one when it fails.
Connector ownership is the row most clubs have never priced. Where the incumbent vendor built and maintains an integration, leaving them means rebuilding it — that is lock-in with a number attached.
Comparative evaluation
Phase 3 · DetermineCoverage of Must-have requirements for the current platform and three alternatives, scored against the matrix from Phase 1 rather than a vendor's own feature list.
A platform that covers 90% of Musts but fails a real-time golf closure requirement is not 90% suitable — which is why the failures are listed, not just totalled.