Build
Stage 4 in the Lifecycle
Build transforms approved designs and available resources into working, tested digital products and their associated service capabilities.
What you should take away
- State the official purpose of build
- Distinguish validation from testing per the official definition
- List the four steps of the build workflow
- Explain why multi-disciplinary product teams outperform pure project handoffs
Official purpose
The purpose of build is to develop, integrate, and test digital products, converting designs into functional solutions.
Digital products combine resources based on digital technology. After resources are secured, organizations execute the build phase. Depending on architecture, build can encompass software development, integration, infrastructure and platform configuration, process design, and supporting documentation for transition, operation, delivery, and support phases. Build includes validation and testing of components and integrated products.
Validation ensures the proposed design meets agreed requirements and establishes acceptance criteria for the subsequent lifecycle stage. Testing executes a system or component under specified conditions, documents results, and evaluates performance. Comprehensive testing guidance appears in the Service Validation and Testing (Version 5) Official Practice Guide.
Build may also create or test service delivery capabilities (teams, roles, instructions), making organizational change part of this phase.
When design completes an iteration, the product team assesses the design and plans build and test activities and resource needs. Missing resources trigger requests to Acquire. Once resources are confirmed, build and test proceed as planned; outputs advance to Transition (live environment, marketplace, or consumer).
Key facts
| Question | Answer |
|---|---|
| Why do we do it? | To develop, integrate, and test digital products, transforming designs into functional solutions. |
| Who does it? | Product teams or specialized software development, infrastructure engineering, and testing teams or project teams formed of the above. |
| When is it performed? | As frequently as needed, triggered by solution designs (subject to resource availability). |
| What are the key outputs? | Built and tested product and service solutions. |
| What are the key metrics of success? | Quality of the product solutions. Building cycle. Adherence to the product roadmap and other relevant guidelines. Stakeholder satisfaction with the product solutions. |
High-level workflow (four steps)
Assess solution design
Plan building and testing; confirm resource availability
Execute building and testing plans
Deliver solutions and supporting documentation to transition
Automation and continuous integration
Build should be highly automated. Continuous integration merges code changes frequently into a central repository with automated builds and tests, identifying integration issues early.
Team shape (book recommendation)
Specialized dev or infrastructure-only teams can extend cycles and obscure ownership. The book advocates for multi-disciplinary product teams maintaining continual ownership. Project structures may assist short-term efforts but cannot substitute for ongoing product ownership.
Extended build topics
Development and integration
- Agile, DevOps, or hybrid delivery
- Configuration, APIs, data integration
- CI/CD pipelines
Testing types (common labels)
- Unit, integration, system, UAT, performance, security, regression
AI in build (ITIL v5 angle)
- AI-assisted development and testing
- Quality automation
- Building products that embed AI
Related management practices
| Practice | Role in Build |
|---|---|
| Software Development and Management | Engineering discipline |
| Service Validation and Testing | Test and validate |
| Service Configuration Management | Configuration control |
| Information Security Management | Secure development |
| Infrastructure and Platform Management | Dev and test platforms |
Inputs and outputs
Inputs: design packages, acquired components, standards, test plans
Outputs: built and tested product, test evidence, release packages, runbooks, updated configuration data
Metrics (examples)
- Build lead time
- Defect density
- Test coverage
- Build success rate
- Time to fix defects
ITIL Car Rental scenario: Build in action
Context: With critical resources secured (AI platforms, supplier partnerships), the team entered the Build phase, where design becomes tangible.
Sam (Head of Product Development): "Since the partner is developing their solution for broad integration, they are using an open architecture and a standard API. To create the integration, we needed minimal consultation; our team developed the solution independently."
Anna (Product Manager): "With the solution design approved and the supplier of our driverless vehicles onboarded, we will now enter the building and testing phase. This includes developing mobile app interfaces, integrating AI services, and preparing operational documentation."
Maria (Business Analyst): "I have confirmed resource requirements as stated in our build plan. What we have for now is sufficient for this stage."
Max (CIO): "Testing has been completed. Using standard interfaces allows for seamless updates without interruption of service."
Omar (IT Delivery Manager): "While testing our app in the internal environment, we encountered several issues. After a trip is planned and the price confirmed, any changes (such as those caused by traffic or alternative routes) are currently affecting the price. With driverless cars, route selection is fully managed by us and we are responsible for providing an optimal route at the agreed price. Any route changes not initiated by the customer should not impact the journey's cost. We must return to the Design stage to revise the price calculation rules and then test again."
This scenario demonstrates a critical aspect of iterative lifecycle management: the Build phase uncovered a design flaw in pricing logic, requiring the team to loop back to Design before proceeding. This exemplifies how the "stepping stones" model functions -- lifecycle activities are not always sequential.