openskills.info
Course Preview

Sourcing and Outsourcing Strategy

Sourcing and outsourcing strategy decides which technology capabilities stay inside an organization, which come from suppliers, and how those choices are governed. It compares delivery models by value, risk, control, capability, and whole-life cost rather than purchase price alone.

itFinOps, procurement, and technology economics

Don't Panic — Sourcing and Outsourcing Strategy

Sourcing strategy decides how a technology capability should be delivered. Internal team, cloud product, managed service, external specialists, or a mixture: all are candidates. Outsourcing is therefore an answer, not a ceremonial button marked “make this someone else's problem.” The accountability, regrettably but usefully, stays put.

The first load-bearing idea is the service boundary: the outcomes, users, data, interfaces, assets, and responsibilities included in the decision. Draw it before comparing providers. Anything vague at this stage does not vanish. It waits patiently and returns as a change request, an unowned handoff, or a meeting with an alarming number of people from Legal.

The second idea is whole-life cost. Internal payroll and a supplier bid are not comparable totals. Add transition, integration, retained governance, change, risk exposure, and exit. Then apply the same demand cases and time horizon to every model. Numbers become useful when their assumptions are visible; extra decimal places are merely assumptions wearing formal shoes.

The third idea is risk allocation. Give a risk to the party that can prevent it, detect it, and reduce its impact. A contract can assign uncontrollable risk to a provider, but physics remains unimpressed. The risk usually returns as a premium, defensive behavior, underperformance, or dispute.

A weighted scorecard helps organize judgment. Mandatory legal, security, residency, and continuity requirements belong outside it as pass-or-fail gates. Test the result by changing uncertain weights and demand assumptions. If a small change selects a different winner, the recommendation is fragile. A pilot or staged commitment is more honest than declaring victory by spreadsheet.

After selection comes transition, where calendars develop an unfortunate reputation for impersonating evidence. Accept the new model when data reconciles, access works, recovery is tested, operators are ready, and critical defects are closed. The handover date proves only that time has passed.

Then govern the relationship. Measure the end-to-end service, not only each component. Monitor supplier health, security, subcontractors, cost, and dependency after award. Keep a retained organization, meaning the customer-side people who still own architecture, assurance, service outcomes, and supplier judgment. Without it, reports can be accepted but not challenged.

Finally, design exit while cooperation is abundant. Specify usable data, documentation, knowledge transfer, access removal, transition help, charges, and acceptance tests. Exercise those provisions during the term. An exit plan first opened at renewal is less a plan than an archaeological discovery.

Read the Intro for the complete operating model. Use the Cheatsheet and Practice Reference to construct a decision record. The Exercise tests whether another reviewer can reproduce it. Field Notes covers the costs that tidy sourcing diagrams prefer not to mention.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources