False-Positive Postmortem: “Three Developers Next Week” Is Not Yet a Technical Outsourcing Brief

Signals to watch

• Business outcome and technical scope can be described
• Internal owner, current team, and dependencies are clear
• Deliverables, acceptance, and timing can be decomposed
• Access, security, contract, and working relationship need confirmation

Direct answer

“We need three developers next week” describes headcount and timing, not a project brief. Executable outsourcing needs a business objective, technical scope, current systems, team relationship, deliverables and acceptance, access and data, security, budget ownership, and an appropriate contract and workforce boundary.

Original judgment

The original judgment was that an urgent request for three developers with a start date represented high-intent outsourcing and should receive CVs immediately.

What was actually happening

There was no project or deliverable. The buyer wanted people to work indefinitely under an internal manager, while stack, permissions, acceptance, budget, and local relationship classification were unknown.

Why the judgment failed

1. Headcount and urgency were treated as scope
2. Business objective and deliverables were not confirmed
3. Management and performance control were ignored
4. Code, data, and system access were not inventoried
5. Project contracting, staff augmentation, and employment reality were not separated

Missing evidence

• Business objective and product owner
• Codebase, architecture, and technical debt
• Tasks, milestones, and acceptance
• Location, management, and contract relationship
• Budget, payment, security, and intellectual property

Corrected rule

Upgrade to a technical outsourcing brief only when the need can be expressed as a business outcome, scope, owner, deliverables, acceptance, access, and timing, with the contract and working relationship appropriately reviewed.

Revised handling process

1. Ask for the business outcome and fixed date
2. Inventory systems, code, and dependencies
3. Rewrite headcount as work packages and deliverables
4. Define internal ownership, communication, and acceptance
5. Confirm access, security, IP, and contract relationship

Review questions

1. Which business problem does the project solve?
2. Which work package belongs to each developer?
3. What systems and dependencies exist?
4. Who manages work and accepts delivery?
5. Which code and data are required?
6. Who confirms contract, payment, and relationship?

Reusable conclusions

• Headcount and urgency are not scope.
• Work packages matter more than CV lists.
• Acceptance ownership precedes start.
• Minimum access applies to outsourcing.
• A project contract cannot disguise the real working relationship.

Related reading：remote contractor checklist and AI recruitment micro-cases This postmortem improves qualification rules and does not claim a customer outcome.

Frequently asked questions

Why did the original judgment become a false positive?

There was no project or deliverable. The buyer wanted people to work indefinitely under an internal manager, while stack, permissions, acceptance, budget, and local relationship classification were unknown.

What is the corrected rule?

Upgrade to a technical outsourcing brief only when the need can be expressed as a business outcome, scope, owner, deliverables, acceptance, access, and timing, with the contract and working relationship appropriately reviewed.

What should the first review ask?

Which business problem does the project solve?; Which work package belongs to each developer?; What systems and dependencies exist?

Sources and further reading

1. AWS: Detailed Application Assessment
2. International Labour Organization: Employment Relationship Recommendation No. 198