Design and transition, and obtain/build

Once engage has understood what stakeholders need and plan has decided what to do, someone has to create or change the products and services that will meet those needs. Two value chain activities share that work. Design and transition makes sure products and services keep meeting stakeholder expectations for quality, cost and time to market. Obtain/build makes sure the components those products and services depend on are available when and where needed and meet agreed specifications. This lesson examines both activities, how they divide responsibilities, and how they work with partners, suppliers and the rest of the chain.

The purpose of design and transition

In plain terms, design and transition ensures that products and services continually meet stakeholder expectations for quality, costs and time to market. The activity covers designing new or changed products and services, planning how they will be introduced, testing that they meet requirements and moving them into live use. The word continually matters: design and transition is not only about new services but about every change to existing ones throughout their lives.

Design and transition balances three expectations that often pull against each other. Stakeholders want high quality, low cost and fast delivery. Faster delivery may mean less testing; lower cost may mean fewer features; higher quality may take longer. Design and transition makes those trade-offs explicit and agrees them with stakeholders through engage.

Inputs and outputs of design and transition

Design and transition receives product and service requirements from engage, portfolio decisions and architectures from plan, service components from obtain/build, knowledge and information about third-party components from suppliers through engage, and performance information and improvement initiatives from deliver and support and improve. Its outputs include requirements and specifications for obtain/build, contract and agreement requirements for engage, new and changed products and services for deliver and support, knowledge and information about them for all activities, and performance information for improve.

Designing for value

Good design starts from the outcomes stakeholders need, not from the technology available. It considers all four dimensions: the people who will run and use the service, the information and technology involved, the partners and suppliers who contribute, and the value streams and processes through which it will be delivered and supported. A design that neglects operational support, for example, may look elegant on paper but generate a stream of incidents once live.

Design also considers experience. ITIL-110 showed that user journeys and touchpoints shape perceived value. Service design practice includes mapping how users will discover, request, use and get help with a service, and removing friction at each touchpoint.

Transition: moving into live use

Transition is the part of the activity that moves a new or changed product or service into live use safely. It includes planning the release, testing, preparing support staff and users, deploying, and confirming that the change works as intended. Practices that contribute include change enablement, release management, deployment management, service validation and testing, and knowledge management. ITIL-140 and ITIL-141 cover these practices; here the focus is on the activity.

Transition risk is reduced by small, frequent changes rather than large, infrequent ones. A large release bundles many changes, so a failure is harder to diagnose and roll back. Many organizations now deploy small changes continuously through automated pipelines, with automated testing and the ability to roll back quickly. Design and transition still exists in those organizations; it is simply performed many times a day in small increments.

Time to market

Time to market is the elapsed time from a decision to create or change something until it is available to consumers. Design and transition directly affects it. Long approval chains, manual testing and large release batches all lengthen time to market. Value stream mapping, covered in lesson 8, often reveals that most of the elapsed time is waiting rather than design or testing work.

The purpose of obtain/build

In plain terms, obtain/build ensures that service components are available when and where they are needed and meet agreed specifications. Components can be obtained from suppliers or built in-house, and most services combine both. A cloud-hosted customer portal might include software developed internally, a commercial content management system licensed from a vendor, infrastructure rented from a cloud provider and a payment service from a fintech partner.

Obtain/build covers many kinds of components: software, hardware, cloud services, data, documentation, trained staff and even supplier services. The activity includes acquiring, developing, configuring and integrating them, and verifying that they meet their specifications before they are handed to design and transition or to deliver and support.

Inputs and outputs of obtain/build

Obtain/build receives architectures and policies from plan, contract and agreement requirements from engage, goods and services from external suppliers and partners, requirements and specifications from design and transition, change requests and improvement initiatives from deliver and support and improve, and knowledge and information about new and changed products. Its outputs include service components for deliver and support and for design and transition, contract and agreement requirements for engage, knowledge and information about components, and performance information for improve.

Make or buy

A central decision in obtain/build is whether to make a component internally or obtain it from a supplier. The decision considers cost, speed, control, risk, available skills and strategic importance. Commodity components (email, storage, standard office software) are usually bought. Components that differentiate the organization or embody unique knowledge are more often built.

Verifying components

Components must meet agreed specifications before they are used. Verification can include functional testing, security assessment, performance testing and checks against contracts (for example, that a supplier's data centre is in an approved location). Catching a problem in obtain/build is far cheaper than discovering it after a service is live.

Working together

Design and transition and obtain/build work in a tight loop. Design produces specifications; obtain/build supplies components; design integrates and tests them; obtain/build fixes or replaces components that fail; transition moves the result into live use. In many organizations, the same product or platform team performs both activities. In others, obtain/build is largely performed by suppliers, with the organization retaining design and integration responsibilities. Either way, the activities need clear inputs and outputs so nothing falls between them.

In Canadian federal procurement, obtain/build often runs through Public Services and Procurement Canada, and departments buying cloud services must follow Government of Canada guidance on data residency and security assessments by the Canadian Centre for Cyber Security. These requirements become part of the specifications that obtain/build must verify.

Lifecycle view in ITIL (Version 5)

The lifecycle activities reported for Version 5 divide this territory more finely: design and transition appear as separate activities, and acquire and build appear separately, matching the two halves of obtain/build. The underlying ideas (specify, obtain or build, verify, integrate and move into live use) are the same. Learners studying Version 5 should use its activity names in exam answers.

Quality gates and acceptance criteria

Design and transition and obtain/build both depend on clear acceptance criteria: statements of what must be true before a component or service moves to the next step. Criteria might include passing automated tests, completing a security review, producing support documentation and confirming that the service desk has been trained. When criteria are agreed in advance, handoffs become checks against a shared standard rather than arguments about whether something is ready.

Acceptance criteria also protect deliver and support. A service that meets its criteria arrives with the knowledge, monitoring and procedures needed to run it, which reduces the incidents that follow many launches.