Gantt schedule example
Maps an Alberta pilot from intended use and workflow mapping through privacy inputs, build, launch, and scale decision.
Reference
Reusable worksheets to apply each module to your product strategy and execution plans in Canada and Alberta contexts.
Workbook reference: 20 minutes
Do not fill every template on day one. Use the table below to choose the minimum useful artifact for your current maturity stage, then add depth as the product moves closer to real deployment.
| Stage | Primary question | Use these templates first | Output quality bar |
|---|---|---|---|
| Concept | Is the problem and workflow worth building? | Lean product canvas, stakeholder register, logic model / theory of change, SMART goals, assumption and decision log | Visible assumptions, named stakeholders, expected outcomes, and a narrow first workflow. |
| Prototype | Can users understand and complete the workflow? | Usability / human factors plan, architecture review checklist, requirements traceability matrix | Critical tasks, user needs, and system boundaries are written clearly enough for review. |
| Pilot | Can the product run safely in a constrained real setting? | Risk matrix, PIA worksheet, V&V plan, cybersecurity risk traceability matrix, incident response runbook | Risks, controls, owners, privacy assumptions, and go/no-go criteria are explicit. |
| AI-enabled pilot | Can model behavior be governed and monitored? | Model card, data card, PCCP / AI change-control plan, post-market surveillance plan | Intended use, data provenance, performance limits, subgroup review, and rollback triggers are documented. |
| Production planning | Can the team sustain cost, security, and support? | SBOM inventory, monthly hosting estimator, RACI artifact owners, Gantt schedule, post-market surveillance plan | Owners, cost assumptions, release gates, vulnerability response, and surveillance cadence are fundable. |
This page helps learners turn discussion into artifacts. Templates are not paperwork for its own sake; they create shared evidence that product, engineering, clinical, QA/RA, privacy, security, and business teams can review together.
Use it whenever a page asks for a practical next step and the team needs a lightweight starting format.
These examples help teams move from a broad ecosystem discussion into execution planning. Use them after reading the medtech landscape page.
Maps an Alberta pilot from intended use and workflow mapping through privacy inputs, build, launch, and scale decision.
Connects inputs, activities, outputs, short-term outcomes, long-term outcomes, assumptions, and risks.
Turns pilot ambitions into specific, measurable, owner-assigned goals with review dates.
Use these first when participants need to turn talk content into concrete next steps. They are intentionally short and plain-language so teams can complete them during or immediately after a session.
Define the first workflow, data path, failure behavior, and builder deliverables before implementation starts.
Name the current stage honestly and identify what must be true before moving to the next one.
Specify the system, standard, owner, data mapping, error handling, and acceptance criteria before promising integration.
Clarify what the AI can do, when humans must review it, and what happens when confidence is low or behavior changes.
Map data sources, storage, access, retention, downstream features, and open governance risks.
Map user needs to design inputs, tests, and evidence artifacts.
Capture hazards, severity, probability, controls, and residual risk.
Plan verification layers, validation studies, and ownership roles.
Record key decisions, owners, and evidence for audits.
Intended use, data, performance, monitoring, and transparency summary.
Provenance, representativeness, quality, and retention for ML datasets.
Description, modification protocol, and impact assessment outline.
Inputs for custodian privacy review (flows, safeguards, risks).
Critical tasks, formative and summative evaluation outline.
Link threats, controls, and verification to requirements.
Track components, versions, suppliers, and patch status.
Severity, roles, containment, and notification checklist.
Indicators, data sources, and reporting cadence.
Evaluate boundaries, fallback modes, and interoperability constraints.
Estimate compute, database, storage, monitoring, and backup costs.
High-level milestones, dependencies, owners, and pilot decision gates.
One-page product and risk assumptions.
Clarify who owns each regulatory and engineering artifact.
Custodians, clinical leads, vendors, and escalation paths.
Connect product activities to outputs, outcomes, assumptions, and risks.
Quarterly objectives tied to evidence milestones, owners, and review dates.
Treat these templates as working decision tools, not static documents. Update them whenever your scope, user volume, or hosting architecture changes. This keeps product, engineering, and operations assumptions aligned as you move from pilot to growth.
Before using templates, complete 1) Program structure, 2) Software + hardware basics, and 3) Getting started with engineering. Then use templates to turn that understanding into execution artifacts.
Choose one template that matches your current decision and fill enough of it to expose assumptions, gaps, owners, and next questions.