Avoid Redundant Questions
Discovery should begin by recognizing information the client has already provided rather than asking them to repeat it.
Performance Consulting · Discovery & Scoping
Performance Consulting & Project Scoping Toolkit
Turning an initial client request into clear requirements, focused questions, and an actionable instructional scope.
This case study demonstrates the consulting work that should happen before design begins: analyzing a client work order, identifying known and missing requirements, structuring discovery questions, and separating product scope from project scope.
Project Overview
A consulting toolkit developed around the fictional Build-It-Right EVM 101 eLearning initiative.
The Challenge
The client request contained answers, assumptions, and important gaps.
The work order described the intended audience, broad learning goal, delivery format, functional content areas, LMS, and development expectations. It did not fully resolve every decision required for accurate planning and design.
Expose Hidden Ambiguity
Unclear assessment, prototype, review, approval, software, testing, and collaboration expectations can create downstream risk.
Separate Two Types of Scope
Product scope defines what will be created. Project scope defines how the work will be organized, reviewed, and delivered.
Consulting Workflow
Ask fewer questions, but ask the right questions.
The toolkit uses the existing client documentation as evidence, then converts only the unresolved information into focused discovery questions.
Product Scope
What must the learning solution include?
Product questions establish the boundaries and characteristics of the instructional experience itself.
Learning Format
Self-paced eLearning, instructional hours, module structure, prerequisites, and completion requirements.
Learners & Performance
Target audience, functional roles, required proficiency, existing objectives, and authentic performance expectations.
Instruction & Assessment
Interactivity, scenarios, exercises, assessment methods, criteria, and alignment to terminal and enabling objectives.
Technology & Access
LMS hosting, authoring tools, SCORM expectations, accessibility, language, and prototype requirements.
Project Scope
How will the work be organized and controlled?
Project questions clarify the development lifecycle, client review process, approval authority, collaboration environment, integration testing, travel, software, staffing, and period of performance.
This distinction protects the design team from treating the instructional product as if it exists separately from the people, resources, systems, and decisions required to create it.
Requirements Analysis
Known requirements became anchors. Unknowns became questions.
The checklist prevented assumptions from quietly becoming design decisions.
Documented by the client
eLearning format, broad audience, LMS, functional areas, foundational goal, ADDIE expectation, source content, scenarios, and accessibility requirements.
Missing or ambiguous
Assessment details, prototype boundaries, LMS version, authoring software, review turnaround, official approver, integration access, and collaboration procedures.
Translate into execution
Confirmed requirements inform the analysis plan, design document, prototype, production schedule, review cycle, risk plan, and final deliverables.
Design Artifacts
Two documents supporting stronger discovery
Together, the work order and checklist show how consulting begins with careful reading, disciplined questioning, and scope clarification.
EVM 101 Project Work Order
The fictional client request defining the broad course purpose, audience, delivery format, instructional expectations, and project requirements.
Open Work OrderProduct & Project Scoping Checklist
A structured job aid used to determine which questions were already answered and which required further client discovery.
Open Scoping ChecklistProfessional Reflection
Good consulting begins before a solution is proposed.
This project reinforced that instructional designers should not begin by choosing content, technology, or activities. They begin by understanding what the client has asked for, what evidence is already available, what remains uncertain, and which decisions must be made before development can be planned responsibly.
The checklist also demonstrated the value of instructional restraint. Strong discovery does not require asking every possible question. It requires asking the questions that reduce meaningful uncertainty and improve the quality of the final solution.