Who owns decisions during an outsourced IT project?

Decision ownership in an outsourced IT project should be divided by decision type, with one clearly identified accountable person for each material choice. The client normally controls business acceptance and organisational risk, while the provider makes technical choices that fall within the agreed design and delivery authority. The important point is to document the boundary rather than rely on assumptions or job titles.

A project governance plan should identify the following roles:

• Executive sponsor: provides organisational direction, resolves issues that exceed the project team’s authority and confirms decisions with significant commercial or operational consequences.
• Business owner: explains the required business outcome, represents affected departments and confirms whether the delivered capability is suitable for operational use.
• Client project lead: coordinates internal stakeholders, gathers approvals and ensures that decisions are made by people with the necessary authority.
• Provider project manager: manages the delivery plan, dependencies, risks, actions and decision log. This role can recommend a course of action but should not approve matters reserved for the client.
• Technical lead or architect: evaluates technical options, designs the solution and directs implementation within the approved scope, standards and constraints.
• Subject matter owners: contribute specialist input for areas such as information security, compliance, networking, applications, data or facilities.

These roles should be recorded in a responsibility matrix or project governance document. A simple RACI model can help, provided it is used carefully: one person should be accountable for the outcome, the people doing the work should be identified, relevant specialists should be consulted, and those who only need updates should be kept informed. Having several people marked as accountable often creates delay because nobody knows whose approval is final.

Technical authority should also have defined limits. An outsourced provider may select a configuration, implementation method or technical component where the choice meets the approved requirements. Escalation is appropriate when a proposed option would alter the agreed scope, introduce material risk, affect regulatory obligations, change the user experience, require additional expenditure or create a dependency for another business system.

Some decisions require joint assessment but a single approval. For example, the provider may explain the technical and security implications of moving a workload, while the client determines whether the resulting operational impact is acceptable. The provider should not treat silence as approval where a decision affects business risk, users, data, contractual commitments or service availability.

Effective projects use a decision register to make ownership visible. Each entry should include:

• the decision required and the date by which it is needed;
• the available options and the provider’s recommendation;
• the technical, financial, security and operational consequences of each option;
• the person authorised to approve it;
• any conditions, dependencies or assumptions attached to the decision;
• the final outcome, approval date and person who authorised it.

This record prevents previously rejected options from being reconsidered without explanation and provides an audit trail when project personnel change. It also separates a decision from an action: approving a design is different from configuring, testing or deploying it.

Decision rights should be agreed during mobilisation, before technical work begins. The project team should confirm who can approve designs, access arrangements, test completion, production deployment, expenditure, scope changes and acceptance of residual risk. Delegates should be named for each role, with clear limits on what they may approve. A delegate can keep work moving, but delegation does not remove the need for an accountable business owner.

When the parties disagree, the issue should be described in terms of evidence rather than personal preference. The provider should set out the impact on cost, timescales, security, maintainability and the intended outcome. The client can then make an informed business decision, or refer the matter to the agreed steering forum if it exceeds the project team’s authority. Escalation should resolve ownership, not transfer responsibility without approval.

For small and medium-sized organisations, this structure need not be bureaucratic. A short governance document, a named client decision-maker, a provider project manager, a technical authority and a maintained decision log may be sufficient. What matters is that every significant decision has a known owner, an appropriate approval route and a written rationale. This gives the outsourced team room to apply its technical expertise while ensuring that the organisation remains in control of choices that affect its operation and risk.