Course Process
1. Technical Feasibility
What it evaluates: Whether the technology, tools, and technical expertise required actually exist or can be acquired.
When to use: Any project involving new or unfamiliar technology, complex integrations, or where technical uncertainty is the biggest risk (e.g., building a new software platform, adopting emerging tech like AI/IoT).
Content: Can it be built/delivered with available technology, skills, and infrastructure? Includes technology options, integration constraints, technical risks, and whether the required expertise exists in-house or must be sourced.
| Size | Length |
|---|---|
| Small | Short paragraph |
| Medium | 1 page, lists key technical dependencies |
| Large | Detailed architecture/approach options, often with a technical risk assessment or proof-of-concept results |
2. Financial Feasibility
What it evaluates: Whether the project makes financial sense — costs vs. benefits, ROI, payback period, funding availability.
When to use: Nearly always relevant, but especially critical for capital-intensive projects (construction, manufacturing, large IT investments) or when competing for limited budget against other initiatives.
Content: Estimated costs, funding sources, projected returns (ROI, payback period, break-even point), and comparison against financial thresholds the organization uses to approve projects.
| Size | Length |
|---|---|
| Small | Simple cost estimate + rough payback |
| Medium | 1–2 pages, basic financial model |
| Large | Full financial model with sensitivity/scenario analysis, funding structure, sometimes third-party financial validation |
3. Operational Feasibility
What it evaluates: Whether the organization can actually execute and sustain the project day-to-day — staffing, skills, process fit, change management.
When to use: Projects that significantly change how people work (new systems, restructured processes, outsourcing decisions) — especially where adoption risk is high.
Content: Can the organization actually run this once built? Staffing, process changes, training needs, change management, day-to-day operational impact.
| Size | Length |
|---|---|
| Small | A few bullets |
| Medium | Half a page |
| Large | 1–2 pages, may include an organizational readiness assessment |
4. Legal/Regulatory Feasibility
What it evaluates: Whether the project can be legally executed — permits, licenses, compliance, contractual constraints, IP issues.
When to use: Regulated industries (healthcare, finance, pharma), construction/real estate (zoning, environmental law), or any project involving new jurisdictions or data privacy considerations.
Content: Permits, licenses, compliance requirements, industry regulations, contractual or IP constraints.
| Size | Length |
|---|---|
| Small | 1 line or omitted if not applicable |
| Medium | Half a page |
| Large | Full legal review, often with external legal counsel input |
5. Schedule Feasibility
There is a sample of this study attached to the course – check it out!
What it evaluates: Whether the project can realistically be completed within the required or desired timeframe.
When to use: Projects with hard external deadlines (regulatory compliance dates, contractual obligations, event-driven launches) where being late has serious consequences.
Content: Can this be delivered in the required timeframe given resource and dependency constraints? Identifies critical path risks.
| Size | Length |
|---|---|
| Small | 1 line |
| Medium | Simple milestone estimate |
| Large | Full schedule feasibility analysis, sometimes with critical path modeling |