ISO/IEC/IEEE 24748-1: ISO/IEC/IEEE 24748-1 – Tutorial (about 60 minutes)

ISO/IEC/IEEE 24748-1 is the international guidance document that explains how to think about, describe and manage the life of a system or a piece of software, from the first idea to the day it is switched off and disposed of. Systems and software engineers, project and programme managers, acquirers, suppliers and process owners use it to build sensible life cycle models: the stages, decision gates and development approaches a project follows while it applies the processes of ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 12207. After this tutorial you will be able to explain what the guidance covers, use its vocabulary correctly, sketch and adapt a life cycle model for a real project, and explain how it relates to the process standards and to assessment.

Free tutorial · about 60 minutes · 7 lessons · 4 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: the current edition is ISO/IEC/IEEE 24748-1:2024, Systems and software engineering – Life cycle management – Part 1: Guidelines for life cycle management. It was prepared jointly by ISO/IEC JTC 1/SC 7 (Software and systems engineering) and the IEEE Computer Society's Software and Systems Engineering Standards Committee, through its Working Group for Life Cycle Processes. The IEEE SA Standards Board approved it on 2024-02-15 and IEEE published it on 2024-03-22 as IEEE/ISO/IEC 24748-1-2024, listed as an active standard. National catalogues list the ISO document as edition 2, dated 2024-03, valid, and replacing ISO/IEC/IEEE 24748-1:2018, which IEEE now marks as superseded. The 2018 edition itself grew out of an ISO/IEC Technical Report published in 2010. We found no newer edition or announced revision of Part 1; the newer documents in the series are other parts (for example Part 4 on systems engineering management planning, 2025, and Part 10 on systems engineering agility, IEEE 24748-10-2025, published in early 2026). Note that the 2024 guidance was written alongside ISO/IEC/IEEE 15288:2023 and the 2017 edition of 12207; 12207 was revised again in 2026, so small differences in process wording are possible. Verified 2026-10-29 against the IEEE SA records for the 2018 and 2024 editions and the Swedish Institute for Standards (SIS) catalogue entry. The full text could not be read for this course, so clause numbers are deliberately not quoted; check the structure in the copy you hold.

Who it is for: engineers moving into systems engineering, technical leads and architects, project and programme managers on technical projects, people who buy or supply engineered systems and software, quality and process improvement staff, and anyone who works in an organisation that says "our life cycle is based on 15288 and 12207" and wants to understand the guidance that sits behind that claim.

Prerequisites: none. Some exposure to a project that delivers a product or a service helps, but every term is explained when it first appears. If you have taken our ISO/IEC/IEEE 15288 or 12207 courses you will recognise some vocabulary; this course focuses on the life cycle management view rather than on the individual processes.

How to use this tutorial: read the seven lessons in order (about 45 minutes), study the four diagrams, then use the remaining time on the reflection questions before you take the 25-question knowledge check.

Learning objectives:

You will be able to explain why ISO/IEC/IEEE 24748-1 exists, what kind of document it is and how it differs from the process standards it supports.
You will be able to define the core vocabulary: system of interest, enabling system, life cycle, life cycle model, stage, decision gate, process, outcome, development approach and adaptation.
You will be able to describe the generic set of life cycle stages, what each is for and how decision gates control movement between them.
You will be able to explain why processes are not stages and how processes are applied iteratively, recursively and concurrently.
You will be able to select a development approach and adapt a life cycle model for a project, recording the reasons.
You will be able to explain how organisations show that they follow the guidance, given that there is no certification against it.
You will be able to place Part 1 within the 24748 series and relate it to 15288, 12207, process assessment and quality management.

Lesson 1 – Origins, purpose and scope

The problem it solves

Every engineered thing has a life. A ticket machine, a hospital information system, a satellite or a mobile banking app is imagined, specified, designed, built, checked, delivered, used, repaired, upgraded and finally retired. Over that life, many organisations and people are involved, and they all need to answer the same practical questions. Where are we in the life of this system? What must be true before we move on? Who decides? What work happens now, and what work comes later? What happens when the system has to be changed after it is already in service?

The international process standards ISO/IEC/IEEE 15288 (for systems) and ISO/IEC/IEEE 12207 (for software) give a catalogue of processes, such as requirements definition, architecture definition, verification, risk management and configuration management. They are deliberately silent on how you should arrange those processes in time. They do not say "do requirements first, then design". That silence is intentional, because a pacemaker, an online shop and a rail signalling upgrade need very different arrangements. But it leaves a gap: practitioners still need help with turning a list of processes into a sensible plan for the whole life of a system.

ISO/IEC/IEEE 24748-1 fills that gap. It is guidance, not a set of requirements. It explains the concepts behind life cycles, describes a generic set of stages and decision gates, explains how processes are used within and across stages, and discusses how to adapt a life cycle model and its content to a particular organisation, project or domain. Its stated aim is to help people use the systems and software process standards together.

A short history

The life cycle ideas in this guidance have been around for decades. Early editions of 15288 contained explanatory material about stages and their purposes. As 15288 and 12207 were being harmonised, that explanatory material was separated into its own document: first an ISO/IEC Technical Report in 2010, then a full joint ISO/IEC/IEEE International Standard in 2018, and now the 2024 edition. The 2024 edition followed the 2023 revision of 15288 and is cited alongside it by the Systems Engineering Body of Knowledge (SEBoK). According to its published abstract, it complements 15288 and 12207, covers life cycle concepts, models, stages and processes and their adaptation, and describes how life cycle concepts relate to more detailed process standards on topics such as measurement, project management and risk management.

What is in scope and what is not

In scope: concepts of systems and life cycles; life cycle models and stages; how life cycle processes are applied, combined and adapted across stages, domains and disciplines; a common way of describing a life cycle for projects that provide or acquire products or services.
Not in scope: a single mandatory life cycle; detailed instructions for any engineering discipline; a certification scheme; specific methods or tools. It does not tell you to use agile, waterfall or any other named method; it helps you reason about which arrangement fits.

A useful mental model: 15288 and 12207 tell you what kinds of work exist and what each must achieve; 24748-1 helps you decide when and how to arrange that work over the life of the system; the other parts of the 24748 series and the more detailed standards tell you how to do particular parts well.

Figure 1 – Part 1 sits between the life cycle process standards and the more specific guidance parts and detailed process standards.

Why a beginner should care

Many organisations quote 15288 or 12207 in contracts and quality manuals but struggle to explain how their gate reviews, release trains, increments and maintenance releases fit together. The concepts in 24748-1 give you the words to do that clearly. They also help you spot common failures, such as projects that plan only up to first delivery and forget support and retirement, or teams that confuse a document-heavy "phase" with the engineering work that actually needs to happen.

Lesson 2 – Key concepts and vocabulary

The 24748 series shares its vocabulary with 15288, 12207 and the systems and software engineering vocabulary ISO/IEC/IEEE 24765. The definitions below are paraphrased in plain English.

System – a combination of interacting elements organised to achieve one or more stated purposes. Elements can be hardware, software, data, people, processes, procedures, facilities, materials or naturally occurring entities.
System of interest – the particular system whose life cycle you are currently considering. Naming it clearly avoids confusion about which level of a larger system a plan or decision applies to.
System element – a member of the set of parts that make up a system. An element can itself be treated as a system of interest one level down.
Enabling system – a system that supports the system of interest during its life but is not part of it while it operates, for example a test facility, a production line, a build pipeline or a training simulator. Enabling systems have life cycles of their own.
Stakeholder – an individual or organisation with a right, share, claim or interest in the system, such as users, operators, acquirers, regulators, maintainers or the public.
Life cycle – the evolution of a system, product, service, project or other human-made entity from conception through retirement.
Life cycle model – a framework of processes and activities concerned with the life cycle, organised into stages, which also serves as a common reference for communication and understanding among the parties involved.
Stage – a period within the life cycle that relates to the state of the system's description or realisation, such as concept, development or utilisation. Each stage has a purpose and expected outcomes.
Decision gate – a point, usually at the end of a stage or at a significant milestone, where the responsible stakeholders review the evidence and decide what happens next.
Process – a set of interrelated or interacting activities that transforms inputs into outputs. In 15288 and 12207, each process is described by a purpose, outcomes and activities broken down into tasks.
Outcome – an observable result of performing a process successfully, for example "a baseline of requirements is established".
Development approach – the overall strategy for how a system is defined and realised over time: for example sequential (once-through), incremental or evolutionary. Agile and lean ways of working are often described as particular forms of these.
Adaptation (tailoring) – deliberately adjusting a life cycle model, its stages, gates, criteria or processes to fit the circumstances of an organisation or project, and recording why.
Iteration, recursion and concurrency – three ways processes are applied: repeated on the same item (iteration), applied again at successive levels of the system structure (recursion), or performed at the same time as other processes (concurrency).
Life cycle concepts – early, agreed descriptions of how the system will be acquired, deployed, operated, supported and retired, such as an operational concept or a support concept. They let later stages be planned from the start.

Three ideas that hold the vocabulary together

Systems are nested. A railway is a system; a train is a system element of the railway but also a system of interest in its own right; the train's braking unit is an element of the train. The same life cycle thinking applies at every level, which is why the guidance talks about recursion. A supplier building the braking unit has its own life cycle model, and its gates must line up with the train maker's gates.

Enabling systems matter. A system cannot be developed, produced, supported or retired without other systems: tools, test benches, factories, training, spare parts logistics, hosting platforms. Their availability is often what drives the schedule. A life cycle model that ignores them will look fine on paper and fail in practice.

Stages describe the system; processes describe the work. A stage answers "what state is the system in?" A process answers "what kind of work are we doing?" Most of the confusion in practice comes from mixing these up, which Lesson 4 explores in detail.

Lesson 3 – Structure of the guidance

Because the document is copyrighted and was not available in full for this course, this lesson describes the content areas reflected in its published scope and in reputable secondary sources, not its exact clause layout. Expect the usual front matter of an ISO/IEC/IEEE document (scope, normative references, terms and definitions, conformance or applicability notes) followed by the guidance itself and supporting annexes.

Content area 1 – System concepts

The guidance starts by explaining what a system is in this context, how systems are composed of elements, how a system of interest relates to its enabling systems and to the systems it interfaces with, and how the same ideas apply to software, services and organisations. It stresses that "system" is a viewpoint: the same thing can be a system of interest for one team and an element for another.

Content area 2 – Life cycle concepts and models

This part explains what a life cycle is, why it is broken into stages, and what a life cycle model does: it gives the parties a shared reference, it provides points where progress and risk are reviewed, and it frames the planning of work and resources. It explains that a system can be in more than one stage at once (for example, version 1 in utilisation while version 2 is in development), and that models differ in how much iteration and overlap they allow.

Content area 3 – Life cycle stages

The guidance describes a generic set of stages that is widely used across industries. Paraphrased:

Stage	Main purpose	Typical evidence at the end
Concept	Understand the problem or opportunity and stakeholders' needs, explore possible solution concepts, judge feasibility and propose a viable way forward	Agreed needs, preferred concept, life cycle concepts, early cost and risk estimate
Development	Refine requirements, define the architecture and design, build or acquire elements, integrate, verify and validate	A verified and validated system ready for production or deployment, with its baselines
Production	Produce the system (once or many times), inspect and test each item, keep production consistent	Produced items that conform to the baseline
Utilisation	Operate the system in its intended environment to deliver value to users	Service delivered; performance and feedback data
Support	Keep the system capable: maintenance, logistics, problem fixing, minor upgrades	Sustained capability; records of changes and failures
Retirement	Withdraw the system from service and store, archive, recycle or dispose of it safely	System removed; data archived; obligations closed

Utilisation and support normally run in parallel: while users depend on the system, it is being maintained. For software, the production stage is usually small (making a copy of a release is cheap), while for hardware it can dominate cost.

Content area 4 – Using the processes within the life cycle

The guidance shows how the four process groups of 15288 and 12207 (agreement, organisational project-enabling, technical management and technical processes) are drawn on throughout the stages. It explains iteration, recursion and concurrency, and it relates the life cycle view to more detailed standards on topics such as project management, risk management and measurement.

Content area 5 – Adapting the life cycle and its content

Finally, the guidance discusses how to adapt a life cycle model, its stages, gates and processes to the organisation, the domain and the project, including choosing development approaches. Because a system can contain hardware, software, people, services and facilities, the same concepts have to work for each kind of element.

When you read the real document, map what you find to these five areas. If your organisation's quality manual claims alignment with 24748-1, these are the areas an informed reviewer would expect to see reflected.

Lesson 4 – How it works in practice

Stages and decision gates

A stage ends with a decision, not with a calendar date. At a decision gate, the people accountable for the investment (often the acquirer, the sponsor and the lead engineer, sometimes a regulator) look backwards at the evidence of progress and forwards at readiness to continue. Secondary sources describing the 24748-1 model list a small set of possible outcomes of a gate decision: begin the next stage (or several stages), continue the current stage, go back to or restart another stage, pause the activity, or terminate. Notice that "continue" and "go back" are perfectly legitimate outcomes: a gate is not a rubber stamp.

Figure 2 – A generic life cycle: stages separated by decision gates, with paths to continue, go back, upgrade, stop or retire.

Gate criteria should be proportionate. SEBoK, describing the 2024 model, notes that entry and exit criteria may be met before the decision, concurrently with it, after it, or not at all; a criterion left unmet should be a conscious decision with the risk accepted. What matters is that the decision is explicit, recorded and based on evidence. A healthy gate review also considers technical debt: shortcuts taken now that will cost effort later.

Processes are not stages

A frequent beginner mistake is to assume each process belongs to one stage: "requirements happen in concept, testing happens in development". In reality, nearly every process is used in nearly every stage, at different intensity. During the concept stage you already manage risk, make decisions, define stakeholder needs, sketch an architecture and think about verification. During utilisation you still manage configuration, measure performance, handle change requests (which trigger fresh requirements and design work) and verify fixes. The guidance makes this point strongly, and it explains three patterns of use:

Iteration – repeating a process on the same item to improve it, for example refining requirements as prototypes reveal problems.
Recursion – applying the same process again at the next level of the system structure, for example defining requirements for the whole aircraft, then for the avionics, then for each avionics unit.
Concurrency – performing several processes at the same time, for example architecture work proceeding alongside risk analysis and early verification planning.

Figure 3 – All four process groups are drawn on throughout the stages, through iteration, recursion and concurrency; the stage defines the situation, the processes define the work.

Choosing a development approach

The development approach shapes how concept and development unfold. Secondary sources group approaches roughly into three families:

Sequential (once-through) – needs are understood early, the whole system is defined, built and delivered once. Fits stable, well-understood requirements, high-cost hardware, or strong regulatory constraints on changing a baseline.
Incremental – needs are mostly understood up front, but the system is built and often delivered in increments. Fits situations where early partial capability is valuable or where funding arrives in tranches.
Evolutionary – needs are not fully known; each version is used to learn what the next should be. Fits novel products, uncertain markets and research-heavy work. Agile methods are often a form of evolutionary or incremental development with short cycles.

All approaches are iterative and concurrent to some degree; the difference is how much is fixed early and how increments are used. One system can mix approaches: a hardware chassis may follow a sequential path while its software evolves in short increments, as long as the two are synchronised at agreed points.

Life cycle concepts: planning the whole life early

A strong theme of 15288:2023, which this guidance accompanies, is to describe, early in the concept stage, how the system will be acquired, deployed, operated, supported and retired. These life cycle concepts are short, agreed descriptions, not huge documents. They prevent the classic surprise where a system is built successfully but cannot be installed, maintained economically or disposed of legally.

Roles and artefacts

The guidance does not prescribe job titles, but in practice life cycle management involves: an acquirer who funds and accepts; a supplier who delivers; a decision authority at each gate; a technical lead or chief engineer who owns the integrity of the system; process owners in the organisation who maintain the standard life cycle models; and the project manager who plans the work. Typical artefacts include the organisation's library of life cycle models, the project's chosen and adapted model, a systems engineering management plan or software development plan (see Parts 4 and 5 of the series), gate criteria and gate records, baselines, and the documented rationale for any adaptation. ISO/IEC/IEEE 15289 helps define the content of these information items.

Lesson 5 – Assessment, certification and compliance

There is no certificate for 24748-1

ISO/IEC/IEEE 24748-1 is a guidelines document. It helps you apply other standards; it does not set out a list of auditable requirements for an organisation. There is no accredited certification scheme in which a third party issues an "ISO/IEC/IEEE 24748-1 certificate" to a company, and there is no official individual certification for it either. Be cautious with any offer claiming otherwise.

So how do organisations show they follow it?

Evidence of good life cycle management usually reaches outsiders through other routes:

Conformance to 15288 or 12207. These process standards do define how an organisation or project can claim conformance, either fully or in a tailored form with documented justification. A well-reasoned life cycle model built using 24748-1 is strong supporting evidence for such a claim.
Process assessment. The ISO/IEC 330xx family defines how to assess process capability. Process assessment models for system and software life cycle processes (ISO/IEC TS 33060 and TS 33061) are built on 15288 and 12207. Assessors look at whether processes achieve their outcomes, not at whether a document quotes 24748-1.
Domain frameworks. Models such as Automotive SPICE or CMMI and domain safety standards examine life cycle planning, gates and change control in their own terms.
Quality management audits. An ISO 9001 certification audit checks planning, design and development controls and change management; a documented life cycle model with gate records helps demonstrate these.
Customer and contract reviews. Acquirers frequently require technical reviews at defined milestones; for defence programmes, 24748-8 describes technical reviews and audits.

What a reviewer would look for

If someone examined whether your organisation really manages life cycles in the spirit of 24748-1, they would typically ask:

Does the organisation maintain defined life cycle models, with guidance on when to use each?
Does each project select a model and development approach, adapt it, and record the reasons?
Are gates defined with criteria, decision authorities and recorded decisions, including decisions to continue, go back or stop?
Does planning cover utilisation, support and retirement, not only development?
Are enabling systems identified and planned?
Are lessons learned fed back to improve the organisation's models?

Professional credentials

Individuals who want recognition in this area usually pursue broader systems engineering credentials. For example, INCOSE's professional certification programme is based on its systems engineering handbook, which is aligned with 15288. That is not a 24748-1 certification, but the life cycle concepts in this course are part of the body of knowledge it covers.

Lesson 6 – Worked example

The situation

MeterWave is a fictional company of 180 people that makes smart water meters for municipal utilities. Its new product, the MW-5, combines a sealed meter body with a radio module (hardware), embedded firmware, a cloud platform that collects readings and raises leak alerts, a mobile app for installers, and a field service operation. A city utility has signed a contract to buy 120,000 units with a 12-year service agreement. MeterWave's quality manual says its processes are based on 15288 and 12207, and its head of engineering asks a systems engineer, Lina, to define a life cycle model for MW-5 using 24748-1 as guidance.

Step 1 – Name the system of interest and its context

Lina writes one page that names the system of interest: "MW-5 metering service", meaning meters, firmware, cloud platform, installer app and the field service procedures. She lists the system elements and the enabling systems: the meter production line, the end-of-line test station, the firmware build and over-the-air update pipeline, the installer training course and the spare parts warehouse. She also lists interfacing systems that MeterWave does not control: the utility's billing system and the public radio network. This immediately reveals that the production test station and the update pipeline need their own plans; both are on the critical path.

Step 2 – Agree life cycle concepts early

In the concept stage, Lina and the utility agree short life cycle concepts: an acquisition concept (pilot of 2,000 units, then four rollout waves), an operational concept (readings every hour, leak alerts within 30 minutes), a support concept (remote firmware updates, battery replacement only at year 10), and a retirement concept (meters returned for battery recycling, customer data deleted at contract end under an agreed procedure). These are each two or three pages long. The retirement concept leads to a design requirement that batteries be removable without destroying the meter body, which would have been very expensive to discover later.

Step 3 – Choose development approaches

Lina does not force one approach on everything. The meter body and radio hardware follow a sequential approach, because tooling for injection moulding and radio certification make late changes costly. The cloud platform and installer app follow an evolutionary approach with two-week increments, because the utility's operators will only know which dashboards and alerts they really need once they see real data. The firmware follows an incremental approach: a certified core for metering accuracy is fixed early, while optional features arrive in later increments by over-the-air updates.

Step 4 – Define stages, gates and criteria

Lina adapts the generic stages. She keeps concept, development, production, utilisation, support and retirement, but splits development into a pilot sub-stage and a full-rate sub-stage, and inserts a pilot gate. Each gate has a short list of criteria, a named decision authority (MeterWave's product board for internal gates; a joint board with the utility for the pilot gate and the rollout gate) and a record template that captures the decision and its conditions.

Figure 4 – MeterWave's adapted life cycle model: a pilot sub-stage, a joint pilot gate, repeating rollout gates and planned retirement.

Step 5 – Use the gates honestly

At the joint pilot gate, the evidence shows that meters meet accuracy requirements but radio coverage in basements is poor in 8 % of locations. The board does not simply approve or reject. It decides to begin full-rate production for the meter body (whose tooling is unaffected), continue the pilot for the radio module with a revised antenna, and attach a condition: the antenna fix must be verified before the second rollout wave. The decision and its conditions are recorded. This is exactly the kind of nuanced gate decision the guidance encourages.

Step 6 – Apply processes across stages

During utilisation, a leak-alert false-positive problem appears. MeterWave runs the usual chain: problem report, impact analysis, a change to the stakeholder requirement for alert sensitivity, firmware and cloud changes, verification on a test bench, a staged rollout via the update pipeline and validation with the utility's operators. These are technical and technical management processes being used again inside the utilisation and support stages, which shows in practice that processes are not stages.

Step 7 – Record adaptation and improve the model

Lina keeps an adaptation record listing each change to the organisation's standard life cycle model (the pilot sub-stage, the joint gates, the mixed development approaches), the reason, and who approved it. When an external assessor later reviews MeterWave against a process assessment model based on 15288, this record helps show that the tailoring was deliberate. After the third wave, MeterWave adds "joint pilot gate for utility contracts" to its library of life cycle models, so the next project starts from an improved template.

What the example teaches

Naming the system of interest and enabling systems surfaces hidden critical paths.
Early life cycle concepts protect later stages from expensive surprises.
Different elements can follow different development approaches if they synchronise at gates.
Gate decisions are richer than yes or no, and must be recorded.
Adaptation is normal; undocumented adaptation is the problem.

Lesson 7 – Relationship to other standards and frameworks

Part 1 is the conceptual entry point to a family of documents. Use the table to see where each neighbour fits.

Standard or framework	What it provides	Relationship to 24748-1
ISO/IEC/IEEE 15288 (system life cycle processes)	Normative set of processes for systems, with conformance options	24748-1 explains how to arrange and adapt these processes in a life cycle
ISO/IEC/IEEE 12207 (software life cycle processes)	Normative set of processes for software, aligned with 15288	24748-1 applies the same stage and model concepts to software
ISO/IEC/IEEE 24748-2 and 24748-3	Guidelines for applying 15288 and 12207 respectively	Process-by-process advice that builds on the concepts in Part 1
ISO/IEC/IEEE 24748-4 and 24748-5	Content and use of systems engineering management plans and software development plans	Where the chosen life cycle model is written down and resourced
ISO/IEC/IEEE 24748-10	Guidelines for systems engineering agility	Deepens the discussion of agile and evolutionary approaches within life cycle models
ISO/IEC/IEEE 15289	Content of life cycle information items (plans, reports, specifications)	Defines what goes into the documents a life cycle produces
ISO/IEC 330xx with TS 33060 and TS 33061	Process assessment framework and models for system and software processes	Assesses process capability; 24748-1 helps you design a life cycle that performs well in assessment
ISO 9001	Certifiable quality management system requirements	A documented life cycle model supports its planning and design-control requirements
Agile frameworks (Scrum, SAFe and others)	Team and programme practices for short-cycle delivery	Can be used as the development approach inside a life cycle model, synchronised at gates

How to talk about the relationships

A precise way to describe your organisation's position: "Our engineering processes are defined using ISO/IEC/IEEE 15288 and 12207. We follow the guidance of ISO/IEC/IEEE 24748-1 for life cycle models and their adaptation, and Parts 4 and 5 for our planning documents. Process capability is assessed against ISO/IEC TS 33060 and TS 33061." That statement is accurate and avoids the common error of claiming "certification" to guidance.

Domain standards

Many domain standards, for example in automotive, rail, aerospace, medical devices and functional safety, define their own life cycles (often called safety life cycles or V-models). The concepts from 24748-1 help you map these domain life cycles onto a common stage-and-gate framework so that one project can satisfy several standards without running parallel, conflicting plans.

Common pitfalls and best practices

Pitfalls

Treating stages as processes. Teams assume testing belongs only to development or that requirements stop after concept, so later changes are handled informally and baselines drift.
Planning only to first delivery. Support and retirement are ignored until they hurt; spare parts, update mechanisms and data deletion obligations appear as costly surprises.
Rubber-stamp gates. Gates that can only say "go" provide no control; problems pass forward and grow.
One approach forced on everything. Applying strict sequential development to fast-changing software, or short agile cycles to expensive tooling, wastes money and creates friction.
Undocumented adaptation. Stages and reviews are skipped quietly, so no one can later explain why, and assessors treat the gaps as weaknesses.
Forgetting enabling systems. Test benches, production lines and pipelines are late, and the system of interest waits for them.
Claiming certification to 24748-1. It is guidance; such claims damage credibility with informed customers.

Best practices

Maintain a small library of life cycle models in the organisation, each with guidance on when to use it and how far it may be adapted.
Write short life cycle concepts in the concept stage covering acquisition, deployment, operation, support and retirement.
Define gate criteria, decision authorities and record templates, and allow decisions such as continue, go back, pause or stop with conditions.
Choose development approaches per element, matching how well needs are understood and the cost of change, and synchronise them at gates.
Record every adaptation with its reason and approval, and feed lessons back into the organisation's models.
Plan enabling systems as first-class work, with their own schedules and owners.
Use the series together: Part 1 for concepts, Parts 2 and 3 for applying the processes, Parts 4 and 5 for plans, 15289 for information items.

Summary and key takeaways

ISO/IEC/IEEE 24748-1:2024 is guidance on life cycle management that helps people apply the process standards 15288 and 12207 together; it replaced the 2018 edition.
A life cycle model organises the life of a system into stages, separated by decision gates, and serves as a shared reference for everyone involved.
The generic stages are concept, development, production, utilisation, support and retirement; utilisation and support usually run in parallel.
Gate decisions include beginning the next stage, continuing, going back, pausing or terminating, and should be evidence-based and recorded.
Processes are not stages: most processes are used in most stages, applied iteratively, recursively and concurrently.
Development approaches (sequential, incremental, evolutionary) can differ between elements of one system if they are synchronised.
Adaptation is expected and must be documented; there is no certification against 24748-1, so evidence flows through 15288 or 12207 conformance, process assessment and quality audits.
Early life cycle concepts and planned enabling systems prevent costly surprises in support and retirement.

Reflection questions

Pick a system you have worked on. What was the system of interest, which enabling systems did it depend on, and which of those caused delays?
Think of the last gate or milestone review you attended. Which decision options were really available, and how was the decision recorded?
For a product with both hardware and software, which development approach would you choose for each element, and where would you synchronise them?
Write two sentences of a retirement concept for a system you know. What design or contract decision does it imply today?
Your organisation wants to drop a formal design review for small projects. How would you decide, document and justify this adaptation so that an assessor would accept it?