Project-Based Outsourcing

Project-Based Outsourcing means giving an external delivery partner responsibility for a defined project or work package.
The engagement normally has a clear objective, boundaries, deliverables, milestones, responsibilities and acceptance criteria.
The provider organizes and manages the delivery needed to produce those outcomes.
The client still remains involved in important business decisions, dependencies and final acceptance.
PMI distinguishes this model from time-and-material staff augmentation, where external consultants are managed directly by the client as part of its internal project team.

The main difference is who owns delivery.
With Staff Augmentation, you add people to your existing team. Your organization normally assigns their work, manages priorities and remains responsible for the final delivery.
With Project-Based Outsourcing, we take responsibility for an agreed project or work package and organize the team required to deliver it.
You manage the business relationship and acceptance. We manage the agreed delivery.

No.
The project needs a clear boundary and definition of success, but not every implementation detail has to be known on day one.
For work with higher uncertainty, the scope can be refined through discovery, iterations or an agreed backlog.
What matters is having a clear process for deciding when a new requirement changes the agreed project boundary.
A good change process identifies the effect on scope, cost, timeline and risk before the change becomes an informal commitment. This is why change control is a standard part of a strong outsourcing SOW.

No.
The commercial model depends on how predictable the work is.
A well-understood work package may fit a fixed or milestone-based price. Work with greater technical uncertainty may be better delivered through capped time and materials, staged discovery or another model.
The important distinction is not the billing method.
It is whether the provider owns a defined delivery outcome rather than simply supplying people.

At minimum, both sides should understand the project objective, scope boundary, major deliverables, acceptance criteria, dependencies, responsibilities and change process.
Client-side dependencies matter as well.
Access to environments, test data, business experts, security approvals or third-party systems can determine whether the supplier can deliver on schedule.
Current practical outsourcing guidance emphasizes making these dependencies explicit rather than treating every delay as a supplier delivery problem.

Acceptance criteria describe the evidence required to consider a deliverable complete.
Depending on the project, this can include functional tests, performance targets, security checks, documentation, deployment results, data reconciliation or operational readiness.
The criteria should be objective enough that both parties can reach the same conclusion about whether the requirement has been met.
PMI specifically recommends measurable quality criteria because they reduce disagreement during final acceptance and give the delivery team a clear definition of completion.

Handover is part of the project rather than an activity left for the final week.
Depending on the engagement, this can include architecture documentation, repositories, Infrastructure as Code, runbooks, deployment procedures, operational knowledge, training and open-risk information.
Where the client team will operate the solution, we involve them early enough for knowledge transfer to happen before final acceptance.
For larger programs, continued delivery can also move into a Managed Delivery Team or Delivery Leadership & Governance model if ongoing responsibility is required.

The strongest fit is technology work close to our core engineering capabilities, for example cloud infrastructure, platform engineering, DevOps and CI/CD improvements, Kubernetes platforms, workload migration, legacy modernization or architecture-led implementation.
We do not position Project-Based Outsourcing as “we can build anything.”
The project should fit the expertise we can credibly lead and have boundaries that allow delivery responsibility to be defined.
That approach also fits the wider Nubes operating model: named experts, bounded work packages and explicit acceptance criteria are preferred over anonymous capacity and open-ended resource supply.