Japan–Vietnam Project Delayed: Replace the Vendor?

#A delayed schedule is an outcome, not yet a cause

A red plan cannot explain why it is red. The same symptom—“two sprints behind”—can come from completely different mechanisms:

• Scope expanded but the baseline was never updated.
• Business requirements were not precise enough to become acceptance criteria.
• The Japan side needed several approval rounds while the Vietnam side kept the original dates.
• The BrSE transmitted words but did not clarify intent and acceptance conditions.
• The vendor lacks the technical capability or staffing it committed.
• Low quality creates loops of fixes, retesting, and reopened issues.
• The current architecture makes every change affect too much of the system.

JUAS IT2026 reports that among 172 projects that missed their quality plans, “insufficient vendor skills” was selected by 59.9%. Yet “insufficient consideration during planning” and “greater-than-expected business or system complexity” were also each selected by 48.8%. This is not Vietnam-specific offshore data, but it makes one point clear: replacing a supplier does not automatically repair planning failures or complexity the organization has not yet understood.

The first question is therefore not “Is this vendor bad?” It is:

If the entire team were replaced tomorrow, would the cause of the delay move into the new team with the work?

#Evidence test 1: Is the delivery data trustworthy?

A sponsor cannot decide from a completion percentage estimated by the delivery team itself. “80% complete” means nothing until you know 80% of which scope, which acceptance conditions have passed, and how much risk sits in the remainder.

I usually rebuild a fact baseline from the following artifacts:

If the vendor opens the artifacts, explains discrepancies, and corrects reports when evidence shows an error, the project still has a foundation for recovery. If every number exists only in a slide deck, the sponsor does not yet have enough data to choose “retain” or “replace.”

#Evidence test 2: Can the current team still recover?

A credible recovery plan is not a list of “more overtime, more people, and renewed commitment to the deadline.” It must show that the team understands the mechanism causing the delay and can change that mechanism.

Choose one small but end-to-end slice of work: requirement clarification, design, code, review, test, and demo. During a short validation cycle, observe five things:

1. Is the requirement converted into acceptance criteria before coding starts?
2. Is risk reported when discovered, or held until the scheduled meeting?
3. Do the actual decision owners on both sides respond through the agreed flow?
4. Does the Definition of Done stop work that is not ready?
5. After a defect, does the team change its way of working or only patch that defect?

This tests the delivery system's ability to learn and correct itself. It is not a race to close one ticket. The current team holds domain knowledge the next team will not have; if it can demonstrate recovery capability, retaining that knowledge is often less risky than replacing everyone.

By contrast, repeating the same promise without changing how the work operates is a red signal. A recovery plan matters only when artifacts and behavior change.

#Evidence test 3: Does the client control the project assets?

Control does not mean the client must operate everything itself. It means the business can continue the project without one vendor account or one individual becoming an irreplaceable bottleneck.

At minimum, verify:

• Which organization owns the source repository, who has administrative access, and whether the commit history is complete.
• Who owns the cloud, domain, CI/CD, monitoring, and third-party service accounts.
• Whether the environment can be recreated from current documentation or only one person knows how.
• Whether the data schema, migrations, and backup/restore process have been verified.
• Whether the backlog, issues, test evidence, and decision log can be exported.
• How the contract defines ownership of code, data, and accounts.

If these assets remain outside the client's control, announcing a vendor replacement before planning the handover can destroy more data and knowledge. Signs of a security breach, withheld assets, or an ownership dispute require immediate involvement from legal and information-security teams; a blog post cannot substitute for reading the actual contract.

#Decision matrix: The choice is not only “keep” or “replace”

After the three evidence tests, the sponsor has four practical intervention paths.

The important point is that replacing the company is not the only level of intervention. Many projects need one accountable end-to-end role replaced, or an independent client-side operator to rebuild the fact baseline and governance.

I describe the responsibility boundary on the Japan–Vietnam BrSE and Delivery Management page. To distinguish this role from someone who only transfers language, see the four-level BrSE maturity model. The article on why “Japanese quality” gets lost in offshore delivery goes deeper into converting tacit knowledge into testable criteria.

#When do I lean toward repairing governance?

I repair governance before replacing the vendor when most of the following remain true:

• The vendor opens the real data, including evidence unfavorable to itself.
• Key members understand the domain and cooperate with independent assessment.
• Repeated failures mainly come from requirements, decision rights, or an unclear Definition of Done.
• A small slice can move from requirement to acceptance under a changed operating model.
• The client also accepts responsibility for changing its part of the system.

“Repair governance” does not mean scheduling more meetings. It usually means fewer reporting layers, explicit decision rights, separating issues from risks, writing acceptance criteria before coding, and making quality visible earlier.

#When do I lean toward replacing the vendor?

I consider vendor replacement reasonable when one or more serious conditions exist:

• Reports cannot be reconciled with source code, builds, test results, or a running environment.
• The vendor repeatedly changes its explanation without updating the baseline or recovery plan.
• Committed key personnel are absent, with no replacement who has enough authority to own the outcome.
• The validation slice repeats the same requirement, review, or quality failure.
• Access to the repository, infrastructure, documentation, or data remains unjustifiably delayed.
• A security, compliance, or contractual breach requires formal escalation.

Even after deciding to replace, the objective remains business continuity, not winning an argument with the old vendor.

#Transition checklist: Do not carry the old debt into the new team

Before the new team accepts scope, lock down at least these artifact groups:

1. Code and build: repository, branch strategy, tags/releases, dependencies, secret inventory, build and deployment procedure.
2. Infrastructure: environment diagram, cloud accounts, domains, certificates, CI/CD, monitoring, backup, and restore.
3. Data: schemas, migrations, data dictionary, integrations, access controls, and security requirements.
4. Product: approved scope, backlog, acceptance criteria, known limitations, and deferred decisions.
5. Quality: test cases, latest results, defect backlog, production incidents, and untested scope.
6. Architecture: system context, dependencies, architecture decision records, technical debt, and the reasons behind past trade-offs.
7. Operations: runbooks, alerts, past incidents, SLA/OLA, and third-party service contacts.
8. Commercial and legal: ownership, licenses, subcontracts, handover obligations, and data deletion requirements after transition.

Do not ask the new team to “re-estimate everything” from an unverified document folder. Give it a small scope it can build, run, and test first. Then use the new team's observed delivery rate to rebuild the plan.

For web assets, the 22-point acceptance and handover checklist adds checks for domains, hosting, source code, and accounts. A larger software project must extend that checklist for its actual architecture, data, and compliance requirements.

#Three questions for the sponsor's next meeting

1. “Which build proves the current progress, and which parts have not passed their acceptance criteria?”
2. “What mechanism will change over the next two weeks—not only which tasks will be done?”
3. “If we had to transition today, which assets or knowledge would we still not control?”

These questions return the meeting to evidence, mechanisms, and continuity. If the answers become clearer through each validation cycle, the project can still recover. If they remain vague, the sponsor has a stronger basis for increasing the level of intervention.

#Frequently asked questions

#How late should a project be before replacing the vendor?

No number of weeks applies to every project. Put the delay beside business value, the critical path, transition cost, and demonstrated recovery capability. One week on a mandatory regulatory path may be more serious than a month on a module that can be deferred.

#Should we add more people to recover the schedule?

Only if the backlog is separable, the environment and documentation support onboarding, and execution capacity is the actual bottleneck. If the bottleneck is requirements or decision rights, more people only increase the number of waiting flows and coordination cost.

#How can a client without technical staff assess the situation?

Use an independent party who stands with the sponsor to rebuild the baseline, inspect artifacts, and facilitate the decision gate. That party should not simultaneously sell the replacement team during the assessment; otherwise, the recommendation to “replace the vendor” carries an obvious conflict of interest.

I work directly at the intersection of Japanese clients, Vietnamese teams, and system architecture. If your project is late and you need to distinguish governance repair, role replacement, and controlled transition, you can submit the current situation. I will start from the available artifacts and delivery risks, without assuming that replacing the vendor is the answer.