Contractor or project problem?

When development slips, the budget grows, and launch moves again, the first instinct is to find someone to blame. Often that means the contractor. Sometimes that is fair. But if a new team runs into the same problems a few weeks later, the cause may be inside the project itself.

Start with the product, not the blame

Before changing teams, separate delivery problems from product and decision-making problems. A project can look slow even when the team is waiting on scope, approvals, access, or a clear definition of done.

The most useful question is not “Who is at fault?” It is “What is blocking a predictable path to launch?”

If roles, integrations, scenarios, and priorities keep changing, the team is not delivering one stable version. It is repeatedly rebuilding the target.

If a business decision takes a week, the team loses more than a week: context disappears, work is paused, and the next estimate becomes less reliable.

If nobody owns the final product decision, every new stakeholder can redirect the work and the backlog never settles.

Four project problems that look like delivery problems

These patterns are easy to mistake for slow engineering:

• Scope changes while a version is being built
• Business approvals and access arrive late
• No single owner makes final product decisions
• “Done” has no shared definition

In each case, replacing the contractor may change the people but not the conditions. The next team will inherit the same moving target.

The reverse can also be true

A delivery partner may be the real problem when:

Signs the contractor is the blocker

• Project status is vague or impossible to verify
• The same defects keep returning
• Dates move without a clear explanation
• Estimates change after work has started
• Obvious contradictions are implemented literally

Another warning sign is the absence of a path forward. If nobody can explain what blocks launch, what is being done now, and what will happen next, the project is not being managed predictably.

A contractor can also be wrong for the stage of the product. A team optimized for large-scale architecture may overbuild a first release; a team focused only on speed may leave critical stability and security risks.

Three questions before you change teams

Ask what specifically is failing, why it is happening, and what must change so the next team does not repeat it.

The answers should cover scope, decision ownership, access, technical constraints, communication, and the criteria for release. Without that diagnosis, handover is only a reset button.

A short audit can turn a vague feeling into a decision: keep the team and fix the process, change the team, or pause delivery until the project has a workable shape.

Sometimes the right move is to replace the contractor. The important part is knowing which problem the change is meant to solve.

• What is actually blocking launch?
• Is the scope fixed for this stage?
• Who makes the final product decisions?
• What does “done” mean for this release?
• Which risks will the next team inherit?
• What must change before the handover?

The next step

If the product is stuck and it is unclear whether the problem is the team, the code, or the development process, document the situation before making a change.

A better handover decision

Review the current scope, open risks, delivery history, and decision process together. Then choose the smallest intervention that restores predictable progress.

Changing a contractor can be the right answer. It is rarely the first question.

Conclusion

A healthy project makes the cause visible. Diagnose the conditions, define what must change, and choose the team—or the process—that can move the product forward.