FDE Project Delivery Process: End-to-End Analysis from Requirements Discovery to Knowledge Transfer

Many enterprises are interested in FDE (Forward Deployed Engineer), but they all share a common question: How is an FDE project delivered? And how is it different from traditional outsourcing?

Everyone is familiar with the traditional outsourcing delivery process: requirements research → solution design → development → testing → go-live → acceptance. But the FDE model works completely differently — it emphasizes embedding, iteration, and outcome orientation, rather than progressing linearly through stages.

This article breaks down the standard FDE delivery process, from initial discovery to knowledge transfer, covering what happens in each stage, what is delivered, and how effectiveness is measured — to help you build a complete understanding.

---

Core Characteristics of the FDE Delivery Process

Before diving into the specific stages, let’s first understand the fundamental difference between FDE delivery and traditional delivery:

Characteristic	Traditional Waterfall	FDE Model
Delivery approach	Linear — one stage finishes before the next begins	Iterative — every iteration forms a complete closed loop
Requirements management	Locked in up front; changes go through a formal process	Continuously evolving; can be adjusted every two weeks
Delivery frequency	One-time delivery at project completion	Demonstrable results every week
Acceptance method	Final acceptance against the requirements list	Continuous acceptance based on business outcomes
Customer participation	Discovery at the start + acceptance at the end, minimal involvement in between	Deeply involved throughout, with daily communication
Risk control	Scope fixed up front; risks are borne later	Small, fast steps; issues are caught and adjusted early

In one sentence: Traditional outsourcing “delivers features against a contract,” while FDE “runs toward outcomes together with the customer.”

---

The Five Stages of the Standard Delivery Process

Stage 1: Discovery and Planning (Week 1)

This is the starting point of the project and also the most critical stage. The root cause of many failed projects is that discovery was not done thoroughly.

Core Tasks

Task	Description	Participating Roles
Business current-state diagnosis	Deep understanding of current business processes, pain points, and goals	FDE + Business Owner
System current-state assessment	Existing system architecture, data landscape, technology stack	FDE + Technical Lead
Data quality assessment	Data completeness, accuracy, and accessibility	FDE + Data/Business Team
Success criteria alignment	Define the metrics by which project success is measured	FDE + Project Sponsor
Priority ranking	Determine what to do first and what to do later	FDE + Business + Technical
Risk identification	Identify potential risks and obstacles in advance	FDE + Customer Team

Deliverables

1. Current-State Diagnosis Report: Business process as-is, system as-is, and data quality assessment
2. Project Proposal: Goals, scope, technical solution, and implementation plan
3. Success Metrics Definition: Quantifiable success criteria (e.g., “increase lead conversion rate by 15%”)
4. Risk Register and Mitigation Plan: Identified risks and corresponding countermeasures

Key Points

• You must get access to the decision-maker: Without decision-maker involvement, it will be very difficult to drive things forward later
• Success criteria must be quantified: Not vague statements like “improve efficiency” — there must be numbers
• Data is the core prerequisite: For AI projects especially, data quality must be assessed first — with poor data, even the best FDE cannot deliver results
• Don’t promise what can’t be done: A good FDE will tell you “what can and cannot be done” at this stage, rather than saying yes to everything

This stage is also commonly known as the “Discovery Week” — spend one week mapping out every aspect of the project, and only then decide whether to proceed and how.

---

Stage 2: Design and Prototyping (Week 2)

Once the diagnosis is clear, we move into the design and prototyping stage. The goal of this stage is: quickly build a demonstrable prototype to validate the feasibility of the solution.

Core Tasks

Task	Description	Participating Roles
Detailed solution design	Architecture design, data flow design, interface design	FDE + Technical Team
Prototype development	Build a runnable prototype of the core functionality	FDE (customer technical team may participate)
Data access validation	Verify whether key data can be obtained and whether its quality is sufficient	FDE + Data Team
Prototype demo and feedback	Demo for the business team and collect feedback	FDE + Business Team
Solution adjustment and optimization	Adjust the solution based on feedback	FDE

Deliverables

1. Technical Solution Document: Architecture diagrams, data flow diagrams, and interface definitions
2. Runnable Prototype: Demo version of the core functionality
3. Data Access Plan: Data sources, access methods, and cleansing rules
4. Iteration Plan: Iteration schedule for subsequent development

Key Points

• The prototype must really run: Not a PowerPoint mockup, but a clickable, runnable prototype that shows real data
• Use real data: Try to build the prototype with the customer’s real data rather than fake data — fake data looks nice but hides problems
• Iterate quickly: The prototype isn’t finalized in one version; it may go through 2–3 revisions
• Don’t pursue perfection: The purpose of a prototype is to validate direction, not to build the final product — make it usable; details can be refined later

After this stage, the customer can clearly see “roughly what the final product will look like” and decide whether to continue investing. This is an important decision point — if the prototype validation shows poor results, the project can be stopped early with minimal loss.

---

Stage 3: Development and Iteration (Weeks 3–5)

This is the main stage of the project, and also the stage where the FDE model differs most from traditional outsourcing.

Traditional outsourcing says “test everything together after development is complete,” while FDE follows “one iteration per week, with a complete development–testing–demo–feedback loop in each iteration.”

Iteration Cadence (Two-Week Cycle)

Monday: Iteration planning meeting → decide what to build in this iteration
Tuesday–Thursday: Development + continuous testing
Friday: Demo + retrospective + priority adjustment

Core Activities in Each Iteration

Activity	Frequency	Participating Roles	Purpose
Daily stand-up	15 minutes per day	FDE + Contact Person	Sync progress, surface blockers
Iteration planning	Once every two weeks	FDE + Business + Technical	Define iteration goals and tasks
Iteration demo	Once every two weeks	FDE + Business Team + Sponsor	Showcase results, collect feedback
Iteration retrospective	Once every two weeks	FDE + Core Team	Summarize lessons, improve process
Code review	Ongoing	FDE + Customer Technical Team	Ensure code quality, enable knowledge transfer

Deliverables

Per iteration:

1. Runnable Incremental Features: New features completed in this iteration
2. Iteration Demo Record: Demo content, feedback, and action items
3. Updated Documentation: Technical documentation, user manuals, etc.

End of entire stage:

1. Complete Feature System: All planned features developed
2. Test Report: Functional, performance, and security test results
3. User Operations Manual: Usage guide for business users
4. Operations Manual: Operations guide for the technical team

Key Points

• Small, fast steps with timely feedback: Don’t wait until “everything is done” to review — look at results every week
• Priorities can be adjusted: If the business side discovers a more important new need, the next iteration’s priorities can be reorganized
• Customer team must participate in development: It’s not the FDE coding alone in a silo; the customer’s technical team should join in code review and testing together
• Quality cannot be compromised: Fast iteration doesn’t mean poor quality — every iteration must include complete testing

The standard development cycle at FDE practices is 6 weeks to deliver an end-to-end AI workflow. Two weeks for discovery + prototyping, then four weeks for development + iteration. This cadence has been validated across a large number of projects — balancing speed with quality.

---

Stage 4: Go-Live and Validation (Week 6)

After development is complete, we enter the go-live and outcome validation stage.

For traditional outsourcing, go-live means “deploy it and you’re done.” For FDE, go-live means “it not only has to go live, it has to run and deliver results.”

Core Tasks

Task	Description	Participating Roles
Production environment deployment	Deploy the system to the production environment	FDE + Operations Team
Data cutover/integration	Connect real data and verify data accuracy	FDE + Data Team
User training	Train business users on how to use the system	FDE + Business Owner
Pilot observation	Monitor runtime after go-live and address issues promptly	FDE + All
Outcome validation	Verify actual results against success metrics	FDE + Sponsor
Issue fixing and optimization	Fix issues based on pilot operation findings	FDE

Deliverables

1. Production-Ready System: Officially live and running
2. Training Materials: Operations manual, video tutorials, FAQ
3. Outcome Validation Report: Comparative analysis of actual results vs. expected goals
4. Go-Live Issue Log and Fix Records: Issues found during go-live and how they were handled

Key Points

• Go-live is not the finish line, it’s the starting line: The first week after go-live is the most critical — monitor runtime closely
• Have a rollback plan: In case something goes wrong, be able to quickly revert to the old system
• User training must be thorough: No matter how good the system is, it’s useless if users don’t know how to use it
• Outcome validation must be objective: Let the data speak — don’t settle for “it feels pretty good”; check each success metric defined at the start of the project one by one

The core goal of this stage is to “ensure the system is genuinely usable, genuinely being used, and genuinely delivering results.” Many projects die at the stage of “it’s live but nobody uses it” — this is precisely where the value of the FDE model lies: go-live is not the end; meeting the success metrics is.

---

Stage 5: Knowledge Transfer and Handover (Weeks 6–8)

This is one of the biggest differences between the FDE model and traditional outsourcing.

Traditional outsourcing handover is “hand over code + hand over documents,” then goodbye. FDE knowledge transfer is “hand-holding teaching to ensure the customer team can maintain and iterate independently.”

Core Tasks

Task	Description	Participating Roles
Code walkthrough	Explain code architecture and implementation logic module by module	FDE + Customer Technical Team
Operations training	Deployment, monitoring, alerting, troubleshooting	FDE + Operations Team
Iteration methodology training	How to continue iterating features using agile methods	FDE + Product/Technical Team
Documentation completion	Fill in all technical and operations documentation	FDE (customer team participates)
Handover acceptance	Confirm all knowledge and documentation have been delivered	FDE + Project Sponsor
Post-project support agreement	Determine the support model after project completion	FDE + Customer

Deliverables

1. Complete Codebase: Source code with standardized comments
2. Comprehensive Technical Documentation: Architecture documents, interface documents, database documents, operations manual
3. Knowledge Transfer Confirmation Checklist: Item-by-item confirmation of knowledge transfer completion
4. Post-Project Support Plan: If needed, agreed support methods and fees

Three Layers of Knowledge Transfer

Layer	Content	Importance
Layer 1: Artifacts	Code, documentation, tools	Foundation — a must-have
Layer 2: Method	How it’s done, why it’s done this way, how to troubleshoot	Core — determines whether independent maintenance is possible
Layer 3: Thinking	Decision-making rationale, trade-off logic, future evolution direction	Highest level — determines whether iteration can continue

Many outsourcing projects only reach Layer 1. FDE projects aim for Layer 2, and excellent FDEs can achieve Layer 3.

Key Points

• Knowledge transfer starts on day one: Not done only at project end, but synchronized throughout the process
• Use “doing” instead of “telling”: Don’t just lecture — let the customer team do it themselves, with the FDE guiding alongside
• Use a handover checklist: Check item by item to ensure nothing is missed
• Leave a safety net: Agree on the support model after project completion, such as a one-month free support period or pay-per-hour on-call support

---

End-to-End Timeline Overview

Taking a standard 6-week FDE project as an example:

Week	Stage	Core Outputs	Decision Point
Week 1	Discovery and Planning	Current-state diagnosis report + project proposal + success metrics	Continue? Approve the solution?
Week 2	Design and Prototyping	Runnable prototype + technical solution + iteration plan	Does the prototype meet expectations? Proceed to development?
Week 3	Iteration Development 1	First version of incremental features	—
Week 4	Iteration Development 2	Second version of incremental features, midpoint review	Need to adjust direction?
Week 5	Iteration Development 3	Complete features + test report	—
Week 6	Go-Live and Validation	System go-live + outcome validation report	Are results up to standard? Accept the project?
Weeks 7–8	Knowledge Transfer	Complete handover + knowledge transfer confirmation	Project officially closes

Note: This is the standard 6-week delivery cycle (8 weeks total with 2 weeks of knowledge transfer). In practice, the cycle varies depending on complexity and scope. Simple scenarios may take 4 weeks, while complex projects may require 3–6 months.

Time Allocation by Stage

Stage	Share of 6-Week Project	Share of 8-Week Project	Core Work
Discovery and Planning	~17% (1 week)	~12.5% (1 week)	Research, solution, goal alignment
Design and Prototyping	~17% (1 week)	~12.5% (1 week)	Prototype development, solution validation
Development and Iteration	~50% (3 weeks)	~37.5% (3 weeks)	Feature development, iterative optimization
Go-Live and Validation	~16% (1 week)	~12.5% (1 week)	Deployment, training, outcome validation
Knowledge Transfer	—	~25% (2 weeks)	Code handover, training, documentation

Consolidated Deliverables Checklist Across All Stages

Deliverable Type	Discovery	Prototyping	Development	Go-Live	Handover
Documentation
Current-state diagnosis report	✅
Project proposal	✅
Success metrics definition	✅
Technical solution document		✅	Updated
User operations manual			Draft	✅ Final
Operations manual			Draft	✅ Final
Code
Runnable prototype		✅
Incremental feature code			Each iteration
Complete production code				✅	✅ Final
Automated tests			Continuously added	✅
CI/CD configuration			✅
Validation
Iteration demo records			Each iteration
Test report				✅
Outcome validation report				✅
Knowledge transfer confirmation checklist					✅
Training
User training materials				✅
Technical training (code walkthrough)					✅
Operations training					✅

Total: A complete FDE project delivers approximately 15–20 items, covering the full chain from solution to code, and from testing to training.

Cycle and Resource Allocation by Project Scale

FDE projects can be large or small. Below are typical configurations for different project scales:

Project Scale	Typical Scenario	FDE Headcount	Total Duration	Discovery	Development	Go-Live + Handover	Suitable Customers
Small (Quick Validation)	Single-scenario AI pilot, e.g., AI customer service, lead scoring	1	4–6 weeks	1 week	2–3 weeks	1–2 weeks	SMEs, startups
Medium (Standard Delivery)	2–3 linked scenarios, e.g., CRM AI upgrade	1–2	8–12 weeks	1–2 weeks	5–7 weeks	2–3 weeks	Mid-sized enterprises, large-enterprise department level
Large (System Transformation)	Multi-system integration + multi-scenario, e.g., full-process AI transformation	2–3	3–6 months	2–4 weeks	2–4 months	4–6 weeks	Large enterprises, group-level
Extra-Large (Full Transformation)	Enterprise-level AI transformation, multiple departments and systems	3–5+	6–12 months+	1–2 months	4–9 months	1–2 months	Large groups, multinational enterprises

Note: The above are standard references. The actual cycle depends on factors such as data foundation, system complexity, and customer collaboration. The worse the data, the older the systems, and the slower the collaboration, the longer the cycle.

Efficiency Advantages of Iterative Development

Why does FDE use agile iteration instead of waterfall? Because the iterative model has higher overall efficiency:

Metric	Waterfall Development	FDE Agile Iteration	Improvement
Time to first usable feature	Project end (3–6 months later)	Week 2–3	80–90% earlier
Requirements change response time	2–4 weeks (formal change process)	1–3 days (done in the next iteration)	80–90% shorter
Time to discover wrong direction	Mid-to-late project (large losses)	Checked every two weeks (small losses)	5–10x faster loss mitigation
Customer engagement	Low (only at start and end)	High (weekly communication)	Significantly improved
Final product fit	60–70% (requirements changed but weren’t tracked)	85–95% (continuously adjusted throughout)	20–30% improvement
Rework rate	20–30% (problems found all at once at the end)	5–10% (corrected promptly throughout)	60–70% lower
Team morale	Low (no visible results for a long time)	High (sense of achievement every week)	Significantly improved

Data sources: Aggregated from agile development industry research (Standish Group Chaos Report, Forrester Agile Benchmark) and FDE project practice data.

For AI projects, where requirements are highly uncertain, the iterative model’s advantages are even more pronounced — waterfall AI projects have a failure rate of over 70%, while the agile iterative model can achieve a success rate of over 80%.

Roles in an FDE Project

A typical FDE project requires the following roles:

Customer-Side Roles

Role	Responsibilities	Time Commitment
Project Sponsor	Decision-making, resource coordination, outcome acceptance	1–2 hours per week
Business Owner	Requirements liaison, business confirmation, user coordination	5–8 hours per week
Technical Contact	System integration, data access, technical communication	5–10 hours per week
End-User Representative	Testing, feedback, training participation	2–4 hours per week

FDE-Side Roles

Role	Responsibilities	Notes
FDE Lead	Overall project responsibility, solution design, key development	At least 1 per project
FDE Engineer	Hands-on development, integration, testing	Sized to project scale
Technical Advisor (as needed)	Expert support in specific domains	E.g., AI algorithm specialist, security specialist, etc.

Collaboration Model

Figure: Three-layer collaboration and communication model for FDE projects

---

Key Success Factors for FDE Projects

Based on lessons learned from a large number of projects, FDE project success depends on several key factors:

1. The Customer Has a Clear Sponsor with Decision-Making Authority

This is the single most important factor. Without decision-maker support, even the most capable FDE cannot drive things forward. The Sponsor doesn’t need to be involved every day, but must be able to make decisions and coordinate resources at critical moments.

2. Data and System Access Are Cleared Up Front

Especially for AI projects, data is the foundation. Before the FDE comes on board, data permissions, system access, and API interfaces must be coordinated in advance. Otherwise, the first week will be entirely spent on approval processes with nothing getting done.

3. The Contact Person Is Reliable and Has Time to Invest

The FDE is not here to “do it for you” — they are here to “do it together with you.” If the customer’s contact is always busy with other things and hard to reach, the project will definitely not move fast.

4. Success Criteria Are Clear and Aligned Between Both Parties

Before the project starts, make it clear “what counts as success.” The more specific the better — for example, “after lead scoring goes live, sales follow-up efficiency improves by 20%,” rather than “improve sales efficiency.”

5. A Trusting and Transparent Communication Culture

The FDE model is built on trust. The customer must trust the FDE’s professional capability, and the FDE must be transparent with the customer — speak up promptly when difficulties arise, don’t hide them until the very end.

---

Common Pitfalls and How to Avoid Them

FDE Project Risk Matrix

In project management, risk = probability of occurrence × impact. Below are the most common risks in FDE projects and how to respond:

Risk	Probability	Impact	Risk Level	Mitigation Strategy	Responsible Stage
Poor data quality prevents model performance	High	High	🔴 Critical	Run data diagnosis in week 1; if data is insufficient, govern data first rather than forcing ahead	Discovery
Scope creep — scope keeps growing	High	Medium	🟠 High	Define priorities per iteration; add new requirements to the backlog; review scope every two weeks	Full lifecycle
Users don’t adopt the system	Medium	High	🟠 High	Involve users from day one; find seed users; demonstrate results with data	Full lifecycle
Contact person has no time; poor communication	Medium	Medium	🟡 Medium	Agree on communication cadence up front; Sponsor drives resource allocation	Discovery + Development
Slow permission approval delays progress	High	Low	🟡 Medium	Coordinate permissions before onboarding; run in parallel to avoid blockages	Discovery
Inadequate knowledge transfer; nobody can maintain after handover	Medium	High	🟠 High	Start knowledge transfer on day one; use a checklist for item-by-item confirmation; include a warranty period	Handover
Key person leaves; project interrupted	Low	High	🟡 Medium	FDE organization has backup mechanism; complete documentation enables quick handover	Full lifecycle
Results fall short of expectations; acceptance is difficult	Medium	Medium	🟡 Medium	Quantify and align success metrics up front; validate continuously throughout; adjust in time	Go-Live

Risk level legend: 🔴 Critical (requires focused attention and advance prevention) ｜ 🟠 High (develop a mitigation plan) ｜ 🟡 Medium (monitor regularly)

---

FDE Agile Delivery vs. Traditional Waterfall Delivery: A Head-to-Head Comparison

Many people ask: How does the FDE process differ from traditional project management? One table says it all:

Dimension	Traditional Waterfall	FDE Agile Delivery
Delivery approach	Linear: research → design → develop → test → go-live, step by step	Iterative: each iteration is a complete develop–test–demo loop
Requirements management	Locked in up front; changes go through a formal process, costing more time and money	Continuously evolving; priorities can be adjusted every two weeks; flexible response to change
Delivery cadence	All features delivered at once at project end	Demonstrable results every week; incremental delivery every two weeks
Customer participation	Discovery up front + mid-project reviews + acceptance at end; limited involvement in between	Deeply involved throughout; daily stand-ups, bi-weekly demos
Acceptance criteria	Against the requirements list — passing if features are built	Against business metrics — passing if results meet targets
Risk control	Scope fixed up front; problems only found later, with large losses	Small, fast steps; checked every two weeks; adjusted early to cut losses
Documentation volume	Document-heavy — tens or hundreds of pages of requirements and design docs	Lightweight documentation — enough is enough; the code and the running system are the best documentation
Team collaboration	Clear division of labor, each does their own job; communication goes through process	Close collaboration; FDE and customer team work together
Change cost	The later the change, the higher the cost (exponential growth)	Change cost is relatively stable; can be adjusted at any time
Applicable scenarios	Standardized projects with very clear requirements	Exploratory projects with dynamic requirements (AI, innovation projects)
Failure mode	“All or nothing” — you only know if it works at the very end	“Progressive” — discover early and adjust early; at worst there are partial results
AI project fit	⭐⭐ Very low	⭐⭐⭐⭐⭐ Best

The essence of the core difference: Waterfall assumes “requirements are certain; success comes from executing the plan as intended”; FDE agile assumes “requirements are uncertain; they need to be continuously explored and adjusted throughout the process.”

For AI projects, the latter is clearly closer to reality.

Phenomenon: As the project progresses, more and more requirements pile up, the scope keeps growing, and the timeline keeps slipping.

How to avoid:

• Define priorities for each iteration and only work on the highest-priority items
• Put new requirements into the backlog and evaluate them in the next iteration
• Review scope every two weeks to ensure alignment with goals
• Remember: fewer, well-crafted features are more valuable than many rough ones

Pitfall Two: Poor Data Quality

Phenomenon: Model performance is poor, and after investigation the root cause turns out to be bad data.

How to avoid:

• Run a data quality assessment in week 1, don’t wait until the development stage to find out
• If data quality is poor, do data governance first, then talk about AI
• Manage expectations — garbage in, garbage out is a law, not something an FDE can solve

Pitfall Three: Users Don’t Adopt or Use the System

Phenomenon: The system is built, but the business team doesn’t use it — which means it was built for nothing.

How to avoid:

• Involve user representatives from day one, rather than pushing the system on them only after it’s built
• Provide thorough training and patiently answer questions
• Find “seed users” — get a group of people using it first to create a demonstration effect
• Demonstrate results with data — when users see it genuinely saves them time and effort, they’ll naturally accept it

Pitfall Four: Inadequate Knowledge Transfer

Phenomenon: After the FDE leaves, nobody can maintain the system, and it gradually falls into disuse.

How to avoid:

• Start knowledge transfer on day one, not just at the end
• The customer’s technical team participates in development throughout, not only seeing the code at handover
• Use a detailed handover checklist and confirm item by item
• Include a 2–4 week “warranty period” with remote FDE support to ensure a smooth transition

---

Closing Thoughts

The FDE delivery process is both complex and simple.

Complex because: it requires the FDE to possess comprehensive capabilities across technology, business, communication, and project management; it requires deep collaboration with the customer team; it requires continuous iteration amid uncertainty.

Simple because: the core logic is just one thing — stand in the customer’s shoes, take responsibility for outcomes, and get it done.

Traditional outsourcing’s logic is “act according to the contract” — I do what’s in the contract, and I don’t touch what isn’t. FDE’s logic is “act according to outcomes” — whatever it takes to achieve the goal, do it.

These are two completely different mindsets, and this is the fundamental reason the FDE model is becoming increasingly popular.

---

📚 FDE Series Articles

Article	Core Content
Complete Guide to FDE (Forward Deployed Engineer)	Role definition, value, capability model, and pricing model fully analyzed
FDE vs. Traditional Outsourcing vs. In-House Team: Deep Comparison and Selection Guide	A comprehensive comparison of three models to help you choose the right delivery approach
FDE Project Delivery Process (this article)	Breakdown of the standard delivery process — what happens and what is delivered in each stage
Why Do AI Projects Need FDE? Avoiding 70% Implementation Failure	Core pain points of AI implementation and how FDE solves them

---

❓ Frequently Asked Questions

Q1: Why is an FDE project 6 weeks? Can it be faster?
6 weeks is the standard cycle for “single-scenario AI implementation” summarized by FDE practices — 1 week discovery + 1 week prototype + 3 weeks development + 1 week go-live validation. Can it be faster? Depends on project complexity. Simple scenarios (e.g., integrating one AI API) can be done in 2–3 weeks; complex scenarios (e.g., a complete CRM AI upgrade) may take 2–3 months. The key is not to chase speed, but that every stage has clear deliverables and decision points, allowing the customer to choose to continue, adjust, or stop at any time.

Q2: What if halfway through we find the direction is wrong?
This is precisely the advantage of the FDE model — early loss mitigation. A bi-weekly iteration retrospective lets you assess whether the direction is correct. If you find the direction is wrong, you can immediately adjust or even terminate the project. The loss is only 2–4 weeks of time and cost, not the massive loss of traditional outsourcing where “after six months you discover everything was wrong.” A good FDE will proactively tell you “this direction might be wrong, should we try a different approach?” rather than blindly pushing through to the end.

Q3: How much manpower does the customer need to invest in an FDE project?
Depends on project size and stage. For a standard 6-week project: the Business Owner invests about 5–8 hours per week, the Technical Contact about 5–10 hours per week, and the Sponsor about 1–2 hours per week. In total it’s roughly “half a person’s” workload. This investment is worthwhile — the more the customer invests, the better the project outcome and the more thorough the knowledge transfer. If the customer completely hands off, what the FDE builds is likely to not match actual needs.

Q4: How is an FDE project accepted? By what criteria?
Unlike traditional outsourcing, which accepts against a “feature list,” FDE projects are accepted against “business outcomes.” Quantified success metrics must be defined at the start of the project, such as “increase lead conversion rate by 15%,” “reduce customer service response time by 50%,” or “shorten contract review time from 2 days to 2 hours.” After go-live, run for 2–4 weeks and compare real data against the metrics — meeting them means passing. Of course, feature completeness is part of acceptance, but the core is outcomes, not the feature list.

Q5: After the project ends, what if there are new requirements?
Several options: first, continue cooperating on a “per person-day/hour” basis — call in the FDE for a few days when needed; second, a “subscription model” — a fixed number of FDE days per month for continuous iteration; third, a “new project model” — treat new requirements as an independent FDE project. Many enterprises choose the subscription model — it’s like having a senior expert on call, available when needed with no waste when not.

---

If you’d like to learn about the specific delivery arrangements for an FDE project, or assess whether your project is a good fit for the FDE model, feel free to get in touch.