Specialist life cycles are governance life cycles that address a specific business context. They are typically heavily tailored to suit their specific context and at first sight do not obviously fit the mould of generic governance life cycles.
The purpose of this look at two particular specialist life cycles is to show that the fundamental principles of life cycles are common to all good governance and can be adapted and tailored to meet very specific requirements.
The first example is from NASA. As you would expect from an organisation that operates at the cutting edge of technology and is responsible for the full asset life cycle, the approach is detailed and thorough. The full NASA approach1 has three levels. The diagram below only shows the top-most level for the purpose of a very broad comparison with the generic governance life cycle.
Pre-phase A in the NASA model is effectively the work that goes on in the definition phase of a portfolio to decide which missions to pursue from a “broad spectrum of ideas and alternatives”.
After a review and decision, the idea may progress to Phase A: Concept and Technology development where the feasibility and desirability is assessed and the mission’s compatibility with strategic objectives is confirmed. This is similar to the generic identification phase.
Phase B: Preliminary Design and Technology Completion is the equivalent of the definition phase. It defines enough detail to establish an “initial baseline capable of meeting mission needs”; develop the structure of the end product and generate preliminary system design. Key outputs will be mock-us and prototypes.
Phase C: Final Design and Fabrication, recognises that as the project moves in to the delivery phase there is still detailed design work to do along with fabrication of hardware and coding of software. Iterative development approaches are coming to the fore here.
In Phase D: System Assembly, Integration and Test, Launch, everything (which the NASA handbook describes as “Hardware, software and humans”) is brought together integrated and tested. Interestingly, the launch is part of this phase. It is perhaps the ultimate handover which either succeeds or fails in a very binary way. It incorporates the elements of handover but not the formal closure of the project that the generic closure phase includes.
This is really where the ‘project’ ends and the mission starts but it is all part of the asset life cycle. The work moves into operation and ultimately moves to NASA’s close out (or termination of the asset) once the craft has done its job and the scientific benefits have been realised.
It must be noted that this is a very interpretive and high-level comparison. The NASA Systems Engineering Handbook explains the life cycle in considerably more detail.
The second example is taken from the Royal Institute of British Architects (RIBA)2. As might be expected from the professional body for Architects, the emphasis is on design.
Where the generic life cycle has two pre-delivery phases, this life cycle has four. The delivery and closure are two visually short phases (from the Architect’s point of view) that do not involve anywhere near as much work for the Architect. The ‘In-use’ (Benefits realisation) usually doesn’t involve the Architect at all.
When mapping the two life cycles, the boundary between RIBA phases 2 and 3 was aligned with the boundary between identification and definition because that is where the “Final Project Brief” is produced. When comparing life cycles, the outputs of each phase are the key to understanding equivalences.
Within their broadly linear governance life cycles, both NASA and RIBA adopt highly iterative development life cycles. This is explicit in the NASA handbook and implicit in the way that buildings are designed, especially since the advent of computer aided design (CAD) and Building Information Management (BIM).
For detailed information on these life cycles and their context, see: