The Difference Between PROJECT & PRODUCT Life-Cycles

All too often I see the concept of Life-Cycle applied as if it were one dimensional. Yes with choice within the dimension but still missing expressions of the essentials. Worse the choice aspect seems mostly to incite fevour about exclusive selection between the ‘right’ and the ‘wrong’ life-cycle.

It is perhaps the ignorance of youth that seems so often to make the young think ‘old ways’ are out-dated and promote ‘the new’ without realisation that often they are turning a cycle that has revolved with several generations. Thus it is with life-cycles, but also we are evolving with each turn. The reuse of old ideas is never quiet as they were used before.

All life-cycles are some jumble of activities that run more or less in a sequence but are overlapped, iterated, forgotten, added, emphasized or deprecated, divided or merged.

Life-cycles exist at three levels that match the governance structures that control capital.

There is the Strategy/ Leadership/ Direction/ Investment/ Care of Capital life-cycle. Its duration may run from under a year (think consumer electronics product life-cycle) to decades (think Oil field and refinery infrastructure).

As a ‘profession’ we folk involved in “delivering change” have some confused notions that splosh ‘program’ partly over this space. Better thinking about portfolios and Investment Life-Cycles would aid us all.

The investment cycle is more or less Idea/ Evaluation/ Commitment/ Project/ Operations/ Withdrawal. Withdrawal may be invisible under the newly advancing Idea/ Evaluation/ Commitment/… of the replacement use of capital

Within the Investment life-cycle there are the twins of the Project Management cycle and the Operational Management cycle; an event driven cycle followed by a time driven cycle.

They are both about governance. The project cycle is the governance of development activity and development has as many life-cycles as there are products to be built, services to be enabled, impacts to be caused or deliverables to be delivered.

Here is where iterative versus design first life-cycle arguments truly belong. The nature of market-place, technical development capability and clarity and stability of customer wants dictates which elements of a project & operational pair’s needs lead to the optimum selection.

A Project Life-cycle is essentially “Who matter?, What do they want?, How will we deliver it?, Design, Build, Test, Integrate and then either repeat the core D-B-T-I if the PRODUCT cycle is iterative or deliver if the D (Design) had integrity constraints that demanded B occurred in full knowledge of D or we have done it so many times we knew all the D & B steps before we started.

A Project may then also be an iterating structure and perhaps we are now running a program. IE Program is a jumble of projects, project a jumble of development life-cycles.

Every human endeavour is a nested set of Investment, Program and Product Development life-cycles or Investment, Project & Product cycle. At least one aspect of confusion arises from the fact that Program must always exist (the envelop that runs from ‘Decide’ before project to ‘Implement’ after project) and that Development lifecycles must always exist but a wide variety of them are often needed concurrently within the life-cycle providing governance of the development activity – be that program with a single project – which most then wrongly call ‘project’ and so dissassociate cost from benefit – or program with more than one project – which now trips up on the boundary between responsibility for change versus for operations.


We won’t fix it till we better understand it