Process: Feasibility Assessment

Process: Feasibility Assessment

Owner: Client Intake Manager (Camille) Type: Manual Frequency: Per new client engagement (after requirements gathering)

Purpose

Determines whether the factory can deliver what the client needs — before making any commitment. Prevents the factory from accepting work it cannot complete on time, within budget, or to the required quality standard. The feasibility assessment is a gate: production does not begin until feasibility is confirmed.

When to trigger

  • After the requirements document is substantially complete (Sections 1-8 of the requirements template filled in)
  • Before any scope commitment or client agreement is signed
  • When a client's request changes significantly during intake (re-assess)

Steps

1. Technical feasibility — consult CTO (Clara)

Question: Can the factory technically build what the client is asking for?

Check with Clara:

  • Are the requested capabilities achievable with current LLM technology?
  • Are there known technical limitations that would prevent delivery?
  • Does the request require capabilities outside the factory's current tooling?
  • Are there security or compliance requirements that affect the technical approach?

Record:

  • Verdict: Feasible / Feasible with conditions / Not feasible
  • Conditions (if any): what needs to change or be added
  • Technical risks identified

2. Pattern availability — consult Agentic Pattern Designer (Ada)

Question: Do we have established patterns for the requested capabilities?

Check with Ada:

  • Do patterns exist in the catalog for the primary capabilities?
  • Are the requested interactions (multi-step, tool use, conversation, etc.) covered by known patterns?
  • Would new patterns need to be designed? If so, how much effort?

Record:

  • Patterns available: list matched patterns
  • Gaps: capabilities with no existing pattern
  • Effort estimate for new patterns (if needed)

3. Architecture assessment — consult Enterprise Architect (Elena)

When: Required for complex requests. Skip for straightforward, single-purpose digital talents.

A request is complex when:

  • It requires integration with 3 or more external systems
  • It involves multi-agent coordination
  • It has strict security or compliance requirements
  • It requires a novel architecture not previously built

Check with Elena:

  • Does the request fit within a known architecture pattern?
  • Are the integration points feasible and well-understood?
  • Are there architectural risks (scalability, reliability, data flow)?

Record:

  • Architecture assessment: Standard / Complex / Novel
  • Risks identified
  • Recommendations for production

4. Timeline feasibility — consult Production Line Architect (Pablo)

Question: Can the factory deliver within the client's timeline?

Check with Pablo:

  • Does an appropriate production line exist for this type of digital talent?
  • What is the estimated production time?
  • Are there current capacity constraints (other engagements in progress)?
  • What is the realistic delivery date?

Record:

  • Production line: existing / needs creation
  • Estimated production time
  • Capacity: available / constrained
  • Realistic delivery date vs. client requested date

5. Compile feasibility report

Combine all findings into a single feasibility report.

Report structure:

# Feasibility Report — [Client Name]

**Date:** [date]
**Assessor:** Camille (Client Intake Manager)

## Summary verdict

[Feasible / Feasible with conditions / Not feasible]

## Technical feasibility
- Verdict: [pass/conditional/fail]
- Notes: [findings from Clara]

## Pattern availability
- Verdict: [pass/conditional/fail]
- Available patterns: [list]
- Gaps: [list]
- New pattern effort: [estimate]

## Architecture assessment
- Verdict: [standard/complex/novel]
- Risks: [list]
- Recommendations: [list]
(or: Skipped — straightforward request)

## Timeline feasibility
- Client requested: [date]
- Realistic estimate: [date]
- Verdict: [on track / tight / not achievable]
- Capacity: [available / constrained]

## Overall risk assessment
| Risk | Severity | Mitigation |
|------|----------|------------|
| | | |

## Recommendation
[Clear recommendation: proceed / proceed with conditions / decline]
[If conditions: list what must be true before commitment]

6. Act on the verdict

  • Feasible: Proceed to scope definition (Step 5 of intake process)
  • Feasible with conditions: Communicate conditions to the client. If client accepts conditions, proceed. If not, re-scope or decline.
  • Not feasible: Communicate honestly to the client. Explain why. Suggest alternatives if possible (e.g., reduced scope, different timeline, referral to another provider). Close the intake.

Quality gate

A feasibility assessment is complete when:

  • Technical feasibility checked with Clara
  • Pattern availability checked with Ada
  • Architecture assessed (or explicitly skipped for simple requests)
  • Timeline feasibility checked with Pablo
  • Feasibility report compiled with clear verdict
  • Recommendation is actionable (proceed / conditions / decline)
  • Client informed of outcome

Turnaround target

Feasibility assessment should be completed within 1 business day of having a substantially complete requirements document. This supports the overall < 2 day intake turnaround target.