118 lines
4.7 KiB
Markdown
118 lines
4.7 KiB
Markdown
# Discovery Loop Reference
|
|
|
|
## Purpose
|
|
|
|
Use discovery to gather only the information needed to set up a useful Basecamp project and produce a workable plan. Keep the conversation focused, practical, and easy for the requester to answer.
|
|
|
|
## Conversation Principles
|
|
|
|
- Ask one question at a time.
|
|
- Prefer multiple-choice questions with a free-text escape hatch, such as "Other / describe briefly."
|
|
- Use progressive disclosure: start with essentials, then ask follow-ups only when the answer changes setup or planning decisions.
|
|
- Reflect confirmed answers briefly before moving to the next topic.
|
|
- Avoid forcing certainty; capture assumptions and risks when the requester is unsure.
|
|
|
|
## Discovery Ledger
|
|
|
|
A discovery ledger is the running record of confirmed project facts, open questions, assumptions, and decisions. Keep it concise and update it after each meaningful answer.
|
|
|
|
Suggested ledger fields:
|
|
|
|
- Confirmed facts
|
|
- Open questions
|
|
- Assumptions
|
|
- Decisions made
|
|
- Risks and constraints
|
|
- Basecamp setup implications
|
|
|
|
## Discovery Topics
|
|
|
|
### Project Name
|
|
|
|
Confirm the exact project name to use. If the requester has no name, offer a short working-name option and mark it as provisional.
|
|
|
|
### Language
|
|
|
|
Confirm the primary language for the Basecamp project, kickoff message, tasks, and docs. Ask whether any stakeholders need translated or bilingual content.
|
|
|
|
### Goal
|
|
|
|
Capture the project goal in one clear sentence. The goal should explain the outcome, not just the activity.
|
|
|
|
### Success Criteria
|
|
|
|
Define how success will be recognized. Prefer measurable or observable criteria, such as launch date met, stakeholder approval received, adoption threshold reached, cost cap held, or deliverable accepted.
|
|
|
|
### Non-Goals
|
|
|
|
Identify what is intentionally out of scope. Non-goals protect the plan from drift and help explain tradeoffs later.
|
|
|
|
### Stakeholders
|
|
|
|
List key stakeholders and what each needs from the project. Include decision makers, contributors, reviewers, affected teams, and external parties where relevant.
|
|
|
|
### External Visibility
|
|
|
|
Confirm whether the project is internal-only, client-facing, partner-facing, public-facing, or mixed. This affects tone, access, notification strategy, and how decisions are documented.
|
|
|
|
### Project DRI
|
|
|
|
Identify the Directly Responsible Individual for the project. The DRI owns forward motion, decision routing, and status clarity even when work is delegated.
|
|
|
|
### Team and Roles
|
|
|
|
Capture who is involved and each person's role. Note owners for delivery, review, approval, technical input, operations, communications, and stakeholder coordination.
|
|
|
|
### Timeline
|
|
|
|
Collect important dates: desired start, kickoff, milestones, review windows, hard deadline, and flexibility. Mark whether dates are fixed, preferred, or tentative.
|
|
|
|
### Constraints
|
|
|
|
Record limits on budget, capacity, tools, process, compliance, availability, quality bar, vendor access, or organizational policy.
|
|
|
|
### Dependencies
|
|
|
|
List dependencies that must happen before or during the project, including people, approvals, assets, data, vendors, systems, legal review, procurement, and upstream deliverables.
|
|
|
|
### Risks
|
|
|
|
Capture known uncertainties that could affect scope, timeline, quality, adoption, budget, or stakeholder alignment. Ask for likelihood and impact only when useful.
|
|
|
|
### Work Structure
|
|
|
|
Determine the preferred planning structure: phases, milestones, workstreams, deliverables, checklists, approval points, or a simple task list. Match structure to complexity.
|
|
|
|
### Kickoff Tone
|
|
|
|
Confirm the tone for the kickoff message: concise and operational, warm and collaborative, executive summary, client-facing polished, or another style.
|
|
|
|
### Basecamp Creation Strategy
|
|
|
|
Decide how to create the Basecamp project:
|
|
|
|
- Minimal setup: project shell, kickoff message, essential to-dos, and core people.
|
|
- Standard setup: kickoff, schedule, grouped to-dos, docs, owners, and initial risks.
|
|
- Structured setup: milestones, approval gates, workstreams, risk tracking, stakeholder-specific access, and status cadence.
|
|
|
|
Choose the lightest strategy that supports coordination without overbuilding.
|
|
|
|
## Minimum Clarity Gate Before Planning
|
|
|
|
Begin planning only when these items are clear enough to proceed:
|
|
|
|
- Project name or acceptable working name
|
|
- Primary language
|
|
- Goal
|
|
- Success criteria
|
|
- Key non-goals or confirmation that none are known
|
|
- Project DRI
|
|
- Core stakeholders or team
|
|
- Timeline expectations and any hard dates
|
|
- Major constraints, dependencies, and risks
|
|
- External visibility level
|
|
- Preferred work structure or permission to choose one
|
|
- Basecamp creation strategy
|
|
|
|
If one or more items remain unknown, either ask the next highest-impact question or document a clear assumption and get permission to proceed on that basis.
|