Discovery Is the Implementation Baseline
Many IT teams treat "Discovery" like a documentation exercise: a phase that produces a thick report, which is then promptly filed away while the real work begins. That leaves much of Discovery’s value unrealized.
Discovery should do more than document how things work. It should prepare teams to deliver. Executed well, it establishes the baseline for implementation, producing living artifacts that teams carry forward and refine as decisions are made. A focused Discovery phase converts unknowns about scope, dependencies, and readiness into a validated implementation baseline. It replaces assumptions with evidence and translates a broad initiative into a well-governed delivery plan, giving executives a decision-ready package for budgeting, procurement, staffing, sequencing, and oversight.
To see what this looks like in practice, we turn to Element Solutions’ Product Owners Aaron Koppel and Kinnary Shah. Their recent Discovery work for the Commonwealth of Pennsylvania offers a practical look at how findings become decisions, requirements, and plans that delivery teams can act on.
“Discovery guides teams through making important and informed decisions, so they can move into implementation with confidence,” explains Kinnary Shah.
The Shift: From Documentation to Delivery
A delivery-oriented Discovery phase produces:
Initial Delivery Backlog: Prioritize epics, user stories, acceptance criteria, and technical work that implementation teams can refine and execute.
Interface Inventories: Identify interfaces, data flows, API requirements, and system owners that helps teams resolve dependencies before development begins.
Architecture Decisions: Establish design choices, tradeoffs, and patterns that help developers build with greater consistency and confidence.
Risk and Dependency Maps: Define blockers and dependencies, so your technical team can sequence work efficiently and effectively.
Together, these assets form a connected implementation baseline: an interface dependency can change backlog priorities, a design decision can clarify acceptance criteria, and an unresolved risk can affect the implementation sequence.
How to Establish the Implementation Baseline
Follow these five practices, with every output contributing to the baseline that teams will carry into delivery:
Mobilize and Align: Align on the definition of "done," scope boundaries, and decision rights.
Understand the Current State: Document the actual workflows, including the manual workarounds and technical debt.
Define the Ecosystem: Map the system dependencies, security constraints, and data flows. This helps you ground architecture in operational reality, beyond just requirements on a page.
Translate Findings into Delivery Assets: Connect each material finding into a requirement, backlog item, decision, risk, dependency, or implementation action.
Estimate, Sequence, and Govern: Develop realistic effort estimates and a phased roadmap informed by the backlog, architecture decisions, and dependencies, with clear assumptions and decision points.
Work through these practices, reviewing assets with operational leaders, technical owners, and end users, and refining them as findings are validated.
Aaron Koppel emphasizes why that collaboration matters: “Implementation gains momentum when the people building the technology and the people using it work together from the start.”
The Element team applied this approach during its six-week Discovery effort for the Commonwealth of Pennsylvania, examining operations across three warehouses and four enterprise systems. The effort surfaced 23 decisions that needed to be addressed before full implementation, making the next steps clearer for agency leaders and delivery teams.
The Bottom Line
A successful Discovery phase establishes a shared baseline for what needs to be built, why it matters, and how success will be validated. As implementation progresses, teams refine the delivery assets and assess changes against that agreed baseline.
Element helps agencies establish that baseline before cost, schedule, and technical decisions harden around incomplete assumptions.
Comments