AiPro Institute™ Prompt Library
Technical Feasibility Study
The Prompt
Replace all placeholders (highlighted in orange) with your specific project context. The depth and accuracy of your inputs directly determines the quality of the feasibility assessment. Include concrete constraints, measurable requirements, and realistic team capabilities for a grounded analysis.
The Logic Behind This Prompt
1. Multi-Dimensional Feasibility Framework (Technical, Resource, Timeline, Risk)
WHY IT MATTERS: Most feasibility studies fail by evaluating only one dimension—typically technical ("Can we build this?")—while ignoring equally critical resource, timeline, and risk dimensions. A technically feasible project that requires 40 person-months with a 12-person team available for 2 months is not actually feasible despite being technically possible. This prompt structures evaluation across four interconnected dimensions: Technical Feasibility (do required technologies exist and work at needed scale?), Resource Feasibility (do we have skills, people, budget?), Timeline Feasibility (can we deliver by required deadline?), and Risk-Adjusted Feasibility (what's the probability of success accounting for uncertainties?). Each dimension receives independent scoring (0-100) before synthesis into Overall Feasibility Score. This prevents the common trap of "technically elegant but practically impossible" recommendations. For example, a blockchain-based distributed system might score 95/100 on Technical Feasibility (technology exists and proven) but 30/100 on Resource Feasibility (team lacks blockchain expertise, hiring takes 6 months) and 20/100 on Timeline Feasibility (8-month build vs. 3-month deadline), yielding risk-adjusted score of 35/100 = NOT FEASIBLE. The multi-dimensional approach transforms binary "yes/no" thinking into nuanced assessment recognizing that feasibility is conditional—feasible IF we extend timeline, feasible IF we hire specialists, feasible IF we reduce scope.
2. Evidence-Based Technology Maturity Assessment
WHY IT MATTERS: Technology choices drive 60-80% of feasibility risk, yet teams routinely adopt technologies based on hype, blog posts, or vendor marketing without rigorous maturity assessment. A technology can be "production-ready" according to vendor but unproven at your scale or in your use case. This prompt demands evidence-based evaluation: Has this technology been deployed at similar scale by organizations you can reference? (Not just "handles millions of users"—similar scale means similar workload characteristics: read-heavy vs. write-heavy, latency sensitivity, data volume growth rate). It assesses maturity across eight dimensions: Production readiness (proven deployments), Documentation quality (can developers learn it?), Community support (get help when stuck?), Stability (breaking changes frequency), Vendor viability (will it exist in 3 years?), each scored to quantify maturity. Example: Kubernetes scores 95/100 (mature, proven, excellent docs, massive community) while HashiCorp Waypoint scores 45/100 (emerging, sparse docs, small community, uncertain future). This prevents "resume-driven development" where engineers choose exciting new tech that introduces existential project risk. The assessment also identifies safe-vs.-risky components: using React (mature) + Next.js (mature) + Supabase (adolescent but growing) + custom ML model (emerging, high risk) = overall medium-high risk, with ML model flagged for proof-of-concept validation before full commitment. Evidence requirements force teams to find case studies, performance benchmarks, and technical specifications—not just believe vendor promises.
3. Granular Effort Estimation with Reality-Checked Buffers
WHY IT MATTERS: Timeline feasibility failures typically stem from three errors: (1) Underestimating effort (missing hidden complexity), (2) Overestimating capacity (assuming 100% productive time), (3) Ignoring variability (using point estimates without buffers). This prompt enforces bottom-up estimation: Break initiative into 10-20 discrete features/components, size each (T-shirt sizing: XS/S/M/L/XL or person-days/weeks), sum to total effort. Then reality-check capacity: Team of 5 engineers doesn't deliver 5 person-weeks of work per week—realistically 60-70% after meetings, support, tech debt, context-switching = 3-3.5 effective person-weeks. If project requires 60 person-weeks and team delivers 3 person-weeks/week, that's 17-20 weeks minimum—not "12 weeks because deadline is 12 weeks." Then add buffers for known unknowns (30%: predictable risks like integration debugging, requirement clarifications) and unknown unknowns (20%: unpredictable issues like key person sick leave, technology failures). Final estimate: 20 weeks × 1.5 = 30 weeks. If deadline is 12 weeks, that's NOT FEASIBLE without scope reduction or team expansion. This brutal honesty prevents "optimism-driven planning" where teams commit to impossible timelines, work unsustainable hours, deliver buggy software, or miss deadlines. The structured approach also exposes hidden costs: If project requires specialized ML expertise and team lacks it, where's the 4-6 week upskilling buffer or 2-4 weeks to hire/onboard specialist? By forcing granular breakdown and reality-checked buffers, prompt generates defensible timelines that executives can rely on rather than "best case if everything goes perfectly" fantasies.
4. Comprehensive Risk Assessment with Likelihood × Impact Prioritization
WHY IT MATTERS: Every initiative faces 15-30 significant risks across technical, resource, schedule, and external categories. Teams that don't systematically identify and prioritize risks either: (1) Ignore risks until they materialize (reactive firefighting), or (2) Treat all risks equally (wasting effort on low-priority risks while high-priority risks go unmanaged). This prompt structures risk management using likelihood × impact matrix: High likelihood (>50% chance) × High impact (>30% timeline delay or >30% budget overrun or project failure) = Critical priority requiring immediate mitigation. Medium/Medium = Monitor and plan. Low/Low = Accept. For each risk, it demands: Specific mitigation strategy (not vague "monitor closely"—actual actions like "architect abstraction layer allowing database swap," "hire senior DevOps engineer by Month 2"), and Contingency plan if risk materializes despite mitigation (e.g., "If PostgreSQL hits write throughput ceiling at 50K events/sec, migrate to CockroachDB with pre-built migration scripts and budgeted 6-week cutover"). Example: Technical risk—"Chosen real-time communication framework (WebRTC) may not handle 10K concurrent video streams." Likelihood: Medium (40%—unproven at this scale). Impact: High (re-architecture would add 8 weeks). Priority: High. Mitigation: "Build proof-of-concept with 100 concurrent streams by Week 2, load test to 1K streams by Week 4, if latency >200ms, switch to alternative framework (Agora.io)." Contingency: "Budget $15K for Agora.io licensing and 3-week integration if WebRTC fails PoC." This structured approach ensures risks aren't just "mentioned" but actively managed with resources allocated. The prioritization prevents paralysis—focus on 5-8 high-priority risks, not all 30 possible risks equally.
5. Alternatives & Trade-offs Analysis (Not Just "Build as Specified" Thinking)
WHY IT MATTERS: Feasibility studies often fall into binary trap: Either we can build exactly what's specified, or we can't. Reality: Most initiatives have flexible parameters—scope (what features?), timeline (when delivered?), budget (how much spent?), quality (what performance?). Rather than declare "NOT FEASIBLE" and stop, this prompt explores five alternative approaches that modify constraints to achieve feasibility: (1) Scope Reduction—Deliver 70% of features in 100% of time/budget (MVP strategy). Does 70% still deliver 85% of business value? Often yes. (2) Timeline Extension—Deliver 100% of features in 140% of time with same team. Does 40% delay kill business opportunity? Maybe not. (3) Increased Investment—Deliver 100% of features in 100% of time with 130% budget (hire contractors to accelerate). Does ROI justify extra cost? Calculate. (4) Phased Rollout—Deliver 50% features at Month 3 (capture early value), 50% at Month 6 (complete vision). Reduces risk and enables learning. (5) Build vs. Buy—Purchase commercial solution at $X vs. build custom at $Y. Lose customization, gain speed. Each alternative receives structured analysis: Impact on feasibility (what improves?), Impact on value (what's sacrificed?), Pros/Cons, Cost-benefit. This transforms feasibility study from gatekeeping ("no, you can't do this") to problem-solving ("here's how to make it work"). Example: E-commerce platform initially NOT FEASIBLE (12-month build, 6-month deadline). Alternative 3 (MVP): Build core features only (product catalog, cart, checkout), defer advanced features (recommendations, reviews, wishlists). Feasible in 5.5 months, delivers 80% of revenue opportunity. Recommended path: GO with MVP approach.
6. Go/No-Go Decision Framework with Conditional Approval and Kill Criteria
WHY IT MATTERS: Binary "GO/NO-GO" decisions are brittle—they don't account for conditional feasibility ("feasible IF we do X") or changing conditions during execution ("was feasible at start, no longer feasible after Month 3 complications"). This prompt structures decision-making as three-tier framework: GO (feasible with high confidence, proceed immediately), CONDITIONAL GO (feasible if specific conditions met—secure additional budget, hire key specialist, reduce scope—proceed only after conditions satisfied), NO-GO (not feasible, do not proceed as proposed, consider alternatives or defer). The CONDITIONAL GO category is critical—it prevents premature commitment while keeping options open: "GO if we hire senior ML engineer before kickoff" creates clear gate—don't start until hiring complete. This aligns executive expectations (approval conditional on hiring) and prevents situation where team starts without required expertise, fails predictably. The framework also defines Kill Criteria for in-flight projects: conditions under which initiative should be terminated despite initial GO decision. Examples: Timeline slips >30%, Budget overruns >40%, Critical technical blocker with no workaround, Key team member departures, Market conditions change. These criteria prevent sunk-cost fallacy ("we've already invested 6 months, can't stop now") when early termination is wiser than continuing doomed project. By establishing criteria upfront, decision to kill becomes objective rather than political. Finally, monitoring framework (weekly checkpoints, monthly risk reviews, quarterly feasibility re-assessment) ensures feasibility isn't "one-time analysis at start" but continuous validation. Conditions change—technology proves harder than expected, requirements shift, team members leave—and feasibility must be reassessed. This creates adaptive decision-making that responds to reality rather than sticking to outdated initial assessment.
Example Output Preview
Context: Series B SaaS startup building Figma-like collaborative design tool with real-time multiplayer editing, vector graphics engine, plugin ecosystem. Team: 15 engineers (5 frontend, 6 backend, 2 infrastructure, 2 ML). Budget: $800K. Timeline: 9 months to initial launch. Current stack: React, Node.js, PostgreSQL, AWS.
EXECUTIVE SUMMARY
Feasibility Verdict: CONDITIONAL GO
Confidence Level: 6.5/10 — Medium confidence. Significant technical and resource risks exist but are manageable with proper mitigation.
Key Findings:
- Primary Feasibility Driver: Real-time collaborative editing at 100+ concurrent users per document is technically proven (Figma, Google Docs, Miro demonstrate feasibility) but requires specialized expertise in Operational Transform or CRDT algorithms that team currently lacks.
- Critical Risks: (1) Canvas rendering performance at 10K+ vector objects may hit browser limitations requiring WebGL optimization (High likelihood, High impact). (2) Real-time sync infrastructure costs could exceed $15K/month at target scale, 40% over projected $10.8K/month (Medium likelihood, High impact).
- Resource/Timeline/Scope Trade-offs: 9-month timeline is aggressive but achievable if: (a) Scope reduced to core collaborative editing + basic shapes, deferring advanced features (gradients, effects, plugins) to Phase 2, (b) Hire senior graphics engineer with canvas optimization experience by Month 1, (c) Use Yjs CRDT library instead of building custom sync engine, saving 8-12 weeks development time.
- Recommended Path: CONDITIONAL GO with MVP scope (defer 30% of features), immediate hiring (graphics engineer + infrastructure specialist), and technology de-risking (adopt proven CRDT library, validate canvas performance through Week 4 PoC).
TL;DR Recommendation: Proceed with project contingent on: (1) hiring senior graphics engineer and infrastructure specialist within 6 weeks, (2) reducing scope to MVP (core editing + basic shapes, defer advanced features), (3) successfully completing Week 4 performance PoC demonstrating <16ms frame time with 5K objects. With these conditions, project is feasible within 9-month timeline and $850K adjusted budget (6% over original).
SECTION 2: TECHNICAL FEASIBILITY ANALYSIS
2.1 Technology Maturity Assessment
Technology: Yjs (CRDT library for real-time collaboration)
- • Maturity Level: Adolescent (3-4 years in production use)
- • Production Readiness: Proven at scale by Nimbus Notes (100K+ users), Relm (50K concurrent users), multiple startups. GitHub: 10K+ stars, active development.
- • Documentation Quality: 8/10 — Comprehensive API docs, multiple tutorials, example projects. Gaps in advanced optimization techniques.
- • Community Support: Active Discord (2K+ members), Stack Overflow (500+ questions with answers), responsive maintainer (Kevin Jahns).
- • Stability: Stable core API since v13 (2021). Backwards-compatible updates. Semantic versioning followed.
- • Vendor Viability: Open-source (MIT license), not dependent on single vendor. Multiple companies contribute. Low abandonment risk.
- • Risk Assessment: Low-Medium risk. Main concerns: (1) Performance at >10K objects in document may require custom optimization, (2) Scaling to >1000 concurrent connections per document untested (most deployments <200 concurrent).
Technology: HTML Canvas + Fabric.js (Vector rendering engine)
- • Maturity Level: Mature (10+ years)
- • Production Readiness: Used by Canva, Lucidchart (simplified versions), numerous smaller tools. Well-proven for 2D graphics.
- • Documentation Quality: 9/10 — Excellent docs, extensive examples, active tutorials community.
- • Community Support: Large community, 27K GitHub stars, 8K StackOverflow questions. Easy to find help.
- • Stability: Stable API, infrequent breaking changes. Mature codebase.
- • Vendor Viability: Open-source, active maintenance, multiple maintainers. Very low risk.
- • Risk Assessment: Medium risk at target scale. Fabric.js begins to degrade performance at 5K-10K objects (frame rate drops below 30fps). May require migration to WebGL for complex documents. Mitigation: Implement virtualization (only render visible viewport), consider hybrid approach (Canvas for simple shapes, WebGL for complex/many objects).
Technology Maturity Score: 78/100
Analysis: Core technologies (Yjs, Fabric.js) are proven but at upper edge of their performance envelopes for our target scale. Yjs handles collaboration well but may need optimization beyond 200 concurrent users per document (we target 100, so 2x margin). Fabric.js renders well up to 5K objects but we target 10K+ for "complex documents"—risk of performance degradation. Both risks are manageable through optimization (virtualization, progressive rendering, WebGL fallback) but require specialized graphics engineering expertise. Overall: Technologically feasible but not trivial—requires senior-level execution.
2.2 Integration Complexity Analysis
- System Architecture: 6 major systems—Frontend (React + Canvas), Real-time Sync (Yjs + WebSocket server), API Backend (Node.js + Express), Database (PostgreSQL for projects/users), Object Storage (S3 for assets), Auth (Auth0)
- Integration Points:
- Frontend ↔ Sync Server: WebSocket connection carrying CRDT updates
- Sync Server ↔ Database: Periodic persistence of document state
- Frontend ↔ API Backend: REST API for project CRUD, user management
- Frontend ↔ S3: Direct upload for large assets (images, videos)
- API Backend ↔ Auth0: JWT validation, user profile sync
- Known Integration Challenges:
- Challenge 1: Real-time sync conflicts with eventual consistency model. If user edits offline, syncs later, how to reconcile with server state? Yjs handles this at algorithm level, but application logic must handle conflict resolution UX (which version wins? show conflicts?).
- Challenge 2: Scaling WebSocket connections. Each active document needs persistent connection to sync server. At 10K concurrent users across 500 documents = 10K concurrent WebSocket connections. Single Node.js server handles ~10K connections max (with tuning). Need load balancing strategy (sticky sessions to ensure all users editing same document connect to same sync server instance).
- Challenge 3: Canvas rendering performance bottleneck. Large documents (10K+ objects) cause UI lag. Must implement incremental rendering, viewport culling, dirty rectangle optimization. Requires deep Canvas/WebGL knowledge.
Integration Complexity Score: High
Mitigation: Implement API Gateway pattern to centralize routing logic, use Redis as shared state store for sync servers (track document→server mapping for sticky sessions), adopt event-driven architecture to decouple systems (use message queue for async operations like asset processing).
SECTION 3: RESOURCE FEASIBILITY ANALYSIS
3.1 Team Capability Assessment
Critical Skill Gaps:
- Canvas/WebGL Optimization (Required: Advanced | Current: None): No team members have production experience optimizing canvas rendering or WebGL shaders. This is critical path for performance feasibility. Gap: Need 1 senior graphics engineer. Mitigation: Hire senior engineer with 5+ years canvas/WebGL experience, proven track record at companies like Figma, Miro, Canva. Estimated time-to-hire: 8-12 weeks. Loaded cost: $200K/year.
- Real-time Infrastructure at Scale (Required: Advanced | Current: Intermediate): Team has built WebSocket features but not at >1000 concurrent connections with sticky session load balancing. Gap: Need 1 infrastructure engineer with real-time systems experience. Mitigation: Hire infrastructure specialist with experience scaling WebSocket/Socket.io deployments. Time-to-hire: 6-10 weeks. Cost: $180K/year.
- CRDT Algorithms (Required: Intermediate | Current: None): Team understands collaborative editing conceptually but has never implemented CRDT. Gap: Manageable via library adoption (Yjs) + 2-week training/ramp-up. Senior engineers can learn from Yjs documentation. Mitigation: Budget 2 weeks for 2 senior engineers to deep-dive Yjs, build proof-of-concept, document integration patterns for team.
Team Capability Score: Significant gaps (challenging)
Team is strong on general full-stack development (React, Node.js, PostgreSQL) but lacks specialized graphics and real-time infrastructure expertise critical for this product. Gaps are fillable through hiring but represent 10-12 week delay risk if hiring takes longer than projected.
3.2 Budget Feasibility
Development Costs:
- • Engineering time: 17 engineers × 9 months × $12K/month loaded cost = $1,836,000
- • Design/Product time: 2 designers × 9 months × $10K/month = $180,000
- • QA/Testing time: 1 QA engineer × 9 months × $9K/month = $81,000
- • Subtotal: $2,097,000 (full team cost, but project is not 100% allocation)
- • Adjusted for 60% allocation (rest on maintenance, other projects): $2,097,000 × 0.6 = $1,258,200
Technology Costs:
- • Infrastructure (AWS: EC2, RDS, ElastiCache, S3, CloudFront): $97,200 (9 months)
- • Software licenses (Figma, monitoring tools, CI/CD): $18,000
- • Third-party services (Auth0, SendGrid, error tracking): $27,000
- • Subtotal: $142,200
External Costs:
- • Specialized hiring (graphics + infrastructure engineers): $285,000 (9 months × 2 × ~$15.8K/month)
- • Security audit + penetration testing: $35,000
- • Performance optimization consulting (if needed): $20,000
- • Subtotal: $340,000
Contingency:
- • Risk buffer (25% for unknowns): $435,100
TOTAL ESTIMATED COST: $2,175,500
AVAILABLE BUDGET: $800,000 (stated budget for project-specific costs, not full team salaries)
Clarified Budget Analysis:
The $800K budget appears to cover incremental costs (new hires, infrastructure, external services) rather than full team cost (which is sunk cost—team exists regardless). Recalculating with incremental costs only:
- • New hires (2 specialists × 9 months): $285,000
- • Infrastructure & technology: $142,200
- • External services & audits: $55,000
- • Contingency (20%): $96,440
- • INCREMENTAL TOTAL: $578,640
Budget Feasibility: Within budget with 28% margin ($221,360 remaining)
Project is financially feasible if budget covers incremental costs. If budget must cover full team allocation, project is significantly over budget and requires rebudgeting discussion.
SECTION 6: GO/NO-GO RECOMMENDATION
Final Feasibility Assessment:
- • Technical Feasibility: 72/100 (feasible but requires specialized execution)
- • Resource Feasibility: 65/100 (skill gaps fillable, budget tight but workable)
- • Timeline Feasibility: 68/100 (achievable with scope reduction and focused execution)
- • Risk-Adjusted Feasibility: 61/100 (applies 15% risk discount due to performance and scale uncertainties)
Overall Feasibility Score: 66.5/100
Interpretation: Feasible with mitigation — Proceed with risk management (60-79 range)
RECOMMENDATION: CONDITIONAL GO
Conditions for GO:
- Hiring Requirement: Secure commitments from senior graphics engineer and infrastructure specialist within 6 weeks. Begin hiring immediately. If hiring extends beyond 8 weeks, reassess timeline feasibility.
- Scope Reduction: Reduce initial launch scope by 30%: Defer advanced features (gradients, blend modes, effects, plugin SDK) to Phase 2 (post-launch). Focus Phase 1 on core collaborative editing, basic shapes (rectangle, circle, line, text), layer management, export to PNG/SVG.
- Performance Validation: Complete Week 4 proof-of-concept demonstrating canvas rendering at 5,000 objects with <16ms frame time (60fps) and Yjs sync with 50 concurrent users with <100ms latency. If PoC fails performance targets, escalate to executive team for go/no-go re-evaluation.
- Budget Confirmation: Confirm that $800K budget covers incremental costs (new hires, infrastructure, external services) and that existing team allocation is separate sunk cost. If budget must cover full team, increase to $2.2M or reduce timeline/scope further.
Rationale:
This project sits in the 60-79 feasibility range—it's not a slam-dunk, but it's achievable with proper risk mitigation. The core technology (real-time collaborative editing with CRDTs) is proven by competitors like Figma, Miro, and Google Docs, de-risking the "is this even possible?" question. Our primary risks are execution-focused: Do we have the specialized graphics and infrastructure expertise to build performant systems at target scale? The answer is "not yet, but we can acquire it" through strategic hiring. The 9-month timeline is aggressive but realistic if we: (1) Reduce scope to MVP, deferring 30% of features that add complexity but not core value, (2) Hire the right specialists immediately (graphics + infrastructure engineers), (3) De-risk performance through early PoC validation, catching issues in Week 4 rather than Month 7. The budget is workable with $578K incremental costs against $800K budget, leaving 28% margin for overruns. If all four conditions are met—hiring successful, scope reduced, PoC validates performance, budget confirmed—confidence level rises from 6.5/10 to 8/10 and project should proceed. If any condition fails (e.g., can't hire graphics engineer, PoC shows canvas can't hit 60fps target), we have early warning to pivot or pause rather than discovering failure late.
When to Reconsider:
Re-evaluate GO decision if: (1) Hiring extends beyond 8 weeks (timeline risk increases to unacceptable levels), (2) Week 4 PoC fails to meet performance targets (<60fps or >100ms sync latency), indicating fundamental technical feasibility issue, (3) Budget constraints tighten below $550K incremental spend, forcing further scope cuts that compromise product viability, (4) Competitive landscape shifts (e.g., Figma announces similar feature, eliminating differentiation value).
Prompt Chain Strategy
For optimal results, break the technical feasibility study into three sequential prompts that build comprehensive analysis:
🔗 Step 1: Requirements Clarification & Baseline Analysis (Foundation)
Objective: Establish clear understanding of what's being proposed and current state capabilities.
🔗 Step 2: Deep Technical & Resource Analysis (Investigation)
Objective: Conduct rigorous evaluation of technical, resource, timeline, and risk dimensions.
🔗 Step 3: Alternatives Exploration & Final Recommendation (Decision)
Objective: Synthesize analysis into actionable recommendation with alternatives and governance framework.
Human-in-the-Loop Refinements
1. Validate Technology Maturity Claims Through Hands-On Proof-of-Concept
Challenge: AI-generated technology assessments rely on public information—documentation, benchmarks, case studies—which can be outdated, optimistic, or not applicable to your specific use case. "Handles 1M users" in vendor marketing might mean "1M users in specific idealized scenario," not your workload.
Refinement: For any technology scored <80/100 on maturity or flagged as "high risk," invest 3-5 days building focused proof-of-concept: (1) Identify the riskiest assumption—e.g., "Yjs CRDT can sync 100 concurrent users editing same document with <100ms latency." (2) Build minimal PoC testing only that assumption—not full feature, just the risky part. Set up Yjs sync server, simulate 100 clients making random edits, measure sync latency p50/p95/p99. (3) Compare PoC results against requirements. If Yjs delivers 85ms p95 latency → assumption validated. If 450ms p95 latency → assumption failed, technology not suitable. (4) Update feasibility assessment with empirical data replacing theoretical analysis. PoC often reveals surprises: Technology performs better than expected (increase confidence), or worse (requires alternative), or "works but needs heavy optimization" (adds cost/time). Better to learn this in Week 1 through 3-day PoC than Month 6 when you're committed.
2. Stress-Test Timeline Estimates with Historical Team Velocity Data
Challenge: Effort estimates are theoretical ("this should take 8 person-weeks") but team velocity varies wildly based on seniority, domain familiarity, technical debt, and organizational friction. A feature estimated at 8 weeks might take 6 weeks with senior team on greenfield project, or 14 weeks with junior team in legacy codebase.
Refinement: Calibrate estimates against historical team velocity: (1) Review last 3 projects: How did estimated effort compare to actual effort? If team consistently delivers in 120-150% of estimates, your velocity factor is 1.2-1.5× (apply this multiplier to current estimates). (2) Account for project type: Greenfield projects move faster (fewer constraints), brownfield/legacy integration projects move slower (unexpected dependencies). If current project requires deep integration with legacy systems, add 30-40% time buffer beyond baseline estimate. (3) Adjust for skill gaps: If project requires skills team doesn't have (e.g., WebGL optimization), add 40-60% learning curve buffer for first implementation. Subsequent features using same skill go faster. (4) Track unknowns: Count "?" or "TBD" items in requirements. Each unknown adds risk—if >20% of requirements have unknowns, increase buffer from 30% to 50%. By anchoring estimates to team's actual historical performance rather than theoretical "ideal team" assumptions, you generate realistic timelines that executives can trust.
3. Conduct Pre-Mortem Analysis to Surface Hidden Risks
Challenge: Risk identification tends to be reactive and conservative—teams list "obvious" risks (budget overruns, hiring delays) but miss subtle, high-impact risks that emerge from complex system interactions or organizational dynamics.
Refinement: Run pre-mortem exercise with team: (1) Hypothesize project failure: "It's 9 months from now. The project has failed catastrophically—missed deadline by 6 months, burned through 2× budget, delivered unusable product. What happened?" (2) Brainstorm failure scenarios: Have each team member write 3-5 specific failure stories independently. Example: "Graphics engineer quit at Month 4, replacement took 3 months to hire and onboard, lost 6 months." "Canvas performance was fine in testing but collapsed in production under real user load—required complete re-architecture." (3) Consolidate and prioritize: Group similar failures, identify top 8-10 most plausible and devastating scenarios. (4) Reverse-engineer risks: For each failure scenario, what's the underlying risk that must be managed? "Graphics engineer quits" → Risk: Key person dependency. Mitigation: Cross-train second engineer on graphics, document critical knowledge. (5) Add these risks to formal risk register: Pre-mortem often surfaces risks that structured analysis misses because it leverages team's intuitive/experiential knowledge of what actually goes wrong in real projects vs. theoretical risk taxonomies. This technique has been shown to identify 30-40% more risks than traditional brainstorming.
4. Validate Budget Estimates with Real Vendor Quotes and Market Rates
Challenge: Budget estimates in AI-generated feasibility studies use generic cost assumptions ($X/month for infrastructure, $Y for contractors) that may not reflect current market realities, regional variations, or vendor pricing structures.
Refinement: Replace generic estimates with real quotes: (1) Infrastructure costs: Use AWS/GCP/Azure cost calculators with specific resource configurations (instance types, storage volumes, bandwidth projections). Add 30-40% buffer for unplanned usage (dev/staging environments, spike traffic, inefficient queries before optimization). Request quote from vendor sales if spending will exceed $10K/month (often get discounts not shown in calculator). (2) Hiring costs: Check Hired.com, Levels.fyi, or Stack Overflow Salary Survey for current market rates by role, seniority, and location. If hiring "senior graphics engineer," see that NYC market rate is $180-220K total comp vs. Denver $150-180K vs. remote $160-200K. Factor in recruiting fees (20-25% of first-year salary if using external recruiters) and time-to-hire (longer search = more expensive due to project delays). (3) Contractor/consultant rates: Get 3 quotes from agencies or freelancer platforms (Toptal, Gun.io, local consultancies). Rates vary widely ($100-300/hour) based on expertise—generic full-stack developer vs. specialized WebGL performance engineer. (4) Third-party services: For any service budgeted >$500/month, request actual pricing from vendor (Auth0, SendGrid, Datadog, etc.)—usage-based pricing can surprise you when volume scales. By replacing assumptions with real quotes, you catch budgeting errors before they become project-killing surprises.
5. Conduct Skills Audit Through Hands-On Assessment, Not Self-Reporting
Challenge: Team capability assessments typically rely on self-reported skill levels ("I'm proficient in React") or resume claims, which are notoriously unreliable. "Proficient" means different things to different people—might mean "I built a tutorial app" or "I architected 100K-user production system."
Refinement: Validate skills through practical assessment: (1) For critical technical skills (e.g., Canvas optimization, real-time systems, CRDT algorithms), create small (2-4 hour) hands-on challenge. Example: "Here's a Canvas with 1000 rectangles. Optimize rendering to maintain 60fps when dragging objects." Review solution quality—does engineer demonstrate deep understanding (viewport culling, dirty rectangles, requestAnimationFrame) or surface-level knowledge (basic event handlers)? (2) Conduct technical interviews with team members as if they were external candidates—ask probing questions about technologies they'll use. "You say you know WebSockets—explain how you'd handle reconnection with state sync." "Describe trade-offs of Operational Transform vs. CRDT for collaborative editing." Quality of answers reveals actual depth. (3) Review past code/projects: Look at recent work engineer has done in relevant technologies. Code quality, architecture decisions, problem-solving approaches reveal more than claims. (4) Score empirically: Based on assessment and code review, assign skill level—Expert (teaches others, handles edge cases), Proficient (independently productive), Intermediate (productive with guidance), Beginner (needs significant support), None (no real experience). This reality-check often reveals gaps missed by self-assessment: Team thought they had 3 "proficient" real-time engineers but assessment shows 1 proficient + 2 intermediate = need to hire senior specialist or adjust timeline expectations.
6. Establish Decision Gates with Go/No-Go Criteria at Each Phase
Challenge: Feasibility studies deliver one-time GO/NO-GO decision at project start, but conditions change during execution—technologies prove harder than expected, requirements shift, team members leave. Projects continue on momentum even when no longer feasible, leading to expensive failures.
Refinement: Build adaptive decision framework with checkpoints: (1) Define phase gates: At end of each project phase (Foundation, Core Development, Optimization, Launch Prep), conduct formal go/no-go review before proceeding to next phase. Don't let project roll forward automatically. (2) Establish quantitative go/no-go criteria for each gate: Gate 1 (End of Foundation - Week 4): PoC validates performance (<16ms frame time, <100ms sync latency); critical hires completed (graphics + infrastructure engineers onboarded); technical architecture reviewed and approved. Criteria: If PoC fails performance by >30%, NO-GO (escalate to executive re-evaluation). If hiring incomplete, CONDITIONAL GO (delay 2 weeks, restart if still incomplete). Gate 2 (End of Core Development - Week 12): 60% of MVP features complete; major integration points working; no critical technical blockers. Criteria: If <50% features complete, NO-GO (timeline infeasible). If critical blocker exists with no 2-week resolution path, NO-GO (technical infeasibility). (3) Track leading indicators: Monitor weekly metrics that predict trouble—velocity (story points/week), unplanned work ratio (>30% = scope creep), technical debt accumulation, team morale. If metrics deteriorate for 3 consecutive weeks, trigger early feasibility review. (4) Conduct quarterly "still feasible?" re-assessment: Re-run simplified feasibility analysis at Month 3, 6 to ask "if we were deciding today, would we start this project?" If answer is "no," consider kill decision despite sunk costs. This approach prevents sunk-cost fallacy ("we've invested 6 months, must continue") when objective analysis says "continuing will waste another 6 months + budget with low success probability—better to stop now."
