An Initiative Question is an open topic that needs resolution during the Initiative lifecycle. Questions are how your team surfaces unknowns, dependencies on answers, and explicit decisions — and tracks each through to resolution. They evolve their meaning by stage:
- Planning: Actively collecting questions from stakeholders
- Approval: Blocking questions must be resolved before proceeding
- Build: Implementation questions become “Blockers & Decisions”
- Retro: Resolved questions become “Lessons Learned”
Unlike Initiative Risks, which track uncertain threats, Questions track explicit unknowns that require an answer. A risk is “this might go wrong”; a question is “we don’t know the answer to this yet.”
Status Lifecycle
Questions follow a simple lifecycle:
open → resolved
↘ deferred
deferred → open (reopened)
resolved → open (reopened)
open — The question is active and awaiting an answer (default).
resolved — The question has been answered. A resolution_text is required to resolve; the resolved_by user and resolved_at timestamp are automatically recorded.
deferred — The question is not immediately actionable and has been set aside for later consideration. It can be reopened at any time.
Categories
Organize questions by their nature:
| Category | When to Use |
|---|---|
| stakeholder | Business, organizational, or stakeholder alignment questions |
| technical | Architecture, implementation, or technology decisions |
| process | Workflow, ownership, or operational questions |
| compliance | Regulatory, legal, or security questions |
Blocking Questions
The blocking flag distinguishes critical questions from informational ones:
- blocking: true — This question must be resolved before the Initiative can advance to the next stage. Catalio surfaces open blocking questions as unmet readiness signals during stage advancement.
- blocking: false — This question is tracked for awareness but does not gate advancement.
Use blocking: true sparingly. Reserve it for questions whose answers will materially change scope, approach, or feasibility — not for every open item.
Key Fields
| Field | Purpose |
|---|---|
| question | The question text |
| status | Current state: open, resolved, or deferred |
| blocking | Whether this question gates Initiative stage advancement |
| category | stakeholder, technical, process, or compliance |
| resolution_text | How the question was resolved (required when resolving) |
| resolved_at | When the question was resolved |
| resolved_by | User who provided the resolution |
| author | User who asked the question |
| sort_order | Display ordering within the initiative (lower numbers appear first) |
Questions in the Initiative Lifecycle
| Stage | Questions Focus |
|---|---|
| planning | Surface all open questions; classify as blocking or informational |
| approval | All blocking questions should be resolved or have confirmed resolution plans before sign-off |
| build | Track outstanding technical questions; escalate blockers quickly |
| retro | Resolved questions become “Lessons Learned” — review patterns across initiatives |
During approval → build advancement, Catalio’s readiness signals flag any open blocking questions. Sponsors see a clear picture of outstanding unknowns before the team enters active build.
Relationships at a Glance
| Related Concept | Relationship |
|---|---|
| Initiative | Questions belong to an Initiative |
| Initiative Risks | Related concept for uncertain threats vs. known unknowns |
| Initiative Tasks | Resolution actions can be tracked as Tasks |
Best Practices
Ask questions early, before they become blockers.
A question captured in Planning — even if it takes weeks to answer — is far less disruptive than one that surfaces mid-Build. Create questions as soon as the unknown is identified, even if you’re not sure who can answer it yet.
Write questions as questions.
“API availability” is a topic. “Will the Payment API team have the v2 endpoints available before our Build phase starts?” is a question. Specificity makes the question answerable and the resolution unambiguous.
Assign category and blocking at creation time.
Don’t leave these fields empty. The category helps route the question to the right person; the blocking flag determines whether it gates the team’s progress.
Write resolution text that’s actionable, not just “yes”.
“Resolved: yes” is useless. “Resolved: Payment team confirmed v2 endpoints available by 2026-06-01. Shaun is the technical contact. See email thread from 2026-05-12.” gives future context.
Reopen rather than create duplicates.
If a resolved question resurfaces (e.g., the answer changes), reopen the original question rather than creating a new one. This preserves history and avoids confusion.
Next Steps
- Understand Initiatives — Learn the stage lifecycle that Questions participate in
- Track Risks — Manage uncertain threats alongside open questions
- Manage Tasks — Convert resolution work into delivery items
Pro Tip: At the start of each stakeholder session, review the open questions list together. Questions that survive multiple sessions without a resolution path are usually blocking dependencies in disguise — escalate them.
Support
- Documentation: Continue reading about Initiative Risks and Dependencies
- In-App Help: The AI assistant can help surface questions from Initiative context
- Email: support@catalio.ai
- Community: Share question management patterns with other Catalio users