capability life cycle management · 2020. 1. 30. · capability life cycle (clc) management...

Capability Life Cycle (CLC) Management

Professor Mike Ryan & Dr Shari Soutberg

©2020 ‐ 1 ‐

Capability Life Cycle (CLC)Management

Professor Mike Ryan

Dr Shari Soutberg

Capability Life Cycle (CLC)

The aim of this course is to:

• explain the intent and features of CLC policy including context, behaviours, principles and management arrangements;

• provide an overview of the CLC process;

• identify the capability management practices necessary to deliver the CLC;

• describe the CLC artefacts and their development; and

• understand the pathways for an Approval Submission through Defence and Government.

2



©2020 ‐ 2 ‐

Course Program

• Background to FPR and CLC.

• Context and Behaviours.

• CLC Process in overview.

• Frameworks, roles, management, practices, documents, and artefacts.

• Capability Management Practices:

– Systems Engineering.

– Project and Program Management.

– Integrated Logistics Support.

– Procurement and Contracting.

– Governance, Risk Management, and Assurance.

• CLC Documents and Artefacts, including examples.

• Submissions and their pathways.

3

Background to CLC



©2020 ‐ 3 ‐

FPR: How Did We Get Here?

1973 – Tange Review

2003 – Defence Procurement Review

2008 – Mortimer Review

2011 – Black Review

2014 – First Principles Review

Numerous Senate Reviews and Audits

Source: First Principles Review: Creating One Defence, 2014.

Reason for First Principles Review (FPR)

• Defence needs to work more effectively to meet future challenges.

• For capability development FPR found (inter alia):

– processes: complicated, slow, inefficient, unclear accountabilities;

– evidence of waste, inefficiency and rework;

– delayed decisions; and

– over‐escalation of issues for decision.

• So ... FPR report identified the need for:

– simplicity,

– greater agility, and

– timely delivery.

6

Source: First Principles Review: Creating One Defence, 2014.



©2020 ‐ 4 ‐

FPR Recommendations

Six core recommendations:

1. Strong strategic centre, stronger accountability and decision making.

2. Single end‐to‐end capability development function.

3. Enterprise approach.

4. Right skills in appropriate jobs.

5. Manage staff resources for optimal use of funds.

6. Commence implementation immediately.

7

First Principles• Clear authorities and accountabilities aligned with

resources• Outcome orientation• Simplicity

• Focus on core business• Professionalism• Timely, contestable advice• Transparency

FPR – Key Messages 8

“The strengthening of the strategic centre and the

establishment of a single end‐to‐end capability development function is reshaping how we

think and act.”

“… in conceiving of the future force, we need to talk about

the integrated force, integrated at an organisational

level and integrated technically and culturally”

“…If you follow the integration logic, we are moving, inexorably, towards a single war‐fighting domain. Our ability to operate effectively across this ‘One Domain’ will depend on our ability to build an Integrated Joint

Force by design”.

Source: VADM Ray Griggs, VCDF, ASPI Building the Integrated Joint Force Seminar, 7 June 2017



©2020 ‐ 5 ‐

One Defence is Key 9

“Intent of the First Principles Review, to transition to a One Defence model and focus on achieving a truly

integrated joint force by design.”

Source: AVM Mel Hupfeld, Head Force Design, INCOSE IS 17 July 2017

Relationship between FPR and the CLC 10

“At the heart of the FPR implementation has been the Capability Life Cycle redesign, which is heavily focused on tailoring, streamlining and better integrating our capability solutions. It is equipping us to take that conceptual journey towards a single domain.”

Source: VADM Ray Griggs, VCDF, ASPI Building the Integrated Joint Force Seminar, 7 June 2017.



©2020 ‐ 6 ‐

Capability Life Cycle

11

What is a Capability Life Cycle?

• ‘Capability’: capacity or ability of an organisation to achieve outcomes or meet core functions.

• Capability realised through Assets which:

– enable that capability, and

– bring value to organisation.

• Assets have a ‘life cycle’.

12



©2020 ‐ 7 ‐

Asset Management Life Cycle13

PlanningAcquisition/ Construction

Operation (use) and Sustainment

Retirement/Disposal

Task 1Task 2

Task 3




Retirement/Disposal

Task 1Task 2

Task 3

ImplementationPlanning Analysis Design Maintenance Disposal

System Development



©2020 ‐ 8 ‐




Retirement/Disposal

Task 1Task 2

Task 3

ImplementationPlanning Analysis Design Maintenance Disposal

Service OperationService Strategy

Service Design

Service Transition

Continual Service Improvement

ITIL (Cycle)

System Development


Defence CLC

16



©2020 ‐ 9 ‐

What is Defence Capability?

• Defence capability:

– capacity or ability of the ADF to achieve a particular operational effect.

• Defence capability systems:

– deliver the operational effect, and

– also have a life cycle.

• Defence approach to life cycle …

17

Defence Capability Life Cycle (CLC)18

Acquisition Strategy and Concepts

Risk Mitigation and Requirements Setting

In‐Service and Disposal

What is the Need? What is the Solution? Acquire Solution Use the Solution (then dispose)

1. http://www.ga.gov.au/scientific‐topics/marine/jurisdiction/map‐series2. http://www.navy.gov.au/fleet/ships‐boats‐craft/future/opv3. https://www.sitecraft.net.au/news/defence‐minister‐announces‐commencement‐of‐opv‐construction/4. https://www.theaustralian.com.au/nation/defence/opvs‐will‐give‐fleet‐a‐bigger‐picture/news‐story/6729b38f69823a32866af390e05efcac

Offshore Patrol Vessel (OPV)



©2020 ‐ 10 ‐

Defence Capability Lifecycle (CLC)

Four‐phase process which:

1. Identifies capability needs.

2. Defines and decides capability solutions.

3. Acquires the capability and introduces it into service.

4. Supports the capability through its life including disposal.

19



In-Service and Disposal

Key Features of Defence CLC

• Policy in Interim CLC Manual.

• Applies to:

– major capital equipment (military equipment);

– ICT; and

– facilities.

• Tailored to suit circumstances.

• Supports integrated joint force by design.

20

http://www.defence.gov.au/CIOG/Careers.asphttps://images.defence.gov.au/assets/archives (M113 Armoured Personnel Carrier & C17‐A RAAF Base Amberley)Source: Architecture Development as a Mission System Integrator, Steven J. Saunders Raytheon Australia, SETE 2008 Canberra



©2020 ‐ 11 ‐

CLC – Principles

• Joint and integrated capability outcomes.

• Integrated planning.

• Flexible, risk‐based, tailored.

• Contestability.

• Discouraging risk aversion.

• Defence focus on core business.

• Default to fastest and simplest.

• Transparency.

• Clear responsibilities and accountabilities.

• Early and transparent industry involvement.

21

Source: Updated Interim CLC Manual

Applied throughout

the CLC

Post Jan 20 – Core CLC Design Principles

• Joint and integrated capability outcomes

• Aligned with strategic and resource guidance

• Integrated project planning (FIC)

• Flexible risk‐based

• Contestability


• Defence focus on planning and governance


• Transparency.

• Clear responsibilities and accountabilities

• Balance capability, cost, schedule, risk

• Engage industry early and as a partner

• One Defence : CASG is fully integrated

22

Source: CLC Manual V1.0

Applied throughout

the CLC



©2020 ‐ 12 ‐

So ….

• What has changed as a result of CLC?

• What hasn’t changed?

23

What has Changed as a Result of CLC?

• Emphasis on Behaviours.

• Modified Process.

• Additional Frameworks: such as Force Design, Smart Buyer.

• Modified Management ‘structures’.

• Approach: default to simplest, tailored, risk‐based, sufficient.

• New Artefacts.

• Modified Industry role.

24



©2020 ‐ 13 ‐

Modified Process and Decision Points up to Acquisition Phase

Snapshot of Key Changes Post‐CLC 25

Industry: Engage early, part of FIC, IPT, and ‘above-the-line’ support

Additional Frameworks

New Management Roles and ‘Structures’

AcquisitionStrategy and

Concepts Risk Mitigation and

Requirements Setting In-Service and

Disposal

Gate 0 Gate 2Gate 1

Behaviours and Approach

New Artefacts:

• One Defence

• Joint/integrated

• Transparency

• Tailored

• Sufficiency

• Risk-based

• Force Design (incl DCAP)

• Contestability

• Smart Buyer

• Integration and Interoperability

• Investment Committee (IC)

• Integrated Investment Program (IIP)

• Management layers: Portfolio (Capability Streams), Program, Product, Project

• CLC Accountability Model: roles, responsibilities and relationships

Program: CPN, Program Strategy, PIOC

Proposal: JCN, JCNS, PES, Business Case, IPMP

Modified Process and Decision Points up to Acquisition Phase

CLC Manual 2020: Capability Governance Framework 26

Industry: Engage early, part of FIC, IPT, and ‘above-the-line’ support

Additional Frameworks

New Management Roles and ‘Structures’




Disposal

Gate 0 Gate 2Gate 1

Behaviours and Approach

New Artefacts:

• One Defence

• Joint/integrated

• Transparency

• Tailored

• Sufficiency

• Risk-based

• Force Design (incl DCAP)

• Contestability

• Smart Buyer

• Integration and Interoperability

• Investment Committee (IC)

• Integrated Investment Program (IIP)

• Management layers: Portfolio (Capability Streams), Program, Product, Project

• CLC Accountability Model: roles, responsibilities and relationships

Program: CPN, Program Strategy, PIOC

Proposal: JCN, JCNS, PES, Business Case, IPMP



©2020 ‐ 14 ‐

What hasn’t Changed as a Result of CLC?

• Traceability to government direction.

• Requirements to be defined.

• Enabling Practices to be applied, including:

– Project Management,

– Systems Engineering,

– Integrated Logistics Support, and


• Compliance with legislation and regulations.

• Accountability for proper use of Commonwealth resources.

27

FPR and CLC: Recap

• One Defence: enterprise approach.

• Single warfighting domain: Joint Force by Design.

• Strategy‐led: traceable to Government Direction.

• Single end‐to‐end capability development.

• Tailored, risk‐based, simple, sufficient.

• Contested: test and improve proposals.

28



©2020 ‐ 15 ‐

CLC – Implementation

• Full description:

– CLC Manual on VCDF CLC website; and

– DRN CLC Website – Modelpedia.

29

Summary

The six core recommendations of FPR:

1. Strong strategic centre, stronger accountability and decision‐making.

2. Single end‐to‐end capability development function.

3. Enterprise approach.

4. Right skills in appropriate jobs.

5. Manage staff resources for optimal use of funds.

6. Commence implementation immediately.

30



©2020 ‐ 16 ‐

Summary

The ten CLC Principles:

1. Joint and integrated capability outcomes.

2. Integrated planning.

3. Flexible, risk‐based, tailored.

4. Contestability.

5. Discouraging risk aversion.

6. Defence focus on core business.

7. Default to fastest and simplest.

8. Transparency.

9. Clear responsibilities and accountabilities.

10.Early and transparent industry involvement.

31

Summary: CLC Design Principles





• Contestability




• Transparency.





32


Applied throughout

the CLC



©2020 ‐ 17 ‐

Summary: CLC Design Principles





• Contestability




• Transparency.





33


Applied throughout

the CLC

Applying the CLC



©2020 ‐ 18 ‐

Defence CLC Challenge35

+Technical endeavour to deliver and

support capability Precision and rigour

Complexity

Engineered systems

Management of Public Resources

Accountability

Performance

Governance/ Legal

+Many Stakeholders

Defence CLC Challenge

Capability Development is at intersection of:

• Stringent Public Sector obligations.

• Complex technical endeavour.

• Significant stakeholder interaction.

https://images.defence.gov.au



©2020 ‐ 19 ‐

Defence CLC Challenge

Implementing the CLC is not an administrative process … it involves:

• Many skill sets: military, technical, business.

• Many considerations: strategic, legal, engineering, support.

• Many stakeholders: Defence, industry, government, civil.

37

Delivering Capability is the Goal

• The goal is to field the right capability in a timely manner.

• From a concept to a leading‐edge engineered system used in theatre.

38

https://images.defence.gov.au/assets/archives (M113 Armoured Personnel Carrierhttps://images.defence.gov.au/assets/archives/5003‐All‐Defence‐Imagery/?q=cyber



©2020 ‐ 20 ‐

Introduction to CLC: Course Coverage

• An overview of:

– What needs to happen (and be produced).

– When it needs to happen.

– Why it is done.

– Who is involved.

• Provide an understanding of how capability development actions fit together …

39

Course Coverage

• Course will emphasise the CLC Process and supporting Methods so that you have Information to take Actionsincluding Decisions.

40

Process & Methods

Information Documents

OCDBusiness

Case

yx

4a5

aa d

yx

4a5

avpqa

dyx

1 2 n

0

...

1.1 1.2 1.n...

1.1.1 1.1.2 1.1.n...

n.1 n.2 n.n...

n.n.1 n.n.2 n.n.n...

Needs Hierarchy Measures Hierarchy

Level 1

Level 2

Level 3

CI

COI

MOE

Level 4 MOP

Level n TPM

….

….

Mission

Actions/Decisions



©2020 ‐ 21 ‐

Introduction to CLC: Course Coverage

• Context: Legal, Policy, Regulatory.

• Behaviours: existing and CLC.

• Process (Frameworks and Artefacts).

• Practices (supporting methods and techniques).

• Artefacts/Documents.

• Methods.

• Submissions.

41

Capability Management Practices

CLC Process (Artefacts and Frameworks)

Course Topic ‘Map’—Applying the CLC 42

Legislative, Regulatory, and Policy Context

Acquisition Strategy and



Disposal

Gate 0 Gate 2Gate 1

Behaviours

Systems EngineeringProgram, Product and Project Management

Risk Management and Assurance

Logistics / ILS

Commercial / Procurement and Contracting



©2020 ‐ 22 ‐

CLC Examples

• In this course we use a number of examples in the context of the CLC to consider how CLC might be applied to real situations.

• Examples illustrate through a mix of actual and hypothetical elements.

• Examples:

– Program: Integrated Air and Missile Defence (IAMD).

– Project: Electronic Support (ES) system.

43

IAMD: Program Example

• Relevant to CLC discussion on:

– Programs.

– System of Systems (SoS).

– Joint Force by Design.

– Integration and Interoperability (I2).

– Program‐level documents and artefacts.

44

Source: http://www.anzidlsoc.com.au/1600_AIR6500_Brief_to_TDL_Interoperability_Summit_2017.pdf



©2020 ‐ 23 ‐

SEA 1448 Ph4A: Project Example

Relevant to CLC discussion on:

• CLC process, frameworks and management constructs such as Smart Buyer and Risk Mitigation.

• Enabling Practices:


– Project Management.

– ILS.


– Risk Management and Assurance.

• Artefacts and documents to be developed.

45

CLC Context



©2020 ‐ 24 ‐



Applying the CLC 47





Disposal

Gate 0 Gate 2Gate 1

Behaviours



Logistics / ILS


Legislative, Regulatory and Policy Context 48

Commonwealth Legislation

Commonwealth Policy

Defence Policy

Defence Regulation

Defence and its officials must comply with applicable Legislation, Policy, and Regulation.



©2020 ‐ 25 ‐

Key Commonwealth Legislation Including but not limited to …

• Public Governance Performance and Accountability (PGPA) Act

2013

• Public Service Act 1999

• Defence Force Discipline Act 1982

• Work Health and Safety Act 2011

• Crimes Act 1914

• Defence Act 1903

• Archives Act 1983

• Public Interest Disclosure Act 2013

• Environment Protection and Biodiversity Conservation Act 1999


Commonwealth Policy

Defence Policy

Defence Regulation

Key Commonwealth Legislation Including but not limited to …

• Public Governance Performance and Accountability Act (PGPA)

2013

• Public Service Act 1999

• Defence Force Discipline Act 1982

• Work Health and Safety Act 2011

• Crimes Act 1914

• Defence Act 1903

• Archives Act 1983

• Public Interest Disclosure Act 2013

• Environment Protection and Biodiversity Conservation Act 1999


Commonwealth Policy

Defence Policy

Defence Regulation



©2020 ‐ 26 ‐

PGPA Act 2013

• The PGPA Framework requires Defence officials to:

– be consistent with Australian Government policies;

– use and manage public resources in an:

• efficient,

• effective,

• economical and

• ethical manner;

– exercise ‘care and diligence’;

– “act honestly, in good faith and for a proper purpose”;

– not improperly use their position or information; and

– disclose interests.

51

Source: DPPM April 2017, Paragraph 21

Key Commonwealth Policies

• Including but not limited to:

– Commonwealth Procurement Rules;

– Indigenous Procurement Policy; and

– Commonwealth Risk Management Policy.

52


Commonwealth Policy

Defence Policy

Defence Regulation



©2020 ‐ 27 ‐

Commonwealth Procurement Rules (CPRs)

• Commonwealth Procurement Rules (CPR) have effect under the PGPA Act 2013.

• CPR:

– set out rules for procuring goods and services;

– indicate good practice;

– keystone of Government’s procurement policy framework; and

– fundamentally focused on achieving value for money.

53


Commonwealth Policy

Defence Policy

Defence Regulation

Key Defence Policies

• Including but not limited to …

– Defence Environment Policy;

– Defence Industry Policy Statement 2016;

– Defence Procurement Policy Manual (DPPM); and

– Joint Directive on Management of Risk in Defence(30/2015).

54



©2020 ‐ 28 ‐

Key Defence Policies

• Including but not limited to …

– Defence Environment Policy;

– Defence Industry Policy Statement 2016;

– Defence Procurement Policy Manual (DPPM); and

– Joint Directive on Management of Risk in Defence(30/2015).

55


Commonwealth Policy

Defence Policy

Defence Regulation

Defence Procurement Policy

• Defence Procurement Policy Manual (DPPM) incorporates:

– CPR, and

– Defence Procurement Policy Directives.

• Must be complied with by Defence officials.

• Promotes responsible and accountable spending.

• Supports proactive management of risks.

56

Source: DPPM April 2017



©2020 ‐ 29 ‐

Key Regulations Including but not limited to …

Defence Regulation: Technical aspects:• Provides confidence to users about the safety and technical

integrity of their systems and equipment.• Ensures:

– fitness for service,– safety, and– environmental compliance.

57

Technical Regulation

• Seaworthiness: Defence Seaworthiness Management System Manual (DSwMS).

• Airworthiness: Defence Aviation Safety Regulation (DASR).

• Land Technical Regulation: ADF Materiel Manual ‐ Land (TRAMM‐L)*.

• Explosive Ordnance Regulation: eDEOP 101 ‐ Department of Defence Explosives Regulations.

• ICT: CIOG ICT Technical Regulatory Framework.

58

* Will be replaced by Landworthiness Manual



©2020 ‐ 30 ‐

Commonwealth Resource Management

Commonwealth Performance Framework

• Government Outcomes: intended results of actions by the Government on the Australian community.

• Commonwealth Programs: primary vehicle by which results are achieved.

• Entities are required to identify the Programs which contribute to government Outcomes over the Budget and forward years.

60

Source: https://www.finance.gov.au/ and defence.gov.au



©2020 ‐ 31 ‐

Commonwealth Programs

• A program is defined in:

– Appropriation Acts, and

– Portfolio Budget Statements,

61

Source: https://www.finance.gov.au/resource‐management/pgpa‐glossary/programme/

Defence Example 62

Corporate Plan

Plan

Purpose: Defence’s role, objectives and functions

Defence’s Purpose is to:

Defend and protect Australia and its strategic interests

Source: https://www.defence.gov.au/



©2020 ‐ 32 ‐

Outcomes Delivered Through Programs63


Budget Programs

Outcome Statements

$

Purpose

Outcome 2: Protect and advance

Australia’s strategic interests

Outcome 1: Defend Australia and its

national interestsDefend and protect Australia and its strategic interests

Programs 1.1 – 1.3 (Operational)

Programs 2.1 – 2.17 (Departmental and Administered)

Two Defence Outcomes64

Outcome 2: Protect and advance Australia’s strategic

interests

Outcome 1: Defend Australia and its

national interests

Programs 1.1 – 1.3

Departmental Budget Programs

Outcomes

Program 1.3: Defence contribution to National Support Tasks in Australia

Outcomes 1.1‐1.3

Outcomes 2.1‐2.17

Programs 2.1 – 2.17

Program 2.1 Strategic Policy and Intelligence

Examples

Program 2.9 Capability Acquisition and Sustainment

Program 2.6 Army Capabilities

$




©2020 ‐ 33 ‐

Portfolio Budget Statements (PBS)65

Portfolio Budget Statements

• Informs Senators and Members of Parliament of proposedallocation of resources to entities in each portfolio.

• Entities receive resources from the annual appropriations acts such as Appropriation Bills (No. 1 and No. 2) 2018‐19.

Budget$


Defence Annual Report66


• SecDef andCDF’s performance report (for FY) to:• Minister for Defence, • Parliament of Australia, and • Australian public.

• Prepared IAW parliamentary reporting and legislative requirements (especially PGPA Act).

Defence Annual Report:Annual Performance

Statement

• Against Outcomesand individual Programs

• Value of Outputs



©2020 ‐ 34 ‐

Five Principal Defence Outputs to Government

1. The Joint Force-in-Being

2. Joint Force Operations

3. National intelligence products

4. Engagement and advice to Government

5. Obligations to Government

67

Source: https://www.defence.gov.au/ (PBS)

Commonwealth Performance Framework 68

Source: https://www.finance.gov.au/

Corporate Plan

Defence Annual Report:Annual Performance

Statement

Plan

How we went X 9/10

Portfolio Budget Statements

Budget $



©2020 ‐ 35 ‐

Bottom Line on Context

• CLC practitioners must comply with applicable legislation, policy, and regulation.

• Compliance with Government direction and traceability of effort to that at all times (mission or capability engineering is relevant.

• ONLY use resources (do work) for Government‐directedactivities.

69

CLC Behaviours

• “It is critically important that personnel within the Capability Lifecycle exhibit partnership behaviours, cooperation, and intellectual honesty focused on government decisions”

70




©2020 ‐ 36 ‐

Behavioural characteristics that underpin CLC

• Collaboration, trust, transparency

• Provide best possible advice to empower:

– Sec & CDF

– Government to make good policy decisions

• Full range of factors and influences considered

• Being agile and adaptable wrt environment

• Ensure stakeholder accountability

• Engage Ministers and central agencies early to aid awareness

71


CLC Behaviours



©2020 ‐ 37 ‐



Applying the CLC73





Disposal

Gate 0 Gate 2Gate 1

Behaviours



Logistics / ILS


Importance of Behaviours

• CLC changes have introduced new work context:

– more flexibility in how work is conducted;

– more integration of activities;

– more interdependencies between stakeholders;

– greater need for collaboration; and

– less strictly defined boundaries.

• Sound Behaviours are critical to making this work.

74



©2020 ‐ 38 ‐

CLC Behaviours

• Acceptance of Accountability at all levels.

• Embracing Contestability.

• Discipline in documentation.

• One Defence: Partnership, cooperation and collaboration.

• Strong behavioural leadership at all levels.

• Deliver on Government direction.

• Improved relationships: in Defence and with Central Agencies.

• Manage risk: Deal with ambiguity and don’t be risk averse.

75

Key Behaviour: Embrace Contestability

• Culture of wanting ideas, proposals and agendas ‘tested’.

• Makes proposals robust.

• Helps improve decisions.

• Establish trust with Government and Central Agencies.

• Engage early with Contestability so can be ‘built into’ brief.

76



©2020 ‐ 39 ‐

Key Behaviour: One Defence

• Collegiate approach: open, transparent and collaborative.

• From working level through to senior committees.

• Critical to development of the Joint Force.

77

Key Behaviour: Tailoring and Sufficiency

• Tailor:

– commensurate with complexity, risk;

– no prescribed approaches; and

– not a ‘cookie cutter’ approach.

• Sufficiency: Work, documents only to extent necessary.

• Discipline in Documentation: limit detail to that needed.

• Define and argue the tailored approach.

Tailor work and documents to what is needed.

78



©2020 ‐ 40 ‐

Key Behaviour: Discipline in Documentation

• Proposals and Briefs must reflect discipline:

– simple, readable, plain English;

– ‘tell the story’;

– not excessive technical language;

– write for final audience—Ministers;

– clearly link effort to Government priorities ;

• Capability Streams,

• Show support for Government’s broader view,

– evidence‐based, identify risks, identify unknowns; and

– include Contestability.

79

Source: Defence CLC Seminar, Feb 2107.

Key Behaviour: Manage Risk

• Manage risk:

– deal with ambiguity, and

– discourage risk aversion.

• Conscious risk reduction mindset throughout CLC.

• Use risk management techniques to:

– identify risks,

– develop risk profile, and

– determine risk mitigation/control.

80

Identify

Assess

Control

ReviewRisk



©2020 ‐ 41 ‐

CLC Behaviours add to Extant Values

• APS Values (ICARE: Impartial, Committed to service, Accountable, Respectful, Ethical).

• APS Code of Conduct.

• Defence‐wide Values (PLICIT: Professionalism, Loyalty, Integrity, Courage, Innovation, Teamwork).

• Single‐Service Values.

• One Defence Leadership Behaviours (CLARITI: Contributor, Learner, Accountable, Risk Manager, Inclusive, Team Builder, and Innovator).

• Professional Codes of Ethics.

81

Source: https://resources.apsc.gov.au/

Practices: Codes of Ethics

Specialist practitioners are also subject to Codes of Ethics, including:

• Project Management:

– Australian Institute of Project Management (AIPM) Code of Ethics.

• Engineering:

– Engineers Australia (EA) Code of Practice.

82



©2020 ‐ 42 ‐

Specialist Practitioners: Common Features

• Professionalism.

• Integrity.

• Competence.

• Act on basis of a well‐informed conscience.

• Act on basis of adequate knowledge.

83

Implications for Defence Managers

Defence officials:

• will employ specialist (non‐core) skills sets;

• must assure they have:

– appropriate competencies, and

– comply with applicable codes of ethics.

84



©2020 ‐ 43 ‐

CLC Process – High‐level Overview



Applying the CLC86





Disposal

Gate 0 Gate 2Gate 1

Behaviours



Logistics / ILS




©2020 ‐ 44 ‐

Defence Capability Life Cycle (CLC)87


Risk Mitigation and Requirements

Setting


What is the Need? What is the Solution? Acquire Solution Use the Solution (then dispose)

1. http://www.ga.gov.au/scientific‐topics/marine/jurisdiction/map‐series2. http://www.navy.gov.au/fleet/ships‐boats‐craft/future/opv3. https://www.sitecraft.net.au/news/defence‐minister‐announces‐commencement‐of‐opv‐construction/4. https://www.theaustralian.com.au/nation/defence/opvs‐will‐give‐fleet‐a‐bigger‐picture/news‐story/6729b38f69823a32866af390e05efcac

Offshore Patrol Vessel (OPV)

CLC Process Overview

• This will be your high‐level process ‘map’.

• There are layers of effort and outcomes that we will address over the three days.

88



Setting




©2020 ‐ 45 ‐

CLC Process Overview89

Decide Need Define Solution Acquire Solution Use the Solution (then dispose)



Setting


Gate 0 Gate 2Gate 1

Four PhasesThree Decision Gates

Overview: Phases of the CLC

The CLC is a four‐phase, risk‐based decision‐making process which:





90



Setting




©2020 ‐ 46 ‐

CLC Gates

There are three decision gates:

– Gate 0: Defence decision to progress to next Gate. All proposals go through Gate 0.

– Gate 1: Government decision to progress proposals to Gate 2 including specific option(s).

– Gate 2: Government decision to acquire a fully defined and costed capability.

91



Setting


Gate 0 Gate 2Gate 1

Investment Approval Pathway


Decide Need Define Solution Acquire Solution Use the Solution (then dispose)



Setting


Gate 0 Gate 2Gate 1

Strategy to acquire and

support solution agreed

Needs defined

Reduce risky aspects and

specify requirements

Undertake Tendering based on

requirements

Contract for Acquisition and initial support

Manage Project

Deliver Capability System

Support Capability System

DisposeCapability System



©2020 ‐ 47 ‐





Disposal

Gate 0 Gate 2Gate 1

ApprovalsIC

Approval

IC, Government

Approval

IC, Government Approval

CM accepts into service

CM approves disposal

At the highest level CLC Process is punctuated by: • Approvals: internal and external.• Acceptance by ‘User’ (Capability Manager).





Disposal

Gate 0 Gate 2Gate 1

ApprovalsIC

Approval

IC, Government

Approval




Sub

mis

sion

App

rova

l &

Dire

ctio

n

Sub

mis

sion

Sub

mis

sion

App

rova

l &

Dire

ctio

n

App

rova

l &

Dire

ctio

n

Acc

epta

nce

App

rova

l

• Submissions proposed to authorities for ‘approval’ and ‘acceptance’. • Authorities generally provide ‘approval’ and ‘direction’.



©2020 ‐ 48 ‐





Disposal

Gate 0 Gate 2Gate 1

ApprovalsIC

Approval

IC, Government

Approval




Contestability

Sub

mis

sion

App

rova

l &

Dire

ctio

n

Sub

mis

sion

Sub

mis

sion

App

rova

l &

Dire

ctio

n

App

rova

l &

Dire

ctio

n

Off

er

Acc

epta

nce

App

rova

l

The submissions or proposals are checked on the way to the authorities e.g. Contestability (we will come back to this).





Disposal

Gate 0 Gate 2Gate 1

ApprovalsIC

Approval

IC, Government

Approval




Contestability

Activities

Smart Buyer

CM Needs

Force Design Outputs

Project Activities Project

ActivitiesSmart Buyer

Smart Buyer

Sub

mis

sion

App

rova

l &

Dire

ctio

n

Sub

mis

sion

Project Activities

Sub

mis

sion

Product Activities

App

rova

l &

Dire

ctio

n

App

rova

l &

Dire

ctio

n

Off

er

Acc

epta

nce

App

rova

l

• Many activities are undertaken to:• develop these submissions; • progress the proposal; and• implement all aspects of the investment (including use the

solution).



©2020 ‐ 49 ‐





Disposal

Gate 0 Gate 2Gate 1

ApprovalsIC

Approval

IC, Government

Approval




Contestability

Activities

Smart Buyer

CM Needs




Smart Buyer

Sub

mis

sion

App

rova

l &

Dire

ctio

n

Sub

mis

sion

Project Activities

Sub

mis

sion

Product Activities A

ppro

val &

D

irect

ion

App

rova

l &

Dire

ctio

n

Off

er

Acc

epta

nce

App

rova

l

Strategy to acquire and

support agreed

Needs defined

Reduce risky aspects and

specify requirements

Undertake Tendering

Contract for Acquisition and initial support

Manage Project

Deliver Capability System

Support Capability System

DisposeCapability System

The activities support the enable progress through the CLC.





Disposal

Gate 0 Gate 2Gate 1

ApprovalsIC

Approval

IC, Government

Approval




Contestability

Activities

Smart Buyer

CM Needs




Smart Buyer

Artefacts Tender docs

PFPS*

POCD*

PES 1JCNSJCN

FPS*

OCD*PES 2

IPMP

PES 3Reduced Risk

Sub

mis

sion

App

rova

l &

Dire

ctio

n

Sub

mis

sion

Project Activities

IMS

Sub

mis

sion

Product Activities

Contract Docs

IPMP

PDA/MAA

Contract Docs

IPdMP

PDA/MSASource Selection

App

rova

l &

Dire

ctio

n

App

rova

l &

Dire

ctio

n

Off

er

Acc

epta

nce

App

rova

l

Numerous documents/artefacts are developed to provide basis for agreement, understanding and to provide a record.



©2020 ‐ 50 ‐





Disposal

Gate 0 Gate 2Gate 1

ApprovalsIC

Approval

IC, Government

Approval




Contestability

Activities

Smart Buyer

CM Needs




Smart Buyer


PFPS*

POCD*

PES 1JCNSJCN

FPS*

OCD*PES 2

IPMP

PES 3Reduced Risk

Sub

mis

sion

App

rova

l &

Dire

ctio

n

Sub

mis

sion

Project Activities

IMS

Sub

mis

sion

Product Activities

Contract Docs

IPMP

PDA/MAA

Contract Docs

IPdMP


Practices/Disciplines

Systems/Requirements Engineering Systems Engineering Management

Project Management

Procurement and Contracting

App

rova

l &

Dire

ctio

n

App

rova

l &

Dire

ctio

n

Contract Management O

ffer

Acc

epta

nce

App

rova

l





Disposal

Gate 0 Gate 2Gate 1

ApprovalsIC

Approval

IC, Government

Approval




Contestability

Activities

Smart Buyer

CM Needs




Smart Buyer


PFPS*

POCD*

PES 1JCNSJCN

FPS*

OCD*PES 2

IPMP

PES 3Reduced Risk

Sub

mis

sion

App

rova

l &

Dire

ctio

n

Sub

mis

sion

Project Activities

IMS

Sub

mis

sion

Product Activities

Contract Docs

IPMP

PDA/MAA

Contract Docs

IPdMP




Project Management


App

rova

l &

Dire

ctio

n

App

rova

l &

Dire

ctio

n

Contract Management

Off

er

Acc

epta

nce

App

rova

l

Many practices and disciplines are needed to help:• Undertake the capability development activities

such as Systems Engineering, Procurement and Contracting.

• Support analysis and decision‐making.• Develop the documents.



©2020 ‐ 51 ‐





Disposal

Gate 0 Gate 2Gate 1

ApprovalsIC

Approval

IC, Government

Approval




Contestability

Activities

Smart Buyer

CM Needs




Smart Buyer


PFPS*

POCD*

PES 1JCNSJCN

FPS*

OCD*PES 2

IPMP

PES 3Reduced Risk

Sub

mis

sion

App

rova

l &

Dire

ctio

n

Sub

mis

sion

Project Activities

IMS

Sub

mis

sion

Product Activities

Contract Docs

IPMP

PDA/MAA

Contract Docs

IPdMP




Project Management


App

rova

l &

Dire

ctio

n

App

rova

l &

Dire

ctio

n


ffer

Acc

epta

nce

App

rova

l

CLC Artefacts and Relationships102

DWP

FOE FJOC

AMS

AJOC

What and Why How

PGPA Act

CPRs

Force Design

CPN

JCN

IIP

DIP

DPPM

Raised within Force Design as Program-level direction

PIOCProgram Strategy

PESJCNS

Smart Buyer

OCD

FPS

IPMPProjectWBS

IMS

Tender and Contract Documents

Selected ASDEFCON Suite

DPG

JCFConcepts

Strategic Guidance

Proposal = Sponsor’s Paper+JCNS+PES

Portfolio

Program

Project



©2020 ‐ 52 ‐

Why this work needs to be done …103




Disposal

Gate 0 Gate 2Gate 1

ApprovalsIC

Approval

IC, Government

Approval




Contestability

Activities

Smart Buyer

CM Needs




Smart Buyer


PFPS*

POCD*

PES 1JCNSJCN

FPS*

OCD*PES 2

IPMP

PES 3Reduced Risk

Sub

mis

sion

App

rova

l &

Dire

ctio

n

Sub

mis

sion

Project Activities

IMS

Sub

mis

sion

Product Activities

Contract Docs

IPMP

PDA/MAA

Contract Docs

IPdMP




Project Management


App

rova

l &

Dire

ctio

n

App

rova

l &

Dire

ctio

n


ffer

Acc

epta

nce

App

rova

l

• Responsible use of taxpayer dollars

• Reliable provision of Defence capability

Why this work needs to be done well …104




Disposal

Gate 0 Gate 2Gate 1

ApprovalsIC

Approval

IC, Government

Approval




Contestability

Activities

Smart Buyer

CM Needs




Smart Buyer


PFPS*

POCD*

PES 1JCNSJCN

FPS*

OCD*PES 2

IPMP

PES 3Reduced Risk

Sub

mis

sion

App

rova

l &

Dire

ctio

n

Sub

mis

sion

Project Activities

IMS

Sub

mis

sion

Product Activities

Contract Docs

IPMP

PDA/MAA

Contract Docs

IPdMP




Project Management


App

rova

l &

Dire

ctio

n

App

rova

l &

Dire

ctio

n

Contract Management

Off

er

Acc

epta

nce

App

rova

l

• What is done poorly ‘upstream’ will have a significant adverse impact ‘downstream’.

• Fixing can be costly or impossible.



©2020 ‐ 53 ‐

Defence Frameworks, Roles, and Management Structures

CLC Process Overview: Frameworks106




Disposal

Gate 0 Gate 2Gate 1

ApprovalsIC

Approval

IC, Government

Approval




Contestability

Activities

Smart Buyer

CM Needs




Smart Buyer


PFPS*

POCD*

PES 1JCNSJCN

FPS*

OCD*PES 2

IPMP

PES 3Reduced Risk

Sub

mis

sion

App

rova

l &

Dire

ctio

n

Sub

mis

sion

Project Activities

IMS

Sub

mis

sion

Product Activities

Contract Docs

IPMP

PDA/MAA

Contract Docs

IPdMP




Project Management


App

rova

l &

Dire

ctio

n

App

rova

l &

Dire

ctio

n

Contract Management

Off

er

Acc

epta

nce

App

rova

l



©2020 ‐ 54 ‐

CLC: Relies on Several New Frameworks 107

Definition of Framework

A framework is a particular set of rules, ideas, or beliefs which you use in order to deal with problems or to decide what to do.

https://www.collinsdictionary.com/dictionary/english/framework




Disposal

To implement the CLC a number of frameworks have been introduced that guide the activities.


Portfolio

Program

Product / Project

Capability Stream




Disposal



©2020 ‐ 55 ‐


• CLC Management Layers

• CLC Accountability Model

• Force Design Framework

• Smart Buyer Framework

• Contestability Framework

• Fundamental Inputs Capability (FIC)

• Integration and Interoperability (I2F)

• Procurement and Contracting Framework

Portfolio

Program

Product / Project

Capability Stream

Planning Sourcing Managing

Capability Governance Framework 110

• Committees:– Defence Committee (DC), Investment Committee (IC), Enterprise Business Committee

(EBC)

– Joint Warfare Committee, Defence Security Committee (DSC), Capability Manager Gate Review (CMGR), Estate and Infrastructure Gate Review (EIGR)

• Decision‐making roles:– Joint Force Authority (JFA), C4ISR Design Authority

– Assigned Roles eg Capability Manager, Domain Leads

• Performance Monitoring and Reporting:– Health Checks and Independent Reviews eg Independent assurance Reviews (IARs)

• Governance and Decision Documents: – Program Strategy, Project Directive, PES, IPMP, PDA

• Contestability

• Financial Considerations and Clearances:– Bi‐Annual Update of IIP

– Budget or Additional Estimates




©2020 ‐ 56 ‐

CLC Management Layers

Portfolio

Program

Product / Project

Capability StreamPortfolio

Program

Product / Project

Interim CLC Manual This Course

CLC Management Layers

1. Portfolio: whole view of Defence capability investment.

2. Capability Stream: ties investment to strategic outcomes.

3. Program: Groups of related Projects, Products, activities.

4. Product: capability system delivered by a Project.

112

Source: Updated Interim CLC Manual

Portfolio

Program

Product / Project

Capability StreamPortfolio

Program

Product / Project

Interim CLC Manual This Course



©2020 ‐ 57 ‐

New (Jan 20): Capability Program Architecture

1. Domains: 5 groups of related capabilities for info to Govt.

2. Capability Programs: 35 Groups of related Projects, Products, activities (similar effects).

3. Multi‐Domain Programs: 12 Programs which span Domains

4. Product: capability system delivered by a Project.

113

Source: Updated Interim CLC Manual and Defence CLC Manual V1.0 2020

Domains

Multi-Domain Programs

Product / Project

Capability Programs

Portfolio

Program

Product / Project

Interim CLC Manual Capability Program Architecture

Portfolio

Common factors: Layers and Groupings

1. Not project‐centric or stove‐piped approach

2. Communicates capability investment to Government

3. Assists capability integration

4. Helps manage and coordinate capability investment (especially between related efforts)

114

* And Multi‐Domain Programs



©2020 ‐ 58 ‐

Key points for post‐Jan 2020 CLC

1. Capability Streams replaced by Domains

2. Programs can be grouped for similar effect and multi‐domain relationships (MDPs)

3. Product and Projects are the building blocks

115

Portfolio

Programs (& Multi-Domain Programs)

Product / Project

Capability Streams/ Domains

This Course

This Course will explain…

1. Layers from Portfolio to Projects

2. Both Capability Streams and Domains

3. Program structure of any kind

4. Products and Projects

116

* And Multi‐Domain Programs

Portfolio

Programs *

Product / Project

Capability Streams/ Domains

This Course



©2020 ‐ 59 ‐

Portfolio

117

Portfolio118

Proposed Investment (Program or Project)

Whole Defence Capability Portfolio

https://images.defence.gov.au/assets/archives (M113 Armoured Personnel Carrier



©2020 ‐ 60 ‐

Portfolio: Benefits

• Comprehensive view of Defence capability investment:

– all capability investments deliver Defence’s strategic goals;

– optimise resources;

– manage risks at Portfolio level; and

– adjust investment actions as necessary.

119

Strategic Goals = Investment Portfolio120

Integrated Investment Program (IIP) Defence White Paper

Defence capability investment Portfolio managed through Integrated Investment Program (IIP).



©2020 ‐ 61 ‐

Integrated Investment Program (IIP)

• Rolling ten‐year expenditure plan

– Approved annually as part of Budget.

– Bi‐annual IIP updates to the Minister.

• Includes activities and projects approved via:

– Defence White Paper (DWP).

– Program update.

– Gate 1.

121


• Managed through Investment Committee (IC) and Defence Committee (DC).

• Spans all capability investment (over whole CLC):

– Major Capital Equipment.

– Enterprise ICT.

– Estate initiatives.

122

http://www.defence.gov.au/CIOG/Careers.asphttps://images.defence.gov.au/assets/archives (M113 Armoured Personnel Carrier & C17‐A RAAF Base Amberley)



©2020 ‐ 62 ‐

Portfolio: Managing Investment

• ‘Managing the Portfolio’ means balancing:

– prioritised strategic capability needs;

– resources; and

– risk.

123

Strategic needs

RiskResources

Managing Portfolio

Capability Streams

124

Portfolio

Program

Product / Project

Capability Stream



©2020 ‐ 63 ‐

Capability Streams

• Six Capability Streams taken from Defence White Paper.

• Helps communicate Defence priorities.

125

Six Capability Streams

Six Capability Streams

• ISREW*, Space and Cyber.

• Air and Sea Lift.

• Land Combat and Amphibious Warfare.

• Strike and Air Combat.

• Maritime and Anti‐Sub Warfare.

• Key Enablers.

126

* ISREW: Intelligence Surveillance, Reconnaissance, and Electronic Warfare




©2020 ‐ 64 ‐

CLC Capability Program Architecture: Five Domains

• Maritime (CN)

• Land (CA)

• Air (CAF)

• Space (CAF)

• Information and Cyber (CJC)

127

Source: Defence CLC Manual V1.0 2020

CLC Capability Streams 128

Defence Capability Portfolio

ISREW, Space and Cyber

Air and Sea Lift Land Combat

and Amphibious Warfare.

Strike and Air Combat.

Maritime and Anti‐Sub Warfare.

Key Enablers.



©2020 ‐ 65 ‐

Capability Streams

• Used for:

– Structuring the IIP;

– Seeking innovation proposals (Defence Innovation Hub);

– Defence Industrial Capability Plan; and

– Australian industrial strategies (from mid‐2019).

129

CLC Programs

130

Portfolio

Program

Product / Project

Capability Stream



©2020 ‐ 66 ‐

CLC Programs

• CLC introduced Programs.

• Programs deliver capability outcomes.

• Multiple Programs in each Capability Stream.

– Currently 40 Programs in Portfolio.

– Number will change.

• Programs made up of Projects and Products.

131

Capability Stream to Programs Matrix 132

Source: Interim CLC Manual

Capability Streams (to prioritise over multiple domains)

Cap

abili

ty M

anag

er D

omai

ns


Air & Sea Lift Land Combat & Amphib Warfare

Strike & Air Combat Maritime & Anti-Sub Warfare

Key Enablers

Chief Joint Capabilities


Assoc Secretary *

Chief of NavyChief of Army Chief of Air ForceChief of Air Force


Chief of Navy

Chief of Army

Chief of Air Force

DepSec SPI

Joint Integration

Maritime

Land

Air & Space

Intelligence & Cyber

C4I and Joint BattleManagement Systems

Joint ISR and EW

Warfighting Innovation(inc Cyber)

Asymmetric Response

Maritime Tactical C4I

Land ISREW

Land C3

Air and Space Awareness

Strategic Intelligence

Strategic Cyber

Geospatial Information and Intelligence

Battlefield Aviation

Sea Lift Amphibious Combat

Maritime Patrol andResponse

Major Surface Combatants

Submarines

Naval Aviation

Maritime Logistics

Minor Combatants

Health Services

Fuel

Explosive Ordnance

Training Support andSimulation

Maritime Infrastructure

and Ranges

Combat Service Support

Systems

Base Operations

Aircrew Training

Airborne Electronic Attack

Integrated Air and Missile

Defence

Air Combat

Combat Vehicles

Soldier Systems

Non-combat Vehicles

Combat Support

Special Operations

Air Mobility

* Associate S

ecretary plays a CM

-like role for 3 corporate enabler Program

s:In

frastructu

re&

Estate / E

nterp

rise ICT

/ W

orkfo

rce



©2020 ‐ 67 ‐

CLC Programs133


Sea Lift

Air Mobility


Submarines

Naval Aviation

Maritime Logistics

Minor Combatants

Portfolio

Programs

Capability Streams







Key Enablers.

Domain and Capability Programs 134

Maritime (CN) Land (CA) Air (CAF)Space (CAF)

Information & Cyber (CJC)

CJC Guided Weapons & EO, Joint C4, Joint Logistics, Joint ISR, Defence Training Areas & Sim, Joint EW. Space Services Joint Cyber

CN

Undersea Combat and SurveillanceSurface and Above Water CombatMaritime C5ISREWMaritime Combat Support and AmphibiousMaritime Mine Warfare, Patrol and Geospatial

CA

Land ISREWDismounted Combat Land C4Special OperationsLand Mobility and Support Land Combat VehiclesLand Combat SupportBattlefield Aviation

CAF

Air ISREWAir Mobility Combat Air SupportAir CombatMaritime Patrol & ResponseIAMD

Space Control

VCDF Asymmetric and Advanced Warfighting

Assoc Sec

Defence Business Enterprise Architecture and Transformation

DGASD Strategic Intelligence and Cyber

SP&I Geospatial Information and Intelligence

CIOG Enterprise ICT

E&IG Enterprise Estate and Infrastructure

CDS Innovation and S&T

Domains

Capability M

anagers

Source: CLC Manual V 1.0 Jan 2020



©2020 ‐ 68 ‐

Domain and Capability Programs 135




CN


CA


CAF


Space Control


Assoc Sec




CIOG Enterprise ICT



Domains

Capability M

anagers


Multi‐Domain Capability Programs 136




CN


CA


CAF


Space Control


Assoc Sec




CIOG Enterprise ICT



Domains

Capability M

anagers




©2020 ‐ 69 ‐

Program

Program is made up of Products, Projects, and Activities which:

– deliver a capability outcome,

– have relationships, and

– likely need to be synchronised or coordinated.

137

CLC and Programs138




Disposal

One system…

CLC: usually shown for one system/project.



©2020 ‐ 70 ‐

CLC and Programs139




One system…

Several systems…

CLC and Programs140




System 1

System 2

System 3

System 4

One system…

Several systems…







Acquisition Risk Mitigation and Requirements Setting







©2020 ‐ 71 ‐

CLC and Programs141




System 1

System 2

System 3

System 4

One system…

Several related systems…












CLC and Programs142

Program




System 1

System 2

System 3

System 4

One system…















©2020 ‐ 72 ‐

CLC and Programs143

Program




System 1

System 2

System 3

System 4

One system…













Program: Delivers Capability over Time(enduring capability from multiple systems)

144

Current System

2019 2025 2030

System 1

System 2

System 3

System 4

System 1

+

System 2

+

+

+

Technology Obsolescence and replacement

System 3

System 2

System 6

+

Required Capability ‘level’ delivered by several systems

+

System 2

System 6

+System 7

Respond to threat changes

2035



©2020 ‐ 73 ‐

Program: Delivers Capability over Time(enduring capability from multiple systems)

145

Current System

2019 2025 2030

System 1

System 2

System 3

System 4

System 1

+

System 2

+

+

+


System 3

System 2

System 6

+


+

System 2

System 6

+System 7


2035

Project

Project

Program: Lifestyle ‘Capability’ over Time (housing, transport, recreation)

146

2019 2025 2030

2 BR Apartment

3 BR House

Carport

+

Car: 4 cyl Hatch

+

+

+

Changing circumstances, Technology changes, Obsolescence and replacement

4 BR House

6 car garage

Car 4WD

+

Required lifestyle ‘capability’ : aspirations…

+Car: Electric

Townhouse

2035

2 BR Apartment

+

Solar incl car charging/ battery

Car: 4 cyl Hatch



©2020 ‐ 74 ‐

Program Features

• A Program is:

– a group of related Projects, Products and activities;

– an enduring capability outcome;

– supports joint capability outcomes;

– managed by a Program Sponsor; and

– helps optimise capability outcomes within resources.

147

CLC Products and Projects

148

Portfolio

Program

Product / Project

Capability Stream



©2020 ‐ 75 ‐

Asset Management Life Cycle 149



Retirement/Disposal

Asset Management

Task 1Task 2

Task 3

CLC Product Life Cycle 150




Disposal



Retirement/Disposal

CLC

Asset Management



©2020 ‐ 76 ‐

CLC Product Life Cycle 151




Disposal



Retirement/Disposal

CLC

Asset Management

Product life cycle

CLC Product Life Cycle

• Product:

– Capability system (platform, equipment, commodity).

– Includes all Fundamental Inputs to Capability (FIC).

– Whole of life cycle (concept to disposal).

– Delivers capability effect.

152




Disposal

Product life cycle



©2020 ‐ 77 ‐

Project

A Project is:

• A temporary, multidisciplinary and organised endeavour to create a unique product, service or result.

153




Disposal

Product life cycle

Project life cycle

CLC Project

A CLC Project is:

• The means by which a Product/s are delivered.

• Project delivers all (FIC).

• Requires Integrated Project Management.

• Part of a Program.

154

Project life cycle

AcquisitionStrategy and Concepts



Product life cycle



©2020 ‐ 78 ‐

CLC Programs155

Air Mobility

Products/Projects



Sea Lift

Air Mobility


Submarines

Naval Aviation

Maritime Logistics

Minor Combatants

Portfolio

Programs

Capability Streams







Key Enablers.

Portfolio/Program/Product/Project 156

Activity: eg preparedness analysis Activity: eg modelling

Program

Portfolio Capability Streams

AcquisitionStrategy and Concepts Risk Mitigation and


Disposal

Project

Product












©2020 ‐ 79 ‐



Program

Portfolio



Disposal

Project

Product










Domains



Program

Portfolio



Disposal

Project

Product










Domains

Programs:• Similar outcomes• Multi‐domain (MDPs)



©2020 ‐ 80 ‐

Summary

The four CLC management layers.

159

Portfolio

Program

Product / Project

Capability Stream

Summary

The new CLC Capability Program Architecture layers comprise:

160

Domains (5)

Multi-Domain Programs (12)

Product / Project

Capability Programs (35)

Portfolio



©2020 ‐ 81 ‐

Roles in the CLC

CLC Leadership

Two types of CLC leadership:

1. Governance of the CLC Policy and Process:

– VCDF: CLC Policy

– Associate Secretary: Contestability.

– DEPSEC CASG: Smart Buyer.

2. Implementing the CLC:

– As per CLC Accountability Model.

162



©2020 ‐ 82 ‐

CLC Accountability Model 163

Defence Committee

Investment Committee

Capability Manager

Program Sponsor

Project/Product Sponsor

Government

Delivery Group Head

Program Manager

Integrated Project/Product

Manager

Industry Representative

FIC SMEAcquisition or

Asset Mgt Specialist

Government Submission

SME

Requirements SME

Contestability

IPT

IPT: Integrated Project/Product TeamSME: Subject Matter Expert FIC: Fundamental Input to Capability

Joint Team

Enablers

Delivery Group

Strategy Policy Intelligence

Sponsor

Partnership

Partnership


Accountability: Meaning

• An accountable person:

• ultimately answerable for the correct and thorough completion of the task, deliverable or outcome.

• A person is held accountable and is accountable to someone.

• Accountability cannot be delegated.

164



©2020 ‐ 83 ‐

CLC Accountability Model

• Customer and Supplier ‘sides’.

• Integrated teams drawn from both ‘sides’.

• Partnerships are key.

165

Customer Supplier

Defence Committee


Capability Manager

Program Sponsor


Government

Delivery Group Head

Program Manager


Manager





SME

Requirements SME

Co

ntesta

bility

IPT


Joint Team

Enablers

Delivery Group


Sponsor

Partnership

Partnership

Customer



©2020 ‐ 84 ‐

Customer: Defence Committees

Defence Committee (DC):

– Chaired by Secretary.

– Primary decision committee for Defence.

Investment Committee:

– Chaired by VCDF.

– Supports DC on capability investment.

Enterprise Business Committee:

– Chaired by Associate Secretary.

– Ensures effective running of Defence.

– In‐year sustainment allocations for capability systems that are in‐service.

167

Defence Committee


Capability Manager

Program Sponsor


Government

Investment Committee (IC)

• Subsidiary of Defence Committee.

• Ensures resourcing consistent with Defence’s strategic priorities.

• Makes Gate 0 decisions for majority of proposals.

• Oversees implementation and integrity of IIP.

• VCDF (Chair):

– Assoc Sec,

– CJC,

– DEPSEC SP&I,

– CFO,

– CN, CA, CAF,

168

Government

Defence Committee


Capability Manager

Program Sponsor


– DEPSEC CAS, CDS,

– FAS Contestability,

– Central Agencies (Finance, PM&C).



©2020 ‐ 85 ‐

Capability Managers (CM)

• Accountable to:

– raise, train and sustain capabilities as directed by Secretary and CDF; and

– Secretary and CDF, through the IC, for management of their Programs.

• Accountable for (inter alia):

– Appropriate allocation of resources.

– Setting and managing requirements incl FIC.

– Execution of budgets and financial delegations for relevant Program activities.

169

Government

Defence Committee


Capability Manager

Program Sponsor


Capability Managers (CM)

• CMs are:

– Chief Joint Capabilities: Joint Integration

– DEPSEC Strategic Policy and Intelligence: Intelligence and Cyber.

– Chief of Navy: Maritime.

– Chief of Army: Land.

– Chief of Air Force: Air and Space.

– Chief Joint Capabilities/ Associate Sec: Key Enablers.

170

Government

Defence Committee


Capability Manager

Program Sponsor




©2020 ‐ 86 ‐

Capability Manager (CM)

• Develops the capability needs as tasked by VCDF.

• Sponsors Gate proposals to the Investment Committee

• Makes funding available to Delivery Groups.

171

Capability Stream to Program Matrix 172


Capability Streams (to prioritise over multiple domains)

Cap

abili

ty M

anag

er D

omai

ns


Air & Sea Lift Land Combat & Amphib Warfare

Strike & Air Combat Maritime & Anti-Sub Warfare

Key Enablers



Assoc Secretary *

Chief of NavyChief of Army Chief of Air ForceChief of Air Force


Chief of Navy

Chief of Army

Chief of Air Force

DepSec SPI

Joint Integration

Maritime

Land

Air & Space

Intelligence & Cyber

C4I and Joint BattleManagement Systems

Joint ISR and EW

Warfighting Innovation(inc Cyber)

Asymmetric Response

Maritime Tactical C4I

Land ISREW

Land C3

Air and Space Awareness

Strategic Intelligence

Strategic Cyber

Geospatial Information and Intelligence


Sea Lift Amphibious Combat

Maritime Patrol andResponse


Submarines

Naval Aviation

Maritime Logistics

Minor Combatants

Health Services

Fuel

Explosive Ordnance

Training Support andSimulation

Maritime Infrastructureand Ranges

Combat Service Support

Systems

Base Operations

Aircrew Training

Airborne Electronic Attack

Integrated Air and MissileDefence

Air Combat

Combat Vehicles

Soldier Systems

Non-combat Vehicles

Combat Support

Special Operations

Air Mobility

* Associate S

ecretary plays a CM

-like role for 3 corporate enabler Program

s:In

frastructu

re & E

state / En

terprise IC

T /

Wo

rkforce



©2020 ‐ 87 ‐

Program Sponsor

• Accountable to the Capability Manager.


– managing Programs;

– delivering within resources;

– Program aligning with strategic objectives;

– developing JCNS, Program Strategy;

– Project and Product outcomes;

– ensuring all I2 directives identified and managed;

– leading Test & Evaluation; and

– capability performance, availability, readinessand preparedness.

173

Government

Defence Committee


Capability Manager

Program Sponsor



Project Sponsor

• Accountable to Capability Manager and Program Sponsor for delivery of the Product. *


– development of capability needs incl FIC and I2;

– Business Case;

– setting direction for the Project; and

– approving the overall risk profile.

174

Government

Defence Committee


Capability Manager

Program Sponsor


* Para 7.11 Interim CLC Manual



©2020 ‐ 88 ‐


• Product Sponsor is accountable to CM and Program Sponsor for:

– Product outcomes; and

– preparedness levels in alignment with strategic priorities.*

175

Government

Defence Committee


Capability Manager

Program Sponsor


* Interim CLC Manual, p. 92.

Supplier



©2020 ‐ 89 ‐

Delivery Groups

• Support Capability Manager (CM).

• Develops Project Execution Strategy (PES).

• Conduct Independent Assurance Reviews (IAR).

• Coordinate early Industry involvement.

• Execute Integrated Project Management Plan (IPMP).

• Sustain and dispose capability as directed and resourced by CM.

177

Delivery Group Head

Program Manager


Manager

Delivery Groups

• Includes:

– CASG (materiel);

– CIOG (ICT);

– SP&I (classified projects); and

– E&IG (facilities).

178

Delivery Group Head

Program Manager


Manager



©2020 ‐ 90 ‐

Program Manager

• Appointed in Delivery or Enabler Group.

• Pivotal to:

– coordinating related Projects, Products, activities; and

– optimisation of available resources.

• Program Management related policies and practices under development.

179

Delivery Group Head

Program Manager


Manager

Integrated Project Manager (IPM)

• Responsible to plan and deliver the Project:

– inclusive of all agreed FIC; and

– to specified:

• scope,

• schedule, and

• budget.

• Coordinate delivery and integration of FIC and other enabler elements.

180

Delivery Group Head

Program Manager


Manager



©2020 ‐ 91 ‐

Integrated Product Manager

• Responsible (to SPO Director and Product Sponsor) to:

– ensure all FIC identified and available to sustain the Product;

– plan and coordinate inputs from FIC providers including industry; and

– coordinate development, management of delivery agreement including the Product Schedule.

181

Delivery Group Head

Program Manager


Manager

Contestability Division

• Independent assurance to VCDF, Secretary, CDF, Central Agencies, Ministers and Government.

• Ensures Defence’s capability needs aligned with strategy and resources.

• Ensures proposals can be delivered.

182

Defence Committee


Capability Manager

Program Sponsor


Delivery Group Head

Program Manager


Manager

Partnership

Contestability

Partnership



©2020 ‐ 92 ‐

Enabler Groups

• Accountable for providing assets and resources to IPT.

• Deliver and manage FIC and enabler components:

– coordinated by the Delivery Group (lead);

– IAW the Integrated Project Management Plan (IPMP).

• Contribute to:

– CM’s Program strategies, and

– Project planning.

183

Defence Committee


Capability Manager

Program Sponsor


Government

Delivery Group Head

Program Manager


Manager




Government Submission SME

Requirements SME

Partnership

Co

nte

stab

ility

IPT


Partnership

Joint Team Enablers

Delivery Group


Sponsor

Integrated Project/ Product Teams

• In both Project and Product cases:

– customer and supplier sides share a partnership; and

– comprise representatives from all relevant stakeholders.

184



Manager





SME

Requirements SME

IPT/ IPdT



©2020 ‐ 93 ‐

Integrated Project/ Product Teams

• IPT: manage Project functions to end of Acquisition Phase.

• IPdT: established before end of Acquisition Phase, as appropriate, to commence Product Management activities.

185



Disposal

Project life cycle

Product life cycle

Initial IPT established

IPdT established(in this period)

IPT closed

IPdT closed

Summary of CLC Accountability Model

• Partnerships and close coordination are core.

• Program Sponsor and Program Manager relationship is integral especially for realising joint capability.

• Integrated Project/Product Teams comprise representatives from relevant Defence stakeholders and Industry.

• IPM coordinates delivery and integration of FIC

• IPdM coordinates ongoing delivery of FIC.

186



©2020 ‐ 94 ‐

Summary of CLC Accountability Model

• Customer and Supplier ‘sides’.

• Integrated teams drawn from both ‘sides’.

• Partnerships are key.

187

Customer Supplier

Defence Committee


Capability Manager

Program Sponsor


Government

Delivery Group Head

Program Manager


Manager





SME

Requirements SME

Co

ntesta

bility

IPT


Joint Team

Enablers

Delivery Group


Sponsor

Partnership

Partnership

Force Design Framework



©2020 ‐ 95 ‐





Disposal

Gate 0 Gate 2Gate 1

ApprovalsIC

Approval

IC, Government

Approval




Contestability

Activities

Smart Buyer

CM Needs




Smart Buyer


PFPS*

POCD*

PES 1JCNSJCN

FPS*

OCD*PES 2

IPMP

PES 3Reduced Risk

Sub

mis

sion

App

rova

l &

Dire

ctio

n

Sub

mis

sion

Project Activities

IMS

Sub

mis

sion

Product Activities

Contract Docs

IPMP

PDA/MAA

Contract Docs

IPdMP




Project Management


App

rova

l &

Dire

ctio

n

App

rova

l &

Dire

ctio

n


ffer

Acc

epta

nce

App

rova

l

Force Design Framework190

Force DesignFramework(DCAP)




Gate 0 Gate 2Gate 1



©2020 ‐ 96 ‐

Force Design Framework191

Force DesignFramework(DCAP)




Gate 0 Gate 2Gate 1

Defence Capability Assessment Program (DCAP)

• ‘front‐end’ to the CLC;

• core function of Strategy and Concepts phase;

• identifies capability needs; and

• ‘joint force by design’ is key.

DCAP192

• DCAP outcomes:

– prioritised investment recommendations;

– traceable to strategic guidance; and

– potential inclusion in Integrated Investment Program (IIP).



©2020 ‐ 97 ‐

DCAP: Annual Cycle193

Often shown as annual program of activities supporting the Force Design Cycle.

Determine Gaps and Opportunities

Prioritise and identify possible options

Recommend response

Approve recommended response

Assess current force

DCAP: Modes of Operation

• Annual:

– gaps and opportunities

– inputs from:

• Force Design analyses, and

• Capability Managers.

• Agile: rapid assessment and resolution inside annual cycle:

• urgent operational requirement, and

• Government direction.

• Fundamental: approximately every four years as basis of Force Design Update.

194



©2020 ‐ 98 ‐

Fundamental Mode

• Addresses gaps and opportunities in greater depth.

• Provides options for fundamental change to force structure.

• Basis for:

– review of force structure,

– update to strategic guidance,

– Defence White Paper, and

– new Integrated Investment Program (IIP).

195

Smart Buyer Framework

Approvals Strategy

Asset Management

Strategy

Governance & Management

Strategy

Commercial Strategy

PES

JCNS

Needs

Strategic

Security

Technology

Industry Capability

Commercial

Financial

Schedule

Project, FIC Integration

Defence Integration



©2020 ‐ 99 ‐





Disposal

Gate 0 Gate 2Gate 1

ApprovalsIC

Approval

IC, Government

Approval




Contestability

Activities

Smart Buyer

CM Needs




Smart Buyer


PFPS*

POCD*

PES 1JCNSJCN

FPS*

OCD*PES 2

IPMP

PES 3Reduced Risk

Sub

mis

sion

App

rova

l &

Dire

ctio

n

Sub

mis

sion

Project Activities

IMS

Sub

mis

sion

Product Activities

Contract Docs

IPMP

PDA/MAA

Contract Docs

IPdMP




Project Management


App

rova

l &

Dire

ctio

n

App

rova

l &

Dire

ctio

n


ffer

Acc

epta

nce

App

rova

l

What is Smart Buyer?

• Decision‐making framework that helps :

– analyse circumstances for :

• capability gap or

• opportunity;

– determine how to best progress the capability need; and

– ensure strategy tailored to circumstances.

• Basis for the Project Execution Strategy (PES).

198



©2020 ‐ 100 ‐

What is Smart Buyer?

• Addresses:

– risks, opportunities and drivers;

– all relevant factors (technical, commercial, financial);

– whole of capability life cycle;

– total cost of ownership; and

– securing capability outcomes and value for money.

199

‘Drivers’ Categories• Acquisition

– Needs

– Strategic

– Security

– Technology

– Industry Capability

– Commercial

– Financial

– Schedule

– Project Internal Dependencies and FIC Integration

– Defence and Cross‐Program Integration

– Management and Governance

• Sustainment

– In‐Service Considerations

– Industry Capability

– Commercial

– Financial

– Support on Operations

– Product Dependencies and FIC Integration

200

For each Project/Proposal these are rated as: High, Medium-High, Medium-Low or Low.



©2020 ‐ 101 ‐

Smart Buyer: Main Steps

• Understand circumstances:

– such as capability need, strategic factors, industry capability, finance constraints.

• Identify drivers: ‘drivers profile’ (risk, opportunities).

• Develop a tailored strategy: PES based on four subordinate strategies …

• Approval Strategy.

• Asset Management Strategy.

• Governance and Management Strategy.

• Commercial Strategy.

201

PES: Tailored Strategy

• Approval Strategy:

– intended path to approval (two pass, one pass, NSC, Ministers), and the reasons for that decision.

• Authorities such as National Security Committee (NSC), One/Two Ministers.

• Pathway:– fast track from Gate 0 to Gate 2; and

– significant risk reduction studies Gate 0 to Gate 1. • Asset Management Strategy

– FIC Management.

– Capability Relevance.

– System(s) Maintenance, Changes and Tech Regulation.

202



©2020 ‐ 102 ‐


• Governance and Management Strategy

– Single or Multi‐layer Governance

– Change Management

– Communications Strategies

– PMO (Program/Project) Structure and Approach

• Commercial Strategy

– Business Intelligence

– Relationships

– Strategic Agreements

– Contractual Provisions.

203

Smart Buyer Workshops

• Core to Smart Buyer are structured workshops:

1. Risk and drivers analysis.

2. Tailored strategy development.

• Uses CASG Independent Assurance Review (IAR) team.

• Develops a tailored approach captured in the PES.

• First Smart Buyer workshop conducted prior to Gate 0.

204



©2020 ‐ 103 ‐

Smart Buyer – Implementation Steps

• Process steps (scalable):

– Kick‐Off meeting (1.5 hrs).

– Risk and Drivers workshop (1 day).

– Strategy Development workshop (1 day).

– Project team drafts the PES.

– Red Team Review (1.5 hrs).

– Approval by Delivery Group Division or Branch Head.

• Facilitated and supported using members of the CASG IAR team who are independent and possess significant experience.

205

Source: Smart Buyer Kick-off Meeting Pack

Strategy and Concepts Phase: Lead‐times to G0206

Source: Smart Buyer presentation pack June 2018



©2020 ‐ 104 ‐

Smart Buyer: Flexible Application

• Smart Buyer method can be used across the CLC:

• analysis, and

• strategy development.

• Smart Buyer can be applied for different purposes:

– early definition of a Project—that is, pre‐Gate 0;

– during the In‐Service and Disposal Phase;

• changes to sustainment activities; or

• upgrade Projects within the In‐Service Phase.

207

Smart Buyer Framework208

Approvals Strategy

Asset Management

Strategy


Strategy

Commercial Strategy

PES

JCNS

Drivers Profile Analysis/Tailoring Capability Need

Strategy

Needs

Strategic

Security

Technology

Industry Capability

Commercial

Financial

Schedule


Defence Integration



©2020 ‐ 105 ‐

Summary

The Smart Buyer framework.

• Decision‐making framework that helps:

– analyse circumstances for capability gap or opportunity identified through DCAP;

– define how to best progress the capability need;

– Determines how to best progress the capability need; and

– ensures strategy tailored to circumstances.

• Explicitly addresses:

– risks, opportunities and drivers;

– all relevant factors (technical, commercial, financial);

– whole of capability life cycle; and

– securing required capability outcomes and value for money.

• Develops the Project Execution Strategy (PES).

209

Contestability Framework



©2020 ‐ 106 ‐





Disposal

Gate 0 Gate 2Gate 1

ApprovalsIC

Approval

IC, Government

Approval




Contestability

Activities

Smart Buyer

CM Needs




Smart Buyer


PFPS*

POCD*

PES 1JCNSJCN

FPS*

OCD*PES 2

IPMP

PES 3Reduced Risk

Sub

mis

sion

App

rova

l &

Dire

ctio

n

Sub

mis

sion

Project Activities

IMS

Sub

mis

sion

Product Activities

Contract Docs

IPMP

PDA/MAA

Contract Docs

IPdMP




Project Management


App

rova

l &

Dire

ctio

n

App

rova

l &

Dire

ctio

n


ffer

Acc

epta

nce

App

rova

l


• Key assurance function.

• Function complements the behaviours

• Function performed by Contestability Division.

• Contestability Division structure: environmental domains.

212



©2020 ‐ 107 ‐

Contestability across the CLC

• Assesses:

– Force Design outputs.

– Key CLC artefacts such as Joint Concepts, CPN, JCNS.

– Gates or other major decisions/approvals.

– Programs as they change strategy.

– Changes to Sustainment Strategies.

– Contract renewals.

213

Strategic

Product

Strategy and Concepts

Risk Mitigation and Requirement

SettingAcquisition

In‐service and Disposal

Contestability

Project


• Contestability checks:

– alignment with:

• strategic capability and

• resource guidance;

– acceptable basis for decision‐making;

– plans can be executed;

– risk assessments and treatment strategies appropriate; and

– cost and schedule estimates are acceptable.

214



©2020 ‐ 108 ‐

Contestability

• Is this the right thing to do?

• Will we receive the outcome we expect?

• Have things been done right?

215

Strategic

Product



SettingAcquisition


Contestability

Project

Benefits of Contestability

• Makes submissions robust.

• Helps improve decisions (not make them).

• Checks key content:

– needs statement before Smart Buyer workshops; and

– needs and strategy before Gates.

• Trust with Government and Central Agencies.

• Supports a strengthened Defence strategic centre.

216



©2020 ‐ 109 ‐

Contestability Model across the CLC217

• Current focus on Gate considerations

• Will be conducted across CLC

Source: Department of Defence

Summary

The role of Contestability.

Key assurance function used to assess:

• Force Design outputs.

• Key artefacts.

• Gates and other major decisions.

• Changes to Strategies and Contracts.

Benefits:

• Makes submissions robust.

• Helps improve decisions (not make them).

• Checks key content:

• Helps establish and maintain trust with Government and Central Agencies.

• Supports a strengthened Defence strategic centre.

218

Strategic

Product



SettingAcquisition


Contestability

Project



©2020 ‐ 110 ‐

CLC Funding Framework


• Single integrated program: all investment needed to deliver and sustain Australia’s defence capabilities.

• Includes equipment, infrastructure, ICT, science and technology, and workforce.

220



©2020 ‐ 111 ‐

Capability Development Investment Fund (CDIF)

• Funding line in IIP.

• Governance principles for access and management of CDIF.

• Primarily for:

– high‐level strategy development and

– early risk reduction activities for current & future IIP Programs and Projects.

• Allocation:

– Up to Gate 0 Program level CDIF allocated annually to CMs by IC.

– Post Gate 0 CDIF allocated by IC on case‐by‐case basis.

• CMs bid (Oct) for pre‐Gate 0 Program CDIF for coming FY.

221

Capability Development Investment Fund (CDIF)

• CDIF is for:

– early investigation activities to identify and research options;

– development of PES and Gate 0 Business Case;

– Smart Buyer workshops; and

– concept demonstrators.

• Early access to IIP funding should be sought before CDIF.

• Where IIP funding not available, additional CDIF can be requested.

• Consult with IPMB to discuss optimal funding mix between CDIF and early access to IIP provision.

222



©2020 ‐ 112 ‐

Frameworks to Understand Components of Capability

Capability Perspectives 224

Support System: SSCC

Mission System

FIC

• Personnel • Organisation• Collective Training• Supplies• Major Systems• Facilities • Support • Command and

Management • Industry

• Operating Support• Engineering Support • Maintenance Support • Supply Support • Training Support

• Australian Industry• ADO• Overseas Industry• Allies/Partners

Sources of SupplyCapabilitySystem

• truck• radar• ship



©2020 ‐ 113 ‐

Preparedness Force Structure

Force elements capable of delivering specific

effects and countering threats

Maintaining the force structure at an appropriate state of

preparedness for a range of potential operations

Defence Capability 225

Readiness Sustainability

Being ready to deploy on

military operations.

Being able to continue operating

Deploy and Operate Force Element

Defence Capability System 226

(Sustain, In-Service)



©2020 ‐ 114 ‐



Mission System Support System

Supporting it In‐ServiceEquipment

Mission and Support Systems



©2020 ‐ 115 ‐

Mission and Support System Perspective229

Capability System


Used to focus on bringing the system into being

(equipment and its use)

What is needed to support it during the In‐service Phase

Fundamental Inputs to Capability (FIC)



©2020 ‐ 116 ‐

Defence Capability

• Capacity or ability to achieve an operational effect.

• Operational effect relies on a combination of contributions or inputs:

– Fundamental Inputs to Capability,

– not just the equipment, and

– all inputs must be in place to deliver operational effect.

• A deficiency in any one adversely impacts the whole.

231

Fundamental Inputs to Capability (FIC)232

Organisation

Command and Management

SupportFacilities

PersonnelCollective Training

Major Systems

Industry

Supplies

Capability (System)

Comprehensive, Structured



©2020 ‐ 117 ‐


• Framework enables:

– comprehensive analysis and planning of capability;

– consideration of all inputs; and

– focus on combination and integration of inputs (not individual inputs separately).

• Makes sure nothing is forgotten for operational effect.

• Everything for the capability is covered to ensure continued and assured lethality and preparedness.

233

Source: http://www.defence.gov.au/publications/docs/Capability‐Life‐Cycle‐Detailed‐Design.pdf


• Organisation: capability employed within functional groupings with appropriate balance of competency, structure, and command and control.

• Command and Management: effective command and management arrangements at all levels to safely and effectively employ the capability.

• Personnel: a competent workforce, including ADF, APS and contractors, for delivery, operation, sustainment and disposal of capability.

234




©2020 ‐ 118 ‐


• Collective Training: capability supported by a collective training regime.

• Major Systems: includes significant platforms, fleets of equipment and operating systems that enable the effective generation of Defence capabilities.

• Facilities and Training areas: infrastructure necessary to support the delivery, sustainment and operation of a capability system, including training areas.

• Supplies: include managing all classes of supply to maintain a capability at the designated readiness state, including sustainment funding and fleet management.

235



• Support: engineering support; maintenance support; supply support; training support; packaging handling, storage and transportation; facilities; support and test equipment; personnel; technical data and computer support.

• Industry: consideration of the resilience and capacity of industry, such as the reliability and health of supply chains.

236




©2020 ‐ 119 ‐

Summary

The nine Fundamental Inputs to Capability (FIC).

• Organisation.

• Command and Management.

• Personnel.

• Collective Training.

• Major Systems.

• Facilities and Training areas.

• Supplies.

• Support.

• Industry.

237

Support System Constituent Capabilities (SSCC)



©2020 ‐ 120 ‐

Support System Constituent Capabilities

• Defence groups support elements that comprise Support System through five functional categories:

– Operating Support.

– Engineering Support.

– Maintenance Support.

– Supply Support.

– Training Support.

239

SSCC Elements

1. Operating Support Capability.

– operating facilities system operators,

– support equipment,

– operator manuals and technical data,

– operating support procedures, and

– operating support information systems.

240



©2020 ‐ 121 ‐

SSCC Elements

2. Engineering Support Capability.

– engineering facilities,

– engineering personnel,

– engineering support and test equipment,

– engineering technical data,

– engineering processes,

– engineering information management system, and

– software support.

241

SSCC Elements

3. Maintenance Support Capability.

– develop, establish and integrate a maintenance support system capable of sustaining a system throughout its life

• maintenance facilities,

• maintenance personnel,

• maintenance support and test equipment,

• maintenance technical data,

• maintenance processes, and

• maintenance information management system.

242



©2020 ‐ 122 ‐

SSCC Elements

4. Supply Support Capability.

– supply facilities,

– supply personnel,

– supply support equipment,

– supply technical data,

– supply processes,

– supply information management system,

– spares, and

– packaging.

243

SSCC Elements

5. Training Support Capability.

– training facilities

– training personnel,

– training equipment,

– training materials and other technical data,

– training processes, and

– training information management system.

244



©2020 ‐ 123 ‐

Mission and Support System Perspective

Training for operators Training facilities …

Capability System


245

Maintenance GaragingSupplies (such as fuel)Spares…

Support System Perspective246

Capability System


Support System Constituent Capabilities (SSCC) framework helps break down Support requirements for in‐service phase.



©2020 ‐ 124 ‐


Capability System



Operating SupportEngineering Support Maintenance SupportSupply Support Training Support

FIC Perspective248


Capability System

Organisation

Command &Management

SupportFacilities


Major Systems

Industry

Supplies

Capability



©2020 ‐ 125 ‐


Organisation


SupportFacilities


Major Systems

Industry

Supplies

Capability (System)


Facilities

Training FacilitiesGaraging Facilities

Permanent Maintenance Facilities

Estate and Infrastructure Group (E&IG) organises

Deployable Mission System Facilities

CASG organises



©2020 ‐ 126 ‐

Supplier Perspective251

Capability System


Department of DefenceAustralian Industry Overseas Industry Other Defence organisations (such as US DoD)

Supplier Perspective252

Facilities

Training Facilities

Garaging Facilities

Permanent Maintenance Facilities

Department of Defence

Australian Industry

Overseas Industry

Deployable Mission System Facilities

Australian Industry



©2020 ‐ 127 ‐

Capability System253

Personnel

Collective Training

Facilities and Training Areas

Supplies

Support

Organisation


Industry

Operating Support

Engineering Support

Maintenance Support

Supply Support

Training Support

Mission System

Support System

Effect / Outcome

SSCC

FIC

(Materiel System)

Capability Perspectives

These structures help:

• ensure everything is covered;

• define requirements of the mission system and its support system;

• delineate what each party (CM, CASG, E&IG, CIO etc organises);

• define who supplies the different elements; and

• define elements for which industry is contracted.

254



©2020 ‐ 128 ‐

SummaryThe nine FIC.

• Organisation.

• Command and Management.

• Personnel.

• Collective Training.

• Major Systems.

• Facilities and Training areas.

• Supplies.

• Support.

• Industry.

The five SSCC.

• Operating Support.

• Engineering Support.

• Maintenance Support.

• Supply Support.

• Training Support

255

Joint Force by Design

CLC Principle: Joint and integrated capability outcomes



©2020 ‐ 129 ‐

CLC Process Overview: Your Process Map257




Disposal

Gate 0 Gate 2Gate 1

ApprovalsIC

Approval

IC, Government

Approval




Contestability

Activities

Smart Buyer

CM Needs




Smart Buyer


PFPS*

POCD*

PES 1JCNSJCN

FPS*

OCD*PES 2

IPMP

PES 3Reduced Risk

Sub

mis

sion

App

rova

l &

Dire

ctio

n

Sub

mis

sion

Project Activities

IMS

Sub

mis

sion

Product Activities

Contract Docs

IPMP

PDA/MAA

Contract Docs

IPdMP




Project Management


App

rova

l &

Dire

ctio

n

App

rova

l &

Dire

ctio

n


ffer

Acc

epta

nce

App

rova

l

I2 Framework (I2F)258

• Supports Joint Force outcomes:

– Integration between ADF force elements.

– Interoperability with Allies, Coalition, civil/government elements.

Source: Architecture Development as a Mission System Integrator, Steven J. Saunders Raytheon Australia, SETE 2008 Canberra



©2020 ‐ 130 ‐





Disposal

Gate 0 Gate 2Gate 1

ApprovalsIC

Approval

IC, Government

Approval




Contestability

Activities

Smart Buyer

CM Needs




Smart Buyer


PFPS*

POCD*

PES 1JCNSJCN

FPS*

OCD*PES 2

IPMP

PES 3Reduced Risk

Sub

mis

sion

App

rova

l &

Dire

ctio

n

Sub

mis

sion

Project Activities

IMS

Sub

mis

sion

Product Activities

Contract Docs

IPMP

PDA/MAA

Contract Docs

IPdMP




Project Management


App

rova

l &

Dire

ctio

n

App

rova

l &

Dire

ctio

n


ffer

Acc

epta

nce

App

rova

l

Joint Force by design… Integration and Interoperability outcomes

Integration and Interoperability Actions

• define interdependencies and interfaces between related systems;

• keep interfaces in ‘lock step’; and

• ensure system/interface changes are managed.

Information Exchange

Eg HF, VHF

IAMDAirborne Sensors

Joint Battle Management System Deployable

Ground Weapons

Mobile Ground Sensors

Eg Frigates

Airborne Relay

260



©2020 ‐ 131 ‐

What is Needed

• Single source of truth

• Authoritative reference:

– assigned authorities;

– overarching design (such as design patterns and standards); and

– ‘living’ information source and configuration controlled.

261

Inputs to Integration and Interoperability

• Australia’s Joint Operating Concept

• Integrating Operational Concept Document V2.1

• Capability Program Narrative (potentially replaced by Program Directives)

• Plan AURORA

• C4ISR Design Operational Design Patterns

• Joint Concepts

• Project OCDs/JCNS

• Whole of Government

• Allies

• Industry

262



©2020 ‐ 132 ‐

Assess Program compliance with I2 Reference Set Requirements

Assess Project compliance with I2 Reference Set Requirements

Assess ongoing in‐service I2 compliance of Products against approved I2 requirements

I2 Assurance, Approval

Joint Force Guidance STRATEGIC

&OPERATIONAL GUIDANCEEXTERNAL OBLIGATIONS AND

AGREEMENTSDCAP OUTCOMES

PROGRAM Drives Project/Product I2 requirements

PRODUCTProduct Baseline

I2 Implementation

AUTHORISED I2 REQUIREMENTS • Joint Force Outcomes • Supporting Joint Concepts• Integrating (I2) Objectives • Directed I2 requirements

I2 Reference Set

AUTHORISED REFERENCE DESIGNS

REQUIRED I2 PRACTICES:• Demonstrated Traceability • Use of SCMILE • Consultation • Established I2 Agreements• Tailored Assurance Pathways• Configuration Control of I2 info

Compliant with

Compliant with

C4ISR DESIGN STANDARDS

PROGRAM ARCHITECTURES

SYSTEM ARCHITECTURES

PRODUCT BASELINES

PROJECTDecide Project I2 requirements

Systems incl Interface Specifications

I2 Framework (I2F)263

C4ISR Design

• C4ISR Design Authority accountable for :

– defining and assuring the joint war‐fighting environment, architecture, and

– setting military I2 requirements.

• C4ISR Design 2025 v0.6 endorsed by Joint Warfare Council.

• Defines I2 for Networked Joint Force (NJF) C4ISR functions.

264



©2020 ‐ 133 ‐

Joint Force Integration Advice

• Change in names of organisation and I2 Framework.

• Force Integration Assurance (FIA) performs the previous role of Joint Force integration advice and assurance.

• Force Development and Validation (FDV) addresses strategic and operational levels of interoperability including:

– Plan AURORA;

– FIDAS; and

– Joint Capability Realisation System (JCRS) (previous known as I2F).

265

I2 is Addressed Across the CLC266



©2020 ‐ 134 ‐





Disposal

Gate 0 Gate 2Gate 1

ApprovalsIC

Approval

IC, Government

Approval




Contestability

Activities

Smart Buyer

CM Needs




Smart Buyer


PFPS*

POCD*

PES 1JCNSJCN

FPS*

OCD*PES 2

IPMP

PES 3Reduced Risk

Sub

mis

sion

App

rova

l &

Dire

ctio

n

Sub

mis

sion

Project Activities

IMS

Sub

mis

sion

Product Activities

Contract Docs

IPMP

PDA/MAA

Contract Docs

IPdMP


App

rova

l &

Dire

ctio

n

App

rova

l &

Dire

ctio

n

Off

er

Acc

epta

nce

App

rova

l

High Level I2 Needs

More specific I2 requirements

Solicitation‐ready I2

Requirements

Negotiation‐Ready I2

Requirements

Contracted I2 Requirements

I2 Design I2 T&E I2 Configuration Management

Integration and Interoperability

Procurement and Contracting Framework



©2020 ‐ 135 ‐





Disposal

Gate 0 Gate 2Gate 1

ApprovalsIC

Approval

IC, Government

Approval




Contestability

Activities

Smart Buyer

CM Needs




Smart Buyer


PFPS*

POCD*

PES 1JCNSJCN

FPS*

OCD*PES 2

IPMP

PES 3Reduced Risk

Sub

mis

sion

App

rova

l &

Dire

ctio

n

Sub

mis

sion

Project Activities

IMS

Sub

mis

sion

Product Activities

Contract Docs

IPMP

PDA/MAA

Contract Docs

IPdMP




Project Management


App

rova

l &

Dire

ctio

n

App

rova

l &

Dire

ctio

n


ffer

Acc

epta

nce

App

rova

l

CLC: Acquisition and Sustainment

• Key outcomes of CLC: acquire and sustain capability assets.

• Defence enters into contracts of $12 billion per annum.

• Good CLC outcomes depends on sound Procurement and contracting.

• Centres around:

– ‘Solicitation’ (requesting offers or tenders);

– Contracting; and

– Contract Management.

Source: Contract Template Selection and Tailoring Guide, Version 2.1 April 2016.

270



©2020 ‐ 136 ‐


• Major focus for CLC:

• Solicitation between Gates 1 and 2.

• Contract/s establishment (just after Gate 2).

• Contract management for Acquisition and Sustainment.

271




Gate 0 Gate 1 Gate 2

Solicitation &Source Selection

Contract Management

Contract Established

Contracting

Solicitation and Source Selection

• Form of risk mitigation:

– understanding possible solutions,

– narrowing options,

– choosing best solution, and

– defining contracted requirements.

272



©2020 ‐ 137 ‐

Procurement Life Cycle

• Planning

1. Plan the procurement.

2. Develop ‘Request documentation’ such as RFT.

• Sourcing

3. Approach the market.

4. Evaluation.

5. Negotiation and contract signature.

• Managing

6. Contract management.

7. Disposal.

273


Relationship to CLC

• CLC Solicitation and Contracting based on the ‘Procurement Life Cycle’.

• Understanding the Procurement Life Cycle is pivotal to deciding the best strategy in the PES for a major acquisition.

274







Contracting and Contract Management



©2020 ‐ 138 ‐

Relationship to CLC

• The Procurement Life Cycle can also be nested within the CLC for example, acquiring risk mitigation studies or other services.

275

Pla

nn

ing

So

urc

ing

Ma

na

gin

g

Risk Reduction

activity

Pla

nn

ing

So

urc

ing

Ma

na

gin

g

Upgrade activity





Why should I know about Proc & Contract?

• All involved in the CLC should know about procurement and contracting rules because, depending on their roles:

– Capability Manager and representatives are accountable;

– Delivery groups (such as CASG, CIOG) are responsible; and

– Enabler groups (such as E&IG) are responsible.

• Defence major capital, ICT and Facilities procurements under increasing scrutiny by:

– tenderers,

– ANAO,

– Senate Estimates and other Parliamentary Committees, and

– media.

276



©2020 ‐ 139 ‐





Disposal

Gate 0 Gate 2Gate 1

ApprovalsIC

Approval

IC, Government

Approval




Contestability

Activities

Smart Buyer

CM Needs




Smart Buyer


PFPS*

POCD*

PES 1JCNSJCN

FPS*

OCD*PES 2

IPMP

PES 3Reduced Risk

Sub

mis

sion

App

rova

l &

Dire

ctio

n

Sub

mis

sion

Project Activities

IMS

Sub

mis

sion

Product Activities

Contract Docs

IPMP

PDA/MAA

Contract Docs

IPdMP




Project Management


App

rova

l &

Dire

ctio

n

App

rova

l &

Dire

ctio

n


ffer

Acc

epta

nce

App

rova

l

Sound Requirements are Critical

• Sound Requirements are critical to:

– Solicitation

– Tender Evaluation and

– Contracting.

• Solicitation generally based on:

– Operational Concept Document (OCD) (as guidance) and

– Function and Performance Specification (FPS).

278



©2020 ‐ 140 ‐

Requirements Must be Traceable

• Requirements must always be traceable to government direction via CLC artefacts, such as:

– Program Integrating Operational Concept (PIOC).

– Joint Capability Narrative (JCN).

– Joint Capability Needs Statement (JCNS).

– Operational Concept Document (OCD).

279

Requirements Underpin Proc & Contracting

Sound Requirements underpin:

• What is to be acquired.

• Work to be done to achieve acquisition and sustainment outcomes.

• Basis for contract and estimates: work, cost, schedule.

• Confirming that deliverables are satisfactory.

280

Verification Cross

Reference Matrix



©2020 ‐ 141 ‐

Solicitation and Source Selection Documents 281

Defence Documents

ASDEFCON Suite including:

• Conditions of Tender.

• Conditions of Contract.

• SOW.

• OCD, FPS, TEMP.

• Data Item Descriptions (DIDs).

Tenderer Responses

Tender documents which detail the offer includes:

• Compliance Matrix.

• Specifications.

• Plans.

• Costs.

• Schedules.

Source Evaluation

•Tender Evaluation

•Source Evaluation Report

Must be robust and fully defendable

Risk Mitigation



©2020 ‐ 142 ‐

Risk Mitigation in the CLC283

Managing risk is an absolutely crucial part of the redesigned CLC.

“We often think that having a 6,000 line item risk register will solve all our problems; it doesn't. So where our focus is now on identifying the risk at that point of the life cycle that is appropriate, and then working out the controls, making sure those controls are effective and monitoring the outcomes. We really need to rethink what we think risk management is all about”.

VADM Ray Griggs, VCDF 2016

Risk in the Context of the CLC

• CLC‐related risk is that capability investment (Project) will fail:

– delivered capability will not meet the need,

– costs become unaffordable,

– will be too late to address capability gap,

– can’t be maintained, and

– unsafe.

• Impact is that Defence:

– capability is deficient, and

– taxpayer money is wasted.

284



©2020 ‐ 143 ‐

Risk Reduction Mindset and Actions

• Risk reduction needed so that:

– approvals to spend public monies:

• based on confidence, and

• are defendable; and

– less likelihood that the Project will fail.

285



Disposal

Risk Reduction

Risk ReductionForce

Design

Reducing level of risk as risky aspects are treated/

Risk Mitigation and Smart Buyer

Smart Buyer is a structured approach for this process:

1. Define risk and drivers categories for Project and Product.

2. Identify risk events and impacts (analysis, workshops).

3. Capture drivers profile:

– risk rating;

– ranking.

4. Plan risk reduction (PES and IPMP).

5. Get approval and funding for risk reduction work.

286



©2020 ‐ 144 ‐

Implementing Risk Mitigation287

Risk Reduction Studies(technical and

implementation risks) Further Requirements Definition

RFT + ODA(commercial risk)

Modelling and Simulation

Eg RFI(commercial risk)

System Reviews

Smart Buyer Risk

Profile

System Engineering Activities

Trade‐off studies

Trade‐off studies


Risk Mitigation andRequirements Setting

In‐Service andDisposal

Gate 0 Gate 2Gate 1

PES

Risk Reduction Activities


CLC Artefacts



©2020 ‐ 145 ‐





Disposal

Gate 0 Gate 2Gate 1

ApprovalsIC

Approval

IC, Government

Approval




Contestability

Activities

Smart Buyer

CM Needs




Smart Buyer


PFPS*

POCD*

PES 1JCNSJCN

FPS*

OCD*PES 2

IPMP

PES 3Reduced Risk

Sub

mis

sion

App

rova

l &

Dire

ctio

n

Sub

mis

sion

Project Activities

IMS

Sub

mis

sion

Product Activities

Contract Docs

IPMP

PDA/MAA

Contract Docs

IPdMP




Project Management


App

rova

l &

Dire

ctio

n

App

rova

l &

Dire

ctio

n


ffer

Acc

epta

nce

App

rova

l

CLC Artefacts / Documents

• The CLC process produces and uses numerous artefacts or documents to provide the basis for:

– Decision making;

– agreement on plans and actions; and

– provide evidence and a record for management and assurance.

• Generally of three types:

– Needs and Requirements.

– Strategy and Plans.

– Contracts and Agreements.

290

What and Why

How (and when)



©2020 ‐ 146 ‐

Artefacts Over the CLC291

Risk Reduction Studies

(technical, commercial risks)

Risk Reduction,

Requirements DefinitionOCD, FPS, TEMP

Solicitation RFT, SER

Requirements Definition

OCD, FPS, TEMP

Planning definition: IPMP, IMS

Contract Mgt Force Design: JCN Contract Mgt





Define Need:JCNS

Smart Buyer Risk

Profile and Strategy definition:

PES

SE Review

Risk Mgt

Assurance Reports

Risk and Assurance Mgt

Contesta‐bility

What and Why

How (and When)

The following is a structure which shows:

• Traceability to government direction

• Traceability between artefacts

• Different levels of artefacts reflecting the CLC Management Layers


Portfolio

Program

Product / Project

Capability Stream



©2020 ‐ 147 ‐


DWP

FOE FJOC

AMS

AJOC

What and Why How

PGPA Act

CPRs

Force Design

CPN

JCN

IIP

DIP

DPPM



PESJCNS

Smart Buyer

OCD

FPS

IPMPProjectWBS

IMS



DPG

JCFConcepts

Strategic Guidance


Portfolio

Program

Project

What and Why294

DWP

FOE FJOC

AMS

AJOC

What and Why How

PGPA Act

CPRs

Force Design

CPN

JCN

IIP

DIP

DPPM



PESJCNS

Smart Buyer

OCD

FPS

IPMPProjectWBS

IMS



DPG

JCFConcepts

Strategic Guidance


Portfolio

Program

Project



©2020 ‐ 148 ‐

How295

DWP

FOE FJOC

AMS

AJOC

What and Why How

PGPA Act

CPRs

Force Design

CPN

JCN

IIP

DIP

DPPM



PESJCNS

Smart Buyer

OCD

FPS

IPMPProjectWBS

IMS


DPG

JCFConcepts

Strategic Guidance


Portfolio

Program

Project


CLC Artefacts Divided into Two Levels

• Key CLC artefacts can be divided into two levels:

– Program for proposals or as common references for subordinate projects/products.

– Project/Product for proposals.

296



©2020 ‐ 149 ‐

Program‐level Artefacts297

DWP

FOE FJOC

AMS

AJOC

What and Why How

PGPA Act

CPRs

Force Design

CPN

JCN

IIP

DIP

DPPM



PESJCNS

Smart Buyer

OCD

FPS

IPMPProjectWBS

IMS


DPG

JCFConcepts

Strategic Guidance


Portfolio

Program

Project


Key Enablers for Program Management

• CPN and JCN: narratives on the expected operational effects of the group of capability systems.

• PIOC:more detailed description of operational relationships between capability systems both within the Program and with other Programs.

• Program Strategy: description of the activities, management arrangements, including integrated schedule across Projects and Products.

• ...

298



©2020 ‐ 150 ‐

Prior to CLC Redesign299

Defence Strategic and Operational GuidanceDWP, DPG, AMS, AJOC, FJOC

Project 1

FPSs

TCD

• Projects and their needs and requirements frequently:– un‐aligned and – not well coordinated (if

at all)

• Needs and Requirements development started at Project layer

Project 2 Product 3

FPSs

TCD

OCD 3

FPSs

TCD

OCD 1 OCD 2

Program Layer as ‘Umbrella’ Reference300


Program 1

Program Integrating Operational Concept (PIOC)

Program Strategy

Capability Program Narrative (CPN)

Project 1

FPSs

IPMP 1

JCNS 1

Project 2 Product 3

OCD 1

• Common ‘umbrella’ reference

• Aligning Project and Product requirements

• Supports integration and interoperability

• ‘Town Plan’

JCN 1

PES 1

FPSs

IPdMP

JCNS 3

OCD 3

JCN 3

PES 3

FPSs

IPMP 2

JCNS 2

OCD 2

JCN 2

PES 2

TCD 1 TCD 2 TCD 3



©2020 ‐ 151 ‐

Proposal‐level Artefacts301

DWP

FOE FJOC

AMS

AJOC

What and Why How

PGPA Act

CPRs

Force Design

CPN

JCN

IIP

DIP

DPPM



PESJCNS

Smart Buyer

OCD

FPS

IPMPProjectWBS

IMS


DPG

JCFConcepts

Strategic Guidance


Portfolio

Program

Project


Proposal Artefacts

• Proposal Artefacts at Project or Product level:



– Project Execution Strategy (PES).

– Business Case which supports Proposals and Submissions

– Integrated Project Management Plan (IPMP).

– Capability Definition Documents (CDD):

• Operational Concept Document (OCD).

• Function and Performance Specification (FPS).

• Test and Evaluation Master Plan (TEMP).

302



©2020 ‐ 152 ‐

CLC Tendering and Contracting Documents303

DWP

FOE FJOC

AMS

AJOC

What and Why How

PGPA Act

CPRs

Force Design

CPN

JCN

IIP

DIP

DPPM



PESJCNS

Smart Buyer

OCD

FPS

IPMPProjectWBS

IMS


DPG

JCFConcepts

Strategic Guidance


Portfolio

Program

Project


Sound Artefacts Essential to Good Capability

• Sound artefacts are needed for:

– CLC approvals

– Solicitation and contracting

– Contract management

– Handover to customer (Capability Manager)

– Maintaining capability

• Must be developed in a rigorous manner using proven Practices such as:

– Systems and Requirements Engineering.

– Program and Project Management structures and techniques.

– Procurement and Contracting methods.

304



©2020 ‐ 153 ‐

Artefacts

• We will go through the Artefacts in more detail on Day 3

305

Summary

The principal CLC proposal artefacts.

306



©2020 ‐ 154 ‐


Defence CLC Challenge308

Management of Public Resources

Accountability

Technical endeavour to deliver and support capability

Performance

Precision and rigour

Complexity

Governance/ Legal

Engineered systems

+

+Many Stakeholders



©2020 ‐ 155 ‐

CLC, Capability Development Context

• Context:

– Significant complexity, scale and cost.

– Interdependencies.

– Many stakeholders.

– High cost.

– Leading edge technologies.

– Changing environment.

309

Successful Capability Outcomes Depend on:

• Activities based on proven professional Practices:

– Beyond administrative organisational processes

– Adapted to Defence context

– Reflecting world’s best practice and

– Using proven methods and techniques

• Sound artefacts developed in a rigorous manner using proven Practices

310



©2020 ‐ 156 ‐

Capability Development Practices

• Developed by experts in each field.

• Based on best practice.

• Captured in:

– International and Australian standards; and

– Bodies of Knowledge (BoK).

• Proven techniques, methodologies.

• Flexible: can be tailored to specific circumstances.

311


• ‘Toolkit’ for implementing CLC.

• Core CLC Practices are:

– Program, Product and Project Management.

– Systems Engineering (SE).

– Integrated Logistics Support (ILS).


– Assurance and Risk Management.

• There are more, such as Financial Management.

• Each Practice provides a different ‘lens’ and role for capability developers.

312



©2020 ‐ 157 ‐

Practices: Level of Effort over CLC 313

Practices applied:

• throughout the CLC,

• at different levels of intensity and depth, and

• depending on the phase and the nature of the effort.




Practices: Level of Effort over CLC 314




Product Management Project Management

Systems Engineering


ILS

Assurance and Risk Management



©2020 ‐ 158 ‐

Capability Development Practices 315

Applied throughout the CLC at different levels of intensity and

depth depending on the phase and the nature of the effortAssurance and Risk Management

ILS


Systems Engineering

Program, Product and Project Management

Practices (‘Toolkit’)

Practices are applied throughout the CLC Process tailored to the CLC Phase and the nature of effort.




Capability Development Practices 316

Practices are not separate activities rather need to be managed as inter‐related streams of work throughout the CLC.






©2020 ‐ 159 ‐

Practices: Life Cycles317




Practices:

• Often described in terms of specific life cycles.

• Generic Practice life cycles can be adapted/ tailored.

Life‐cycle Views of CLC Practices 318





Acquisition Utilization RetirementPre-acquisition

System Engineering Life Cycle


Project Life Cycle

Sustainment Disposal

Te

rmin

ate

Product Life Cycle

Sourcing Planning Managing

ImplementDevelopConceive

Planning

Sourcing

Managing



©2020 ‐ 160 ‐


• The next sessions will take you through the Practices so you can see:

– what work is done during the CLC (ie Activities);

– how to define this work; and

– what is done to develop the Artefacts.

319





Disposal

Gate 0 Gate 2Gate 1

ApprovalsIC

Approval

IC, Government

Approval




Contestability

Activities

Smart Buyer

CM Needs




Smart Buyer


PFPS*

POCD*

PES 1JCNSJCN

FPS*

OCD*PES 2

IPMP

PES 3Reduced Risk

Sub

mis

sion

App

rova

l &

Dire

ctio

n

Sub

mis

sion

Project Activities

IMS

Sub

mis

sion

Product Activities

Contract Docs

IPMP

PDA/MAA

Contract Docs

IPdMP




Project Management


App

rova

l &

Dire

ctio

n

App

rova

l &

Dire

ctio

n

Contract Management

Off

er

Acc

epta

nce

App

rova

l



©2020 ‐ 161 ‐

Systems Engineering

Context

• Defence materiel or equipment is the result of highly sophisticated engineering effort:

– Leading‐edge technology

– novel adaptation of technology

– significant integration

– electronics‐based and software intensive

– particular focus on availability, redundancy, endurance, security, and safety

– integrates a range engineering disciplines such as mechanical, civil, electrical, aerospace.

• These systems must be defined, developed and supported through rigorous formalised methods.

322



©2020 ‐ 162 ‐

Systems Engineering

Systems Engineering is a technical management framework:

• integrates engineering disciplines

• provides proven structured processes

• enables development and control of a product including:

– requirements definition,

– design,

– verification and validation,

– maintenance and modification of a Product, and

– conduct of technical investigations, reviews

• addresses all life cycle considerations.

323

Systems Engineering and the CLC

Systems Engineering is valuable to the CLC and obligations of Defence officials:

• trusted method for deriving needs and requirements which are demonstrably traceable to approved guidance

• rigorous consideration of all feasible alternatives to select the best solution

• ensures holistic consideration of all factors

• provides structured assurance approach (e.g. System Review process)

• enables structured identification of system development and technical risks to target risk reduction.

324



©2020 ‐ 163 ‐

Use of the word ‘system’

• The word ‘system’ has many contexts:

– Physical systems such as solar systems, river systems, railway systems, satellite systems, communication systems, information systems, pulley systems, and nervous systems.

– Philosophical systems, social systems, religious systems, gambling systems, banking systems, and systems of government.

– More‐esoteric examples, such as the consideration of individual and social behaviour as a system of purposeful events.

325

Use of the Word ‘System’

• The common aspect of ‘system’ stems from its early use to refer to:

the whole (or the set) that results:

when a number of things have been grouped,

in a particular manner,

for a particular reason.

• So, what is a ‘system’ in the context of ‘systems engineering’?

326



©2020 ‐ 164 ‐

Definition of a System

• In systems engineering, ISO/IEC 15288 therefore defines a system as:

a combination of interacting elements organized to achieve one or more stated purposes*

* ISO/IEC 15288‐2015, Systems and Software Engineering—System Life Cycle Processes, 2015.

327


• So, a system comprises:

– system elements,

– interconnections (interactions) between elements, and

– an external system boundary.

System of interest(SOI)

System element

Interconnection/interaction

System boundary

328



©2020 ‐ 165 ‐


• Narrowing the definition of a system has two major implications:

– The systems elements, interconnections and boundary are not accidental but result from deliberate design (engineering).

– A system must be managerially and operationally independent (and may well have been procured independently).

329

A System and its Environment330

System of interest(SOI)

External element

System element

Interconnection/interaction

External Interface (input/output)

OperatingEnvironment

Boundary



©2020 ‐ 166 ‐

A System and its Environment331

System of interest

Widersystem of interest

Operating environment

Wider environment

System as a Product

• In a physical sense, the term system is sometimes considered to be synonymous with product—that is, we say that the project is delivering a system, or is delivering a product.

332

System

Operational products Enabling products

Testproduct

Trainingproduct

Disposalproduct

Developmentproduct

Deploymentproduct

Supportproduct

Productionproduct

Endproduct

ANSI/EIA‐632‐1998, Processes for Engineering a System, Washington, D.C.: Electronic Industries Association (EIA), 1999.



©2020 ‐ 167 ‐

A System as a Capability

• Systems are much more than an aggregation of hardware or software products and also include: organisation, personnel, collective training systems, facilities, data, support, and operating procedures and organisational policies.

• A system therefore delivers an operational capability, not just products.

333

Capability System

• It is common, therefore, particularly in defence environments, to refer to the system at this level as a capability system.

• Each of the elements of a capability system will probably have a different acquisition cycle, since each represents a different type of acquisition.

• Here we focus on the major equipment element so that the descriptions are less cluttered.

• We must remember, however, that all elements are acquired in parallel and must be brought back together prior to introduction into service in order to field an operational capability.

334



©2020 ‐ 168 ‐

Logical and Physical Descriptions

• A system can be described in two broad ways:

– Logical (or functional)—what the system will do, how well it will do it, how it will be tested, under what conditions it will perform, and what other systems will be involved with its operation.

– Physical—what the system elements are, how they look, and how they are to be manufactured, integrated, and tested.

• Both the logical and physical descriptions of a system comprise a series of statements called requirements.

335


• The two descriptions are valid independent descriptions of a system:

– We develop the logical description first.

– How we implement current physical systems should not colour unnecessarily the way in which we might describe future systems.

– Upper‐level trade‐offs and feasibility analyses must be conducted at the logical level before deciding on the physical implementation.

– A logical description is ideally suited to the interface between systems engineering and the business case.

– The logical description changes slowly; the physical description changes much faster.

336



©2020 ‐ 169 ‐


• In the development of a system, therefore, there are at least two architectural views: a system logical architecture, and a system physical architecture.

• Of course, these two descriptions are of the same system so they must be related.

• We will see later how the logical architecture, as outlined in the requirements breakdown structure (RBS), is mapped onto the physical architecture as represented by the configuration items contained in the work breakdown structure (WBS).

337

System

SystemElement

SystemElement

SystemElement

A system

comprises

a set of interacting

system elements

Hierarchical descriptions of a system

• We can consider the system to be a hierarchical composition of system elements (either logical or physical).

338



©2020 ‐ 170 ‐

Mission

Function1

Function2

Function1.1

Function1.2

Function1.3

Function2.1

Function2.1

Logical (Functional) Hierarchy

• In a logical description of a system, the system’s mission is broken down into a hierarchical structure of its major functions—to form a functional hierarchy, or a functional architecture.

339

Physical Hierarchy

• We use a simple four‐layer representation (system, subsystem, assembly, component) which can be more elaborate.

340

System

Products

Subsystems

Assemblies

Components

Subcomponents

Parts Subcomponents

Subassemblies

Parts

IEEE‐STD‐1220, IEEE Standard for Application and Management of the Systems Engineering Process, New York: IEEE Computer Society, 2005.



©2020 ‐ 171 ‐

Physical Hierarchy

• It is common to allow the hierarchical terms to be relative. For example, an aircraft system contains, among others, the engine subsystem, which may consist of assemblies such as fuel tanks, pumps and lines, turbines, compressors, gear boxes, and hydraulic pumps.

• The engine manufacturer may consider the engine to be the system, comprising fuel, power plant, and hydraulic subsystems, and so on.

• However, an implicit part of the definition of a system is that it must be able to stand alone in its own right. An engine is therefore not a system—it is only useful as an element of a system (that is, as a subsystem).

341

Hierarchy of an SOI

• It is probably better, therefore, to consider an SOI to comprise a combination of interacting system elements, some of which may be systems in their own right.

342

System-of-Interest

SystemElement

SystemElement

System System

SystemElement

SystemElement

SystemElement

SystemElement

SystemElement

SystemElement

System System

ISO/IEC 15288‐2015, Systems and Software Engineering—System Life Cycle Processes, 2015.



©2020 ‐ 172 ‐

SOI: System or System‐of‐Systems343

System-of-Interest

System System System

System System System

SystemElement

SystemElement

SystemElement

SystemElement

SystemElement

SystemElement

System-of-Systems

System

SystemSystem-of-Systems

Three Types of Collections of Systems

• System of Systems (SoS)—integrated capability.

• Family of Systems (FoS)—common‐use systems.

• Portfolio of Systems (PoS)—management grouping.

We will later call these collections: Programs.

344

Source: M.W. Maier, Architecting a portfolio of systems, Systems Engineering. 2019;1‐13, wileyonlinelibrary.com/journal/sys



©2020 ‐ 173 ‐

System or System‐of‐systems (SoS)?345

System

Subsystem Subsystem

Subsystem Subsystem

System-of-Systems

System System

System System

System or System‐of‐systems (SoS)?346

System

Subsystem Subsystem

Subsystem Subsystem

System-of-Systems

System System

System System

A system is an integration of a number of co‐dependent subsystemsthat are interconnected

permanentlyto achieve a common purpose.

An SoS is an integration of a number of independent systems that are interconnected for a period of time

to achieve a common purpose.



©2020 ‐ 174 ‐

System Life Cycle

Generic System Life Cycle

• Throughout the life of a system there are a number of phases and activities, each of which builds on the results of the preceding phase or activity.

• The sum all these activities is called a system life cycle.

• A generic system life cycle can be divided into four very broad phases.

348

AcquisitionPhase

UtilizationPhase

RetirementPhase

Pre-acquisitionPhase



©2020 ‐ 175 ‐

Pre‐acquisition Phase

• The life cycle begins in the Pre‐acquisition Phase with an idea for a system being generated as a result of business planning.

• Business needs are confirmed and supported by a business case.

• Ensures that only feasible, cost‐effective projects are taken forward to acquisition.

349

AcquisitionPhase

UtilizationPhase

RetirementPhase


Acquisition Phase

• The Acquisition Phase is focused on bringing the system into being and into service in the organisation.

• The system is defined in terms of:

– business requirements,

– stakeholder requirements, and

– system requirements.

• A contractor is then normally engaged to develop/deliver the system.

350

AcquisitionPhase

UtilizationPhase

RetirementPhase




©2020 ‐ 176 ‐

Utilization Phase

• The system is operated and supported during the Utilization Phase

• During utilization, the system may undergo a number of modifications and upgrades to:

– rectify performance shortfalls,

– meet changing operational requirements or external environments to enable ongoing support for the system to be maintained, or

– enhance current performance or reliability.

351

AcquisitionPhase

UtilizationPhase

RetirementPhase


Retirement Phase

• The system is in service during the Utilization Phase until:

– the business has no further need for the system, or

– it no longer can meet the functions required of it by the organisation, or

– it is no longer cost‐effective to keep it in service.

• If the business need for the capability still exists in the organisation, the conclusion of one system life cycle marks the start of another and the process begins again.

352

AcquisitionPhase

UtilizationPhase

RetirementPhase




©2020 ‐ 177 ‐

Parties Involved

• Throughout the system life cycle, there are a number of parties involved.

• The customer organization is managed by:

– enterprise management who set the direction for the organisation and for

– business management who are responsible for the activities conducted by

– the operations element of the organisation which is run by

– the operators—sometimes called the users.

353

Parties Involved

• The systems used within the organisation are acquired by:

– the acquisition element (also called the acquirer, or tasking activity) of the organisation under the auspices of

– a project, which is typically managed by

– a project manager.

• Project managers are supported by a number of related disciplines including:

– systems engineering,

– requirements engineering,

– specialist engineering disciplines,

– quality assurance, and

– integrated logistic support.

354



©2020 ‐ 178 ‐

Parties Involved

• Operators are supported in their operation of the system by the support element of the organisation, which supports, sustains, and maintains the system throughout its life.

• In addition to the operational, acquisition, and support staff, there are many others within the customer organization who have a stake in the successful implementation of the project.

• These stakeholders can include representatives from the management, financial, operations, supply, maintenance, and facilities areas of the organisation.

355

Parties Involved

• The system is obtained from a supplier (also called the performing activity) who may deliver the system off‐the‐shelf or may develop it, in which case they are often called the developer.

• The supplier (developer) may be an internal part of the customer (acquirer) organisation.

• It is increasingly common these days for the supply or development to be undertaken by an outside organisation called a contractor.

• The relationship between the customer and the contractor is defined by the terms and conditions of the contract.

• Often the contractor is not able to perform all of the work required and devolves packages of work to a number of subcontractors through a number of subcontracts.

356



©2020 ‐ 179 ‐

Acquisition Phase Utilization Phase Retirement PhasePre-acquisition Phase

ProjectManagement

Enterprise/Business

Management

SystemsEngineering

Operations

Responsibilities of the Parties Involved

• Responsibility for the various phases of the system life cycle is spread across the enterprise (or organisation) within which the eventual system will operate.

• Note that all parties are involved at all stages in the life cycle, with the roles and responsibilities of each party shifting in emphasis between stages.

357

Activities in Acquisition and Utilization Phases

• Systems engineering is predominantly related to the Acquisition Phase of the system life cycle and, to a lesser extent, the Utilization Phase.

• For these two major phases, we use the life‐cycle activities based on those defined by Blanchard and Fabrycky.

358

AcquisitionPhase

PreliminaryDesign

DetailedDesign and

Development

UtilizationPhase

RetirementPhase


ConceptualDesign

Constructionand/or

Production

Operational Useand

System Support

Blanchard, B. and W. Fabrycky, Systems Engineering and Analysis, Upper Saddle River, N.J.: Prentice-Hall, 1998.



©2020 ‐ 180 ‐

Acquisition Phase

• The Acquisition Phase comprises the four main activities of Conceptual Design, Preliminary Design, Detailed Design and Development, and Construction and/or Production.

• Here we look at each of these activities in a little more detail—we will examine them in much more detail in later weeks.

359

PreliminaryDesign

DetailedDesign and

Development

Constructionand/or

Production

ConceptualDesign

Acquisition Phase

Conceptual Design

• Formal transition from the business world to the project world—from the mission statement to complete logical description of the system‐of‐interest.

• Ensures proper definition of the system requirements.

• Ensures appropriate engagement with business managers and upper‐level stakeholders.

360

PreliminaryDesign

DetailedDesign and

Development

Constructionand/or

Production

ConceptualDesign



©2020 ‐ 181 ‐

Conceptual Design

• Business Needs and Requirements (BNR) are articulated and confirmed by business management.

• BNR are elaborated by stakeholders at the business operations level into a set of Stakeholder Needs and Requirements (SNR).

• SNR are elaborated by requirements engineers into system requirements in the System Requirement Specification (SyRS).

361

PreliminaryDesign

DetailedDesign and

Development

Constructionand/or

Production

ConceptualDesign

System Requirement Specification (SyRS)

StakeholderNeeds and

Requirements(SNR)

BusinessNeeds and

Requirements(BNR)

Conceptual Design

• The BNR, SNR and the SyRS are key elements of what is called the Functional Baseline (FBL).

• Conceptual Design ends with the System Design Review (SDR), which finalizes the initial FBL.

• SDR confirms the BNR, SNR and the SyRS, and provides a formal record of design decisions and design acceptance.

362

PreliminaryDesign

DetailedDesign and

Development

Constructionand/or

Production

ConceptualDesign

Functional Baseline

System Design Review (SDR)



©2020 ‐ 182 ‐

Preliminary Design

• Converts the logical architecture in initial FBL into description of the physical subsystems (the upper‐level physical architecture) that will meet the system requirements.

• Results in the Allocated Baseline (ABL), so‐called because the functionality of the system is now allocated to physical building blocks called configuration items (CI), which are described in Development Specifications.

• Ends with a Preliminary Design Review (PDR).

363

PreliminaryDesign

DetailedDesign and

Development

Constructionand/or

Production

ConceptualDesign

Allocated Baseline(Development Specifications)

Preliminary Design Review(PDR)

Functional Baseline(System Requirement Specification (SyRS))

System Design Review(SDR)


Requirements(SNR)

BusinessNeeds and

Requirements(BNR)

Detailed Design and Development

• Uses engineering disciplines to develop the individual subsystems, assemblies, and components in the system.

• Results in the Product Baseline (PBL) as the system is now defined by the numerous products (subsystems, assemblies, and components) as well as the materials and processes for manufacturing and construction.

• Ends with Critical Design Review (CDR).

364

PreliminaryDesign

DetailedDesign and

Development

Constructionand/or

Production

ConceptualDesign



Allocated Baseline(Development Specifications)Preliminary Design Review

(PDR)

Product Baseline(Product Specifications)Critical Design Review

(CDR)


Requirements(SNR)

BusinessNeeds and

Requirements(BNR)



©2020 ‐ 183 ‐

Construction and/or Development

• Components are produced in accordance with the PBL specifications and the system is ultimately constructed.

• Ends with Formal Qualification Review (FQR), which provides the basis upon which the customer accepts the system from the contractor.

• FQR is informed by the results of acceptance test and evaluation (AT&E)

365

PreliminaryDesign

DetailedDesign and

Development

Constructionand/or

Production

ConceptualDesign



Allocated Baseline(Development Specifications)Preliminary Design Review

(PDR)

Product Baseline(Product Specifications)Critical Design Review

(CDR)


Requirements(SNR)

System AcceptanceFormal Qualification Review

(FQR)

BusinessNeeds and

Requirements(BNR)

Utilization and Retirement Phases

• Major activities in Utilization Phase are:

– Operational Use

– System Support

• Modifications may be necessary.

• The system life cycle ends with the Retirement Phase.

366

AcquisitionPhase

UtilizationPhase

RetirementPhase




©2020 ‐ 184 ‐

Development Approaches

• We have presented the life‐cycle phases and activities in sequence.

• This assumes the waterfall approach to development.

• There other approaches such as incremental, spiral, and evolutionary acquisition, each of which has strengths and weaknesses.

• For simplicity, we continue to assume the waterfall approach for the majority of the course—a solid understanding of the approach is useful because it helps understand the others, and the others all have the waterfall approach as a fundamental building block.

• We return to the other approaches later.

367

Introduction toSystems Engineering



©2020 ‐ 185 ‐

What is Systems Engineering?

• Each definition tends to reflect the particular focus of its source.

• There are, however, a number of common themes which indicate the key tenets of systems engineering:

– Top‐down approach

– Requirements engineering

– Life‐cycle focus

– System optimization and balance

– Integration of specialisations and disciplines

– Management

369

Top‐down Approach

• Traditional engineering disciplines are based on bottom‐up approach:

– We design and build components, integrate them into the next higher level element and so on until we have the system.

– This is very effective so long as we are trying to solve a particular, well‐defined problem.

• Complex problems with many inter‐relationships tend not to be suited to bottom‐up solutions.

370



©2020 ‐ 186 ‐

Top‐down Approach

• Start by looking at the system as a whole to provide a thorough understanding of the system and its environment and interfaces.

• System‐level requirements are developed.

• Likely subsystems can then be considered and requirements assigned to individual subsystems, the subsystems further broken down into assemblies, and then into components

• This process continues until a complete understanding is achieved of the system from top to bottom which allows:

– Additional (derived requirements) to be developed.

– Interfaces between subsystems to be identified.

• This approach is well documented in process standards such as ANSI/EIA‐632.

371

Top‐down Development372

System


Subsystem Subsystem

Testproduct

Trainingproduct

Disposalproduct

Developmentproduct

Deploymentproduct

Supportproduct

Productionproduct

Endproduct

System


Subsystem Subsystem

Testproduct

Trainingproduct

Disposalproduct

Developmentproduct

Deploymentproduct

Supportproduct

Productionproduct

Endproduct

System


Subsystem Subsystem

Testproduct

Trainingproduct

Disposalproduct

Developmentproduct

Deploymentproduct

Supportproduct

Productionproduct

Endproduct

System


Subsystem Subsystem

Testproduct

Trainingproduct

Disposalproduct

Developmentproduct

Deploymentproduct

Supportproduct

Productionproduct

Endproduct

System


Subsystem Subsystem

Testproduct

Trainingproduct

Disposalproduct

Developmentproduct

Deploymentproduct

Supportproduct

Productionproduct

Endproduct

System


Subsystem Subsystem

Testproduct

Trainingproduct

Disposalproduct

Developmentproduct

Deploymentproduct

Supportproduct

Productionproduct

Endproduct

System


Subsystem Subsystem

Testproduct

Trainingproduct

Disposalproduct

Developmentproduct

Deploymentproduct

Supportproduct

Productionproduct

Endproduct

System


Subsystem Subsystem

Testproduct

Trainingproduct

Disposalproduct

Developmentproduct

Deploymentproduct

Supportproduct

Productionproduct

Endproduct

System


Subsystem Subsystem

Testproduct

Trainingproduct

Disposalproduct

Developmentproduct

Deploymentproduct

Supportproduct

Productionproduct

Endproduct

System


Subsystem Subsystem

Testproduct

Trainingproduct

Disposalproduct

Developmentproduct

Deploymentproduct

Supportproduct

Productionproduct

Endproduct

System


Subsystem Subsystem

Testproduct

Trainingproduct

Disposalproduct

Developmentproduct

Deploymentproduct

Supportproduct

Productionproduct

Endproduct

System


Subsystem Subsystem

Testproduct

Trainingproduct

Disposalproduct

Developmentproduct

Deploymentproduct

Supportproduct

Productionproduct

Endproduct

System


Subsystem Subsystem

Testproduct

Trainingproduct

Disposalproduct

Developmentproduct

Deploymentproduct

Supportproduct

Productionproduct

Endproduct



©2020 ‐ 187 ‐

Bottom‐up Integration

• While design is top‐down, integration is bottom‐up.

• At each stage of the integration, some form of integration testing will be conducted to verify the successful integration.

373

Subsystem

Component Component

Subsystem

Integration testing

Assembly Assembly

SystemSystem

Development Integration

Design Solution

Requirements Engineering

• Complete and accurate definition of requirements is fundamental to project success.

• Original need translates into statements of requirement which form the basis of functional and (eventually) physical design.

• These transitions must be managed by a rigorous process called requirements engineering.

• Once requirements have been collected, the systems engineering process then focuses on the derivation and decomposition of these requirements from the system level right down to the lowest constituent component (sometimes referred to as requirements flowdown).

374



©2020 ‐ 188 ‐


• Requirements traceability is essential:

– Forward traceability allows design decisions to be traced from any requirement down to a lower level.

– Backward traceability means that any lower‐level requirement is associated with at least one higher‐level requirement.

• Traceability assures the customer that all requirements can be accounted for in the design at any stage and that no unnecessary requirements are included.

• Traceability also supports the configuration control (change management) process.

• Requirements traceability is a feature of top‐down design, which guarantees that requirements can be satisfied at any stage.

375

Life‐cycle Focus

• Systems engineering maintains a life‐cycle focus as decisions are made.

• Often, the temptation is to focus on acquisition issues in order to minimise acquisition costs and schedules.

• Given that a system spends a majority of its life in utilisation the full life‐cycle cost (LCC) must be considered.

• As a simple example, it is false economy to buy a cheaper car that has very high running costs, if a slightly more expensive car can be acquired which has lower through‐life costs (and therefore a lower LCC).

376



©2020 ‐ 189 ‐

Reduction in Overall Acquisition Schedule

• A reduction in overall acquisition time is possible through solid requirements engineering efforts.

• By getting the requirements right early and then monitor their inclusion into the subsequent design, we can reduce the potential for costly and time‐consuming changes later.

High

Low

Conceptual &Preliminary

Design

DetailedDesign and

Development

Constructionand/or

Development

Utilization

Ease of making changes

Cost of making changes

377

System Optimisation and Balance

• We cover this issue in detail later but basically a collection of optimally‐designed subsystems do not necessarily lead to an optimal system.

• Systems engineering is looking for optimal system‐level performance.

• This sometimes must force subsystem and component designers down sub‐optimal paths.

• Also system engineering recognises that the system must be designed with balance in mind.

– For example we must balance system performance with other factors such as social, ethical, cultural and psychological effects (and others).

378



©2020 ‐ 190 ‐

Integration of Specializations / Disciplines

• Systems engineering integrates a diverse range of technical disciplines and specializations.

• Our aircraft example illustrates this point because it involves more than just engineering disciplines—must also involve finance, legal, environmental specialists and so on.

• Systems engineering defines the tasks that can be completed by these disparate disciplines and specialties and then provides the management to integrate their efforts to produce a system.

• This function is essential because of the complexity of large projects and their contracting mechanisms, and the geographic dispersion of contractor and subcontractor personnel across the country and around the world.

379

Management

• Systems engineering clearly has a technical role to play but it also has a very important management role.

• There is a very strong link between the necessary functions of project management and systems engineering.

• Systems engineering products ensure project management decisions are informed.

• More on this later.

380



©2020 ‐ 191 ‐

Systems Engineering Management

Technical Reviews and Audits

• Technical reviews and audits measure progress and reduce technical risk by:

– providing a formal evaluation of design maturity

– measuring and reporting on planned and actual performance

– clarifying and prioritising design requirements

– evaluating and establishing the system baseline at discrete points in the design process

– providing an effective means of formal communication between stakeholders

– recording design decisions and rationales for later reference

382



©2020 ‐ 192 ‐


• Work for both customer and contractor.

• Vital part of systems engineering.

• Range from very informal discussions to formal meetings.

• Aim to determine the ability of the design to meet the necessary requirements.

• Reviews will tend to become more detailed as the design progresses.

• Normally specified (number, content and timing) in contractual documentation.

383


• Number of reviews required will depend on:

– Complexity

– Size

– Technical risk

• Reviews must be scheduled at the correct stage in the development:

– Too early = immature design, unable to determine adequacy

– Too later = miss opportunities to rectify problems

• Normally relate reviews and audits to documentation release in early stages.

• Seen as a major technical risk monitoring tool.

384



©2020 ‐ 193 ‐


• We have already discussed the following reviews and audits discussed in MIL‐STD‐499B:

– System Requirements Review

– System Design Review

– Preliminary Design Review

– Critical Design Review

– Test Readiness Review

– Functional Configuration Audit

– Physical Configuration Audit

– Formal Qualification Review

Conceptual Design

Preliminary Design

Detailed Design & Development

Construction and/or Production

385

Technical Reviews and Audits386

ConceptualDesign

DetailedDesign &

Development

PreliminaryDesign

Constructionand/or

Production

Operational Useand

System Support

MISSION

DISPOSAL

•Feasibility Analysis•System RequirementsAnalysis•System Synthesis &Evaluation

•Subsystem FunctionalAnalysis•Requirements Allocation•Sub‐system Synthesis &Evaluation

•Detailed DesignRequirements•Designing & IntegratingSystem Elements•System PrototypeDevelopment

System Level Subsystem Level Component Level Modifications Modifications

System Design ReviewPreliminary Design Review

Critical Design Review

Functional Baseline•SyRS

Allocated Baseline•Development Specifications

Product Baseline•Product Specifications•Process Specifications•Material Specifications

Formal Qualification Review

Functional Configuration Audit

Physical Configuration Audit

Test Readiness Review

System Requirements Review

BNR/SNR



©2020 ‐ 194 ‐

Technical Review and Audit Management

• Review and audit requirements can be extensive so management required.

• Requirements must be specified in contract.

• However, requirements must be proportional to size and complexity of the project:

– Under‐reviewing will expose the project to risk.

– Over‐reviewing will needlessly increase cost and schedule without additional benefit.

• Both customer and contractor need to be involved as both parties can add value.

• Results must be documented and action items must be assigned to an individual (unassigned action items = unactioned action items).

387

Technical Review and Audit Plan (TRAP)

• The principal way of managing the technical review and audit effort is via a Technical Reviews and Audits Plan (TRAP).

• The TRAP documents all formal reviews, detailing the entry criteria that must be met prior to the commencement of the review or audit and the exit criteria that must be demonstrated prior to approval of the review or audit.

• The TRAP is normally drafted and approved during Conceptual Design.

388



©2020 ‐ 195 ‐

Test and Evaluation

System T&E

• Ensures consistent and coordinated approach to system testing.

• Directs the focus of Test and Evaluation (T&E) effort at different life‐cycle stages.

• Aims to progressively test and evaluate the system as it passes through the life cycle.

• Aims to identify problems early to avoid costly and time consuming rectifications later.

• T&E is a major technical risk mitigation measure.

390



©2020 ‐ 196 ‐

System T&E

• Testing can be expensive and time‐consuming:

– Specialised test equipment.

– Highly trained personnel.

– Expensive operating costs.

– Facilities.

• A formal plan is usually required to manage the entire T&E effort: Test and Evaluation Master Plan (TEMP).

391

Verification and Validation (V&V)

• The entire systems engineering process aims to produce a system that is:

– verified against the documentation produced, and

– validated against the original needs, goals and objectives.

• V&V ensures that we have both:

– built the system right (verification); and

– built the right system (validation).

• The T&E effort supports V&V.

392



©2020 ‐ 197 ‐

T&E categories

• Developmental Test and Evaluation (DT&E):– Largely undertaken in the Acquisition Phase.– Support design and development effort.– Generally undertaken by contractors.

• Acceptance Test and Evaluation (AT&E):– Formal acceptance testing on behalf of customer.– Between the Acquisition and Utilisation Phases.

• Operational Test and Evaluation (OT&E):– Focuses on functional or operational testing of the system.– Generally undertaken by users following acceptance.– Some OT&E—called Preview T&E (PT&E)—can occur earlier during Acquisition Phase, particularly for large, phased projects.

393

T&E Categories

PreliminaryDesign

DetailedDesign and

Development

Operational Useand

System Support

Constructionand/or

Production

ACQUISITIONPHASE

UTILIZATIONPHASE

ConceptualDesign

AT&E

OT&E

DT&E

PT&E



©2020 ‐ 198 ‐

Developmental Test and Evaluation (DT&E)

• Takes place throughout the Acquisition Phase.

• Aims to highlight design deficiencies early—the earlier a deficiency is noted, the cheaper and easier it is to rectify.

• Used to validate designs and to monitor and minimise design‐related risks.

• Covers a broad range of testing from lowest level components to system prototypes very close to final system configuration

• Responsibility normally lies with the contractor.

• Although a contractor responsibility, customer will normally want visibility into DT&E progress (perhaps through the Technical Review and Audit process).

395

Acceptance Test and Evaluation (AT&E)

• Normally shared by contractor and customer:

– customer approves procedures

– customer and/or contractor conduct testing

– customer will always observe if not conducting

• Focused on confirming that delivered system meets the system‐level requirements contained in the System Specification and the contract (back to the Functional Baseline).

• Discrepancies are documented and rectified.

• On successful conclusion, system is accepted and will formally enter Utilization Phase.

396



©2020 ‐ 199 ‐

Operational Test and Evaluation (OT&E)

• After AT&E, OT&E is used by the customer to assess the ability of the system to meet the original needs.

• Can be conducted early in Conceptual Design, in which case it is called Preview T&E (PT&E).

• Testing focused on operational functionality rather than design issues.

• Normally, testing agency within the customer’s organisation will be independent from the procuring agency within the customer’s organisation.

• Independence is important to gain an unbiased assessment (sometimes the procuring agency will feel some ownership and responsibility for system performance).

397

OT&E

• Modifications may be suggested as a result of OT&E.

• OT&E may also be used to assist operators to fine‐tune operational procedures relating to system use.

• Must be conducted in as realistic conditions as possible.

• Responsibility of the customer organisation.

398



©2020 ‐ 200 ‐

OT&E

AT&E

AT&E

AT&E

AT&E

AT&E

AT&E

Facilities

Training

Support

Supplies

Personnel

SyRS


Capability System Development

Acquisition Phase Utilization Phase

In-service

DeliveredCapabilitySystem

StRSOrganisation

Major System AT&E

OT&E

Validation

Verification

Test Management

• To allow a coordinated approach to testing, DT&E, AT&E and OT&E will normally be managed by the contractor.

• Coordination ensures minimal impact on schedule and maximum effectiveness.

• Coordination may also save on T&E resources and avoid unnecessary duplication of effort.

400



©2020 ‐ 201 ‐

Test and Evaluation Master Plan (TEMP)

• Test and Evaluation Master Plan (TEMP) is the major plan for entire T&E effort.

• Required by contract, prepared by contractor and approved by customer.

• Drafted during Conceptual Design and approved by the end of Preliminary Design.

• Should be reviewed at each formal review to ensure that any design changes are reflected in the testing program.

401

Specifications & Standards



©2020 ‐ 202 ‐

Specification Tree

System RequirementSpecification

InterfaceControl

Document

HardwareDevelopmentSpecification

Hardwarerequirementsspecification

Interfacerequirementsspecification

HardwareProduct

Specification

Interfacedesign

document

ProcessSpecification

MaterialSpecification

COTSProduct

Specification

SoftwareProduct

Specification

SoftwareDevelopmentSpecification

Softwarerequirementsspecification

Interfacerequirementsspecification

Softwaredesign

document

Interfacedesign

document

Databasedesign

document

Hardwaredesign

document

SE Standards Evolution

MIL-STD-499

(1969)

MIL-STD-499A(1974)

MIL-STD-499B(1994)

EIA/IS 632(1994)

IEEE 1220(Trial Use)

(1994)

EIA 632(1999)

IEEE 1220(1998)

MIL-STD-499C(Draft 2005)

ISO/IEC 15288(2008)

IEEE 1220(2005)

ISO/IEC 15288(2003)

ISO/IEC 15288(2015)

EIA 632(2003)

404



©2020 ‐ 203 ‐

Integration & Planning

Integration Management

• The Interface Control Document (ICD) will completely define the interfaces between two CIs.

• Interface types include: physical, electronic, electrical, hydraulic, pneumatic, software, and environmental.

• Integration management is all about communications.

• Interface problems are usually blamed on technical difficulties but often result from poor communications between two teams.

• ICD needs to be reviewed regularly if for no other reason than to ensure communications.

• Customer should review ICDs at design reviews.

406



©2020 ‐ 204 ‐

SE Management Plan (SEMP)

• Systems engineering is such a broad subject area that an overall management plan or approach needs to be developed.

• This plan is called the Systems Engineering Management Plan (SEMP).

• SEMP details:

– Normally prepared by the contractor.

– Reviewed and approved by the customer.

• There may be more than one SEMP per system development:

– Customer.

– Contractor.

– Major sub‐contractors.

407

Major Plans408

ConceptualDesign

DetailedDesign &

Development

PreliminaryDesign

Constructionand/or

Production

Operational Useand

System Support

MISSION

DISPOSAL

•Feasibility Analysis•System RequirementsAnalysis•System Synthesis &Evaluation

•Subsystem FunctionalAnalysis•Requirements Allocation•Sub‐system Synthesis &Evaluation

•Detailed DesignRequirements•Designing & IntegratingSystem Elements•System PrototypeDevelopment

System Level Subsystem Level Component Level Modifications Modifications

System Design ReviewPreliminary Design Review

Critical Design Review

Functional Baseline•SyRS

Allocated Baseline•Development Specifications

Product Baseline•Product Specifications•Process Specifications•Material Specifications

Formal Qualification Review

Functional Configuration Audit

Physical Configuration Audit

Test Readiness Review

System Requirements Review

BNR/SNR

Technical Review and Audit Plan (TRAP)

Test and Evaluation Master Plan (TEMP)

Risk Management Plan (RMP)

Configuration Management Plan (CMP)

Systems Engineering Management Plan (SEMP)



©2020 ‐ 205 ‐

Introduction toProject Management

Introduction

• Project management is still a relatively young, emerging profession.

• While there is some considerable agreement to the tasks that should be conducted, many of the terms are still not standardised.

• We will highlight the major practices and use the most commonly accepted terms.

• In particular, we discuss project management within the framework adopted in the Project Management Body of Knowledge (PMBOK©)*.

410

* A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Project Management Institute, Upper Darby, PA, 2017.



©2020 ‐ 206 ‐

CLC Project

• A Project is a unique, finite, multidisciplinary and organised endeavour to deliver a Product or Products.

• A Project generally occurs in the early part of the Product Life cycle although Projects can be established later (for Product upgrades, for example).

• A Project has its own life cycle which delivers the Product.

411

AcquisitionStrategy and Concepts Risk Mitigation and Requirements Setting


Product life cycle

Gate 0 Gate 2Gate 1

Project life cycle

Conceive Develop Implement Terminate

What is Project Management?

• Project Management provides a structured and reliable means to realise the Product.

• Project management is:

the application of knowledge, skills, tools and techniques to project activities to meet project requirements.*

• Project management is the management effort to deliver the best balance across these requirements.

412




©2020 ‐ 207 ‐


Project Management (PM) is achieved through a number of well‐defined and proven processes across ten project management knowledge (PMBOK) areas*:

• Integration Management

• Scope Management

• Schedule Management

• Cost Management

• Quality Management

413

• Resource Management

• Communications Management

• Risk Management

• Procurement Management

• Stakeholder Management


Defence Project Management

• Structured and reliable means to deliver a Product

• CASG Project Management policy and guidance follows the principles from a number of standards namely:

– Project Management Institute (PMI) Project Management Body of Knowledge (PMBOK®);

– AS ISO 55000‐55002:2014;

– Managing Successful Programs (MSP); and

– AS ISO 21500:2016 Guidance on Project Management. AS21000.

414



©2020 ‐ 208 ‐

IPM Roles in the CLC

• Delivery Group:

– appoints IPM

– establishes IPMT before Gate 0

• IPM responsible for:

– developing PES, IPMP

– undertaking initial project planning and coordination

– managing ‘program’ of risk reduction activities

– coordinates early industry involvement

– implements integrated planning across FIC

– integrate and coordinate delivery of FIC

415

Integrated Project Management: Dimensions

Consistent with ISO 55000 and PMBOK, Project Management is an integrating discipline which ensures:

• whole‐of‐life, Joint Force Integration, legislative and regulatory obligations;

• coordinating and integrating FIC; and

• integrate the supporting Practices.

416

* A Guide to the Project Management Body of Knowledge (PMBOK), Project Management Institute, Upper Darby, PA, 2017.



©2020 ‐ 209 ‐

What is a Project?

• Normally within an organisation there are the people who conduct the normal operations of an organisation (the tellers in bank, for example) and those that perform projectsundertaken to improve the organisation and its services (the project managers who roll out the new ATM network, for example).

• While the distinction between the two is occasionally blurred, operations tend to be ongoing and repetitive, while a project is:

a temporary endeavour undertaken to create a unique product, service or result.*

417


What is a Project?

• Temporary:

– A project has an identifiable start and end date.

– Temporary relates to the activity, not the product.

– Temporary does not indicate any particular duration—some projects are very short (of the matter of days), others can take decades.

• Unique:

– The unique nature of a project arises because there is always something different about the activities undertaken during a project.

– For example, building a new house is unique because of different owners, block of land, design, timeframe, etc.

418



©2020 ‐ 210 ‐

Project Size

• A project therefore applies to a wide range of activities undertaken by an organisation over and above its normal operational activities.

• Notice that nothing we have said refers to the size of a project—a project may only involve a few people and a small number of resources, or thousands of people and billions of dollars.

• A project can be of any size—from baking a cake to building the Channel Tunnel—whatever the size, the principles we discuss here are applicable.

• We do need, however, to consider the size of a project (and therefore the amount of management required) at the beginning when we are establishing project processes and procedures.

419

What is a Project?

• Typical projects may be:

– Developing a new product or service

– Changing the organisational structure, staffing levels or culture

– Introducing a new operating procedure into an organisation

– Designing a new city

– Modifying an engine to provide greater power

– Constructing a building or a complex

– Drilling a well in a third‐world village

– Running for local office

• In short, a project may be any unique, temporary endeavour.

420



©2020 ‐ 211 ‐

What is a Project?

• A project is distinctive because it has:

– A distinct start and finish

– A life cycle ( a number of distinct phases between the start and end)

– A budget and an associated cash flow

– Unique activities

– Use of resources

– A single point of responsibility (the project manager)

– Team roles

* R. Burke, Project Management: Planning and Control Techniques, Burke Publishing, 2003.

421


• Project management is:

the application of knowledge, skills, tools and techniques to project activities to meet the project requirements.*

• Note: “meet”, not “meet or exceed”.

• We achieve project management through a number of well‐defined processes (the ten PMBOK knowledge areas*) that we discuss in more detail throughout this course.

• They are introduced here to provide an overview of project management.


422



©2020 ‐ 212 ‐

What is Project Management?423

SCOPE

CUSTOMERSATISFACTION

TIME COST

Program and Portfolio Management

• A program is defined as a group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually.

• A portfolio is a collection of projects or programs and other work that are grouped together to facilitate effective management of that work to meet strategic business objectives.

424




©2020 ‐ 213 ‐

Who is the Project Manager?

• The project manager is the single point of responsibility for a project.

• The project manager integrates and coordinates all the contributions of the project team and guides them successfully to completion.

• Project managers need good:

– General management and administration skills

– Leadership skills

– Planning, problem‐solving and decision‐making ability

– Communications (written and verbal) skills

– Negotiation skills

– Technical skills

425

PMBOK Knowledge Areas

• Project Integration Management

• Project Scope Management

• Project Schedule Management

• Project Cost Management

• Project Quality Management

• Project Resource Management

• Project Communications Management

• Project Risk Management

• Project Procurement Management

• Project Stakeholder Management

426



©2020 ‐ 214 ‐

Project Integration Management

• Ensures all project elements are integrated and coordinated and conflicting alternatives and expectations are managed.

• Key is development of the Project Plan.

• Once the plan is in place, the project must be executed in accordance with the plan.

• Since the Project Plan will be subject to changes from time to time and some form of change control is required.

427

Project Integration Management428

1.1 Develop Project Charter

.1 Inputs.1 Business documents.2 Agreements.3 Enterprise environmental

considerations.4 Organisational process assets

.2 Tools and Techniques.1 Expert judgement.2 Data gathering.3 Interpersonal and team skills.4 Meetings

.3 Outputs.1 Project charter.2 Assumption log

1.2 Develop Project Management Plan

.1 Inputs.1 Project charter.2 Outputs from other processes.3 Enterprise environmental


.2 Tools and Techniques.1 Expert judgement.2 Data gathering.3 Interpersonal and team skills.4 Meetings

.3 Outputs.1 Project management plan

1.3 Direct and ManageProject Execution

.1 Inputs.1 Project management plan.2 Project documents.3 Approved change requests.4 Enterprise environmental


.2 Tools and Techniques.1 Expert judgement.2 PMIS.3 Meetings

.3 Outputs.1 Deliverables.2 Work performance data.3 Issue log.4 Change requests.5 PMP updates.6 Project documentation updates.7 Organisational process assets

updates

ProjectIntegration Management

A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Project Management Institute, Upper Darby, PA, 2017.



©2020 ‐ 215 ‐


1.4 Manage Project Information

.1 Inputs.1 Project management plan.2 Project Documents.3 Deliverables.4 Enterprise environmental


.2 Tools and Techniques.1 Expert judgement.2 Knowledge management.3 Information management.4 Interpersonal and team skills

.3 Outputs.1 Lessons learned register.2 Project management plan updates.3 Organisational process assets

updates



1.5 Monitor and ControlProject Work

.1 Inputs.1 Project management plan.2 Project documents.3 Work performance documentation.4 Agreements.5 Enterprise environmental

factors.6 Organisational process assets

.2 Tools and Techniques.1 Expert judgement.2 Data analysis.3 Decision making.4 Meetings

.3 Outputs.1 Work performance reports .2 Change requests.3 Project management plan updates.4 Project document updates


1.6 Perform IntegratedChange Control

.1 Inputs.1 Project management plan.2 Project documents.3 Work performance reports.4 Change requests.5 Enterprise environmental


.2 Tools and Techniques.1 Expert judgement.2 Change control tools.3 Data analysis.4 Decision making.5 Meetings

.3 Outputs.1 Approved change requests.2 Project management plan updates.3 Project document updates

1.7 Close Project or Phase

.1 Inputs.1 Project charter.2 Project management plan.3 Project documents.4 Accepted deliverables.5 Business documents.6 Agreements.7 Procurement documentation.8 Organisational process assets

.2 Tools and Techniques.1 Expert judgement.2 Data analysis.3 Meetings

.3 Outputs.1 Project document updates.2 Final product, service, or result

transition.3 Final report.4 Organisational process assets

updates





©2020 ‐ 216 ‐

Project Scope Management

• Ensures all work necessary to complete the project is included in scope.

• Unnecessary work is omitted.

• Scope planning and definition are an important part of scope management.

• Makes use of well known SE tools such as RBS/WBS.

• As with Integration, once plans have been established, they need to be verified.

• This represents formalised approval of the project and its scope by all stakeholders.

• Changes must be managed following approval.

• Remember:

– Change isn’t necessarily bad but uncontrolled change is.

431

Project Scope Management432

2.2 Collect Requirements

.1 Inputs.1 Project charter.2 Project management plan.3 Project documents.4 Business documents.5 Agreements.6 Enterprise environmental factors.7 Organisational process assets

.2 Tools and Techniques.1 Expert judgement.2 Data gathering.3 Data analysis.4 Decision making.5 Data representation.6 Interpersonal and team skills.7 Context diagram.8 Prototypes

.3 Outputs.1 Requirements documentation.2 Requirements traceability matrix

2.3 Define Scope

.1 Inputs.1 Project charter.2 Project management plan.3 Project documents.4 Enterprise environmental factors.5 Organisational process assets

.2 Tools and Techniques.1 Expert judgement.2 Data analysis.3 Decision making.4 Interpersonal and team skills.5 Product analysis

.3 Outputs.1 Project scope statement.2 Project documentation updates

ProjectScope Management


2.1 Plan Scope Management

.1 Inputs.1 Project charter .2 Project management plan.3 Enterprise environmental factors.4 Organisational process assets


.3 Outputs.1 Scope management plan.2 Requirements management plan



©2020 ‐ 217 ‐

Project Scope Management433

2.5 Validate Scope

.1 Inputs.1 Project management plan.2 Project documents.3 Verified deliverables.4 Work performance data

.2 Tools and Techniques.1 Inspection.2 Decision making

.3 Outputs.1 Accepted deliverables.2 Work performance information.3 Change requests .4 Project document updates

2.6 Control Scope

.1 Inputs.1 Project management plan.2 Project documents.3 Work performance data.4 Organisational process assets

.2 Tools and Techniques.1 Data analysis

.3 Outputs.1 Work performance information.2 Change requests.3 Project management plan updates.4 Project document updates

ProjectScope Management


2.4 Create WBS

.1 Inputs.1 Project management plan.2 Project documents.3 Enterprise environmental


.2 Tools and Techniques.1 Expert judgement.2 Decomposition

.3 Outputs.1 Scope baseline.2 Project documentation updates

Work Breakdown Structures (WBS)

• A WBS is a deliverable‐oriented grouping of project components that provides a hierarchical description of the whole project—if it isn’t in the WBS, it isn’t in the project’s scope.

• The WBS is therefore a graphical overview of the project that helps verify as well as communicate the project scope.

• The WBS is normally presented in chart form—each item is uniquely identified.

• The lowest level of the WBS contains what are normally called work packages.

434



©2020 ‐ 218 ‐

Work Breakdown Structures (WBS)435

An example WBS—US DoD MIL-HDBK-881 format

Aircraft system

Systems engineering/project management

Air vehicle

Systems test &evaluation

Training

Data

Operationalactivation

Supportequipment

Spares

Facilities

•Undercarriage CI•Wings/fuselage CI•Fuel system CI•Hydraulic system CI•Flight controls CI•Engine CI•Avionics CI•Interior CI•Design, integration, assembly, test

•Developmental test & evaluation•Acceptance test & evaluation•Operational test & evaluation•T&E support•Test facilities

•Aircraft equipment•Support services•Facilities

•Technical publications•Engineering data•Management data•Support data•Data repository

•Test & measurement equipment•Support & handling equipment

•System-level assembly,installation & checkout

•Technical support•Site construction

Work Breakdown Structures (WBS)436

WBS numbering system

COMPLETE PROJECT

1234 01 01 001

Main assemblies

Sub-assemblies

Parts and components

Work package number

R. Burke, Project Management: Planning and Control Techniques, Burke Publishing, 2003.



©2020 ‐ 219 ‐

Project Schedule Management

• Includes processes required to ensure the timely completion of the project.

• Also called time management:

– Starts with activity definition where all project activities are identified.

– The sequence that these activities will be conducted is then identified (including parallel).

– The duration of each activity is estimated.

– The schedule results.

• SE is heavily involved with schedule management.

437

Project Schedule Management

• The schedule then needs to be managed and controlled throughout the project.

• Many computer‐aided tools are available to assist (for example, PERT and CPM software).

• Tools don’t manage the schedule, they merely assist the project manager.

• Experience and judgement remain the premier time management tools.

438



©2020 ‐ 220 ‐

Project Schedule Management439

3.2 Define Activities

.1 Inputs.1 Project management plan.2 Enterprise environmental factors.3 Organisational process assets

.2 Tools and Techniques.1 Expert judgement.2 Decomposition.3 Rolling wave planning.4 Meetings

.3 Outputs.1 Activity list.2 Activity attributes.3 Milestone list.4 Change requests.5 Project management plan

updates

3.3 Sequence Activities

.1 Inputs.1 Project management plan.2 Project documents.3 Enterprise environmental factors.4 Organisational process assets

.2 Tools and Techniques.1 Precedence diagramming method.2 Dependency determination and

integration.3 Leads and lags.4 PMIS

.3 Outputs.1 Project schedule network

diagrams.2 Project documentation updates

ProjectSchedule Management

A Guide to the Project Management Body of Knowledge (PMBOK), Project Management Institute, Upper Darby, PA, 2017.

3.1 Plan Schedule Management

.1 Inputs.1 Project charter.2 Project management plan.3 Enterprise environmental factors.4 Organisational process assets


.3 Outputs.1 Schedule management plan

Project Schedule Management440

3.4 Estimate Activity Durations


.2 Tools and Techniques.1 Expert judgement.2 Analogous estimating.3 Parametric estimating.4 Three-point estimating.5 Bottom-up estimating.6 Data analysis.7 Decision making.8 Meetings

.3 Outputs.1 Duration estimates.2 Basis of estimates.3 Project document updates

3.5 Develop Schedule

.1 Inputs.1 PMP .2 Project documents.3 Agreements.4 Enterprise environmental factors.5 Organisational process assets

.2 Tools and Techniques.1 Schedule network analysis.2 Critical path method.3 Resource optimization technique.4 Data analysis.5 Leads and lags.6 Schedule compression.7 PMIS.8 Agile release planning

.3 Outputs.1 Schedule baseline.2 Project schedule.3 Schedule data.4 Project calendars.5 Change requests.6/.7 Project plan/document updates

ProjectSchedule Management


3.6 Control Schedule.1 Inputs

.1 Project management plan

.2 Project documents

.3 Work performance data

.4 Organizational process assets.2 Tools and Techniques

.1 Data analysis

.2 Critical path method

.3 PMIS

.4 Resource optimization

.5 Leads and lags

.6 Schedule compression.3 Outputs

.1 Work performance information

.2 Schedule forecasts

.3 Change requests

.4 Project management plan updates

.5 Project document updates



©2020 ‐ 221 ‐

Project Cost Management

• Responsible for ensuring that the project is delivered within the prescribed budget.

• The next step to estimate the costs associated with each of the activities making up the project.

• Can use previous experience, tools, and modelling to assist.

• Cost budgeting involves allocating the budget to individual project activities.

• Cost control then ensures that changes to the cost baseline is positive.

441

Total Cost of Ownership

• Costing approaches: bottom‐up; top‐down; or a combination

• Bottom‐up:

– utilises WBS (based on the requirements set).

• Top‐down:

– exemplar solution (such as cost estimate based on existing similar system/s);

– Parametric (use a known attribute such as weight of ship, SLOC to develop estimates);

– Analytical techniques using historical data and application of factors for projections; and

– Indexing.

442



©2020 ‐ 222 ‐

Importance of Good Costing Practice

• Supports consideration of Options for Gate decisions.

• Fundamental part of the Business Case and Government submissions.

• Budgeting.

• Particular aspects have proven to be difficult, such as estimating developmental and/or integration projects.

443

Costing Activities across CLC

• Costing activities and techniques change in type and focus dependent on the phase of the CLC:

– Pre‐Gate 0, 1, 2 activities including risk reduction efforts.

– Acquisition Costs:

• includes Introduction into Service. – Operating Costs:

• Most difficult to estimate.

• Required over LOT of capability.• Techniques include:

–Use of historical data.–Factor against acquisition costs.

– Disposal.

444



©2020 ‐ 223 ‐

Project Cost Management445

4.1 Plan cost management.1 Inputs

.1 Project charter


.3 Enterprise environmental factors

.4 Organisational process assets.2 Tools and Techniques

.1 Expert judgement

.2 Data analysis

.3 Meetings.3 Outputs

.1 Cost management plan

ProjectCost Management


4.2 Estimate Costs.1 Inputs





.1 Expert judgement

.2/3 Analogous/parametric estimating

.4 Bottom-up estimating

.5 Three-point estimating

.6 Data analysis

.7 PMIS

.8 Decision making.3 Outputs

.1 Cost estimates

.2 Basis of estimates

.3 Project document updates

Project Cost Management446

4.3 Determine Budget

.1 Inputs.1 Project management plan.2 Project documents.3 Business documents.4 Agreements.5 Enterprise environmental factors.6 Organisational process assets

.2 Tools and Techniques.1 Expert judgement .2 Cost aggregation.3 Data analysis.4 Historical information review.5 Funding limit reconciliation.6 Financing

.3 Outputs.1 Cost baseline.2 Project funding requirements.3 Project document updates

4.4 Control Costs

.1 Inputs.1 Project management plan.2 Project documents.3 Project funding requirements.4 Work performance data.5 Organizational process assets

.2 Tools and Techniques.1 Expert judgement.2 Data analysis.3 To-complete performance index.4 PMIS

.3 Outputs.1 Work performance information.2 Cost forecasts.3 Change requests .4 Project management plan updates.5 Project document updates

ProjectCost Management




©2020 ‐ 224 ‐

Project Quality Management

• Aims to ensure that the project will satisfy its needs.

• Quality assurance will be dealt with separately later.

• Project Management has an important role to play with respect to quality management.

• Quality planning requires management to determine which quality standards will be applied to the project—for example, the ISO 9000 series (more on this later).

• Once the quality standards have been selected, quality planning against those standards is required.

• Quality assurance (in accordance with the plan) involves planned and systematic activities aimed at enhancing confidence in project quality.

• Quality control is also used to check specific project results.

447

Project Quality Management448

5.1 Plan Quality Management


.2 Tools and Techniques.1 Expert judgement.2 Data gathering.3 Data analysis.4 Decision making.5 Data representation.6 Test and inspection planning.7 Meetings

3 Outputs.1 Quality management plan.2 Quality metrics.3 Project management plan updates.4 Project documentation updates

5.2 Manage Quality

.1 Inputs.1 Project management plan.2 Project documents.3 Organisational process assets

.2 Tools and Techniques.1 Data gathering.2 Data analysis.3 Decision making.4 Data representation.5 Audits .6 Design for X.7 Problem solving.8 Quality improvement methods

.3 Outputs.1 Quality reports.2 Test and evaluation documents.3 Change requests.4 Project management plan updates.5 Project document updates

5.3 Control Quality

.1 Inputs.1 Project management plan.2 Project documents.3 Approved change requests.4 Deliverables.5 Work performance data.6 Enterprise environmental factors.7 Organizational process assets

.2 Tools and Techniques.1 Data gathering .2 Data analysis.3 Inspection.4 Testing/product evaluations.5 Data representation.6 Meetings

.3 Outputs.1 Quality control measurements.2 Verified deliverables.3 Work performance information.4 Change requests.5 Project management plan updates.6 Project document updates

ProjectQuality Management




©2020 ‐ 225 ‐

Project Resource Management

• Aims to make the most effective use of resources involved in the project, particularly people.

• Organisational planning is the initial activity involving:

– Identifying requirements.

– Documenting and assigning project roles and responsibilities.

– Reporting relationships.

• Once the resource requirements have been identified, the staff must be acquired.

• Finally, the team must be developed to enhance the performance of the individual and team.

449

Project Resource Management450

6.1 Plan Resource Management


.2 Tools and Techniques.1 Expert judgment.2 Data representation.3 Organizational theory.4 Meetings

.3 Outputs.1 Resource management plan.2 Team charter.3 Project documents updates

6.2 Estimate Activity Resources


.2 Tools and Techniques.1 Expert judgement.2 Bottom-up estimating.3 Analogous estimating.4 Parametric estimating.5 Data analysis.6 PMIS.7 Meetings

.3 Outputs.1 Resource requirements.2 Basis of estimates.3 Resource breakdown structure.4 Project management plan updates

ProjectResource Management

6.3 Acquire Resources


.2 Tools and Techniques.1 Decision making.2 Interpersonal and team skills.3 Pre-assignment.4 Virtual teams

.3 Outputs.1 Physical resource assignments.2 Project team assignments.3 Resource calendars.4 Change requests.5 Project management plan updates.6 Project documents updates.7 Enterprise environmental factors

updates.8 Organisational process assets

updates




©2020 ‐ 226 ‐

Project Resource Management451

6.4 Develop Team


.2 Tools and Techniques.1 Co-location.2 Virtual teams.3 Communication technology.4 Interpersonal and team skills.5 Recognition and rewards.6 Training.7 Individual and team assessments.8 Meetings

.3 Outputs.1 Team performance assessments.2 Change requests.3 Project management plan updates.4 Project document updates.5 Enterprise environmental factors

updates.6 Organisational process assets

updates

6.5 Manage Team

.1 Inputs.1 Project management plan.2 Project documents.3 Work performance reports.4 Team performance assessments.5 Enterprise environmental factors.6 Organisational process assets

.2 Tools and Techniques.1 Interpersonal and team skills.2 PMIS

.3 Outputs.1 Change requests.2 Project management plan updates.3 Project documents updates.4 Enterprise environmental factors

updates

ProjectResource Management


6.6 Control Resources

.1 Inputs.1 Project management plan.2 Project documents.3 Work performance data.4 Agreements.5 Organizational process assets

.2 Tools and Techniques.1 Data analysis.2 Problem solving.3 Interpersonal and team skills.4 PMIS

.3 Outputs.1 Work performance information.2 Change requests.3 Project management plan updates.4 Project documents updates

Communications Management

• Starts with communications planning to determine the overall communications requirements—who needs what, when and how.

• Information is then disseminated in accordance with the findings of the first step.

• Must be done in a timely manner.

• Reporting the performance and status of the project is an important part of communications.

• An important communications aspect is reporting the closure of project phases or the project itself.

452



©2020 ‐ 227 ‐

Project Communications Management 453

7.1 Plan Communications Management

.1 Inputs.1 Project charter.2 Project management plan.3 Project documents.4 Enterprise environmental factors.5 Organizational process assets

.2 Tools and Techniques.1 Expert judgement.2 Comms requirements analysis.3 Communications technology.4 Communication models.5 Communication methods.6 Interpersonal and team skills.7 Data representation.8 Meetings

.3 Outputs.1 Comms management plan.2 Project management plan

updates.3 Project documentation updates

7.3 Monitor Communications

.1 Inputs.1 Project management plan.2 Project documents.3 Work performance data.4 Enterprise environmental factors.5 Organisational process assets

.2 Tools and Techniques.1 Expert judgment.2 PIMS.3 Data representation.4 Interpersonal and team skills.3 Meetings

.3 Outputs.1 Work performance information.2 Change requests.3 Project management plan

updates.4 Project documentation updates


ProjectCommunications Management

7.2 Manage Communications

.1 Inputs.1 Project management plan.2 Project documents.3 Work performance reports.4 Enterprise environmental factors.5 Organisational process assets

.2 Tools and Techniques.1 Communications technology.2 Communications models.3 Communications skills.4 PIMS.5 Project reporting.6 Interpersonal and team skills.7 Data representation

.3 Outputs.1 Project communications.2 Project management plan

updates.3 Project documentation updates.4 Organizational process assets

updates

Risk Management

• Risk identification:

– Determine possible risks

– Document risk characteristics

– Needs to be performed on a continual basis

• Risk quantification:

– Evaluates risks and determines interactions

– Determines likely impact of the risk on the project

• Risk response development:

– Take advantage of the opportunities

– Manage the risks to project performance

• Risk response control:

– responding to changes to the risks

454



©2020 ‐ 228 ‐

Project Risk Management455

8.1 Plan Risk Management

.1 Inputs.1 Project scope.2 Project management plan.3 Project documents.4 Enterprise environmental factors.5 Organisational process assets

.2 Tools and Techniques.1 Expert judgment.2 Data analysis.3 Meetings

.3 Outputs.1 Risk management plan

8.2 Identify Risks

.1 Inputs.1 Project management plan.2 Project documents.3 Agreements.4 Procurement documentation.5 Enterprise environmental factors.6 Organisational process assets

.2 Tools and Techniques.1 Expert judgment.2 Data gathering.3 Data analysis.4 Interpersonal and team skills.5 Prompt lists.6 Meetings

.3 Outputs.1 Risk register.2 Risk reports.3 Project documents updates

8.3 Perform QualitativeRisk Analysis

.1 Inputs.1 Project management plan .2 Project documents.3 Enterprise environmental factors.4 Organisational process assets

.2 Tools and Techniques.1 Expert judgment.2 Data gathering.3 Data analysis.4 Interpersonal and team skills .5 Risk categorisation.6 Data representation.7 Meeting

.3 Outputs.1 Project documents updates

ProjectRisk Management



8.4 Perform Quantitative Risk Analysis

.1 Inputs.1 Project management plan .2 Project documents.3 Enterprise environmental factors.4 Organisational process assets

.2 Tools and Techniques.1 Expert judgment.2 Data gathering.3 Interpersonal and team skills .4 Representation of uncertainty.5 Data analysis

.3 Outputs.1 Project documents updates

8.5 Plan Risk Responses


.2 Tools and Techniques.1 Expert judgment.2 Data gathering.3 Interpersonal and team skills .4 Strategies for threats.5 Strategies for opportunities.6 Contingent response strategies.7 Strategies for overall project risk.8 Data analysis.9 Decision making

.3 Outputs.1 Change requests.2 Project management plan updates.3 Project document updates





©2020 ‐ 229 ‐


8.7 Monitor Risks

.1 Inputs.1 Project management plan.2 Project documents.3 Work performance data.4 Work performance reports

.2 Tools and Techniques.1 Data analysis.2 Audits.3 Meetings

.3 Outputs.1 Work performance information.2 Change requests .3 Project management plan updates.4 Project documents updates.5 Organisational process assets

updates


8.6 Implement Risk Responses

.1 Inputs.1 Project management plan.2 Project documents.3 Organisational process assets

.2 Tools and Techniques.1 Expert judgement.2 Interpersonal and team skills.3 PMIS

.3 Outputs.1 Change requests .2 Project documents updates

Procurement Management

• Responsible for obtaining materials and services for the project from outside the organisation.

• Planning must be conducted to determine what is required and when.

• Solicitation planning—these requirements must be documented and potential sources identified.

• Solicitation involves obtaining quotes and offers etc.

• Source selection determines the best offer.

• Contract administration—put in place to manage the procurement contract with the source.

• Contract close‐out—completion and settlement of the contract.

458



©2020 ‐ 230 ‐

Project Procurement Management459

9.1 Plan Procurements.1 Inputs

.1 Project charter

.2 Business documents





.1 Expert judgment

.2 Data gathering

.3 Data analysis

.4 Source selection analysis

.5 Meetings.3 Outputs

.1 Procurement management plan

.2 Procurement strategy

.3 Bid documents

.4 Procurement SOW

.5 Source selection criteria

.6 Make-or-buy decisions

.7 Independent cost estimates

.8 Change requests

.9 Project documents updates

.10 Org process assets updates

9.2 Conduct Procurements.1 Inputs



.3 Procurement documents

.4 Seller proposals


.6 Organizational process assets.2 Tools and Techniques

.1 Expert judgement

.2 Advertising

.3 Bidder conferences

.4 Data analysis

.5 Interpersonal and team skills.3 Outputs

.1 Selected sellers

.2 Agreements

.3 Resource calendars

.4 Change requests

.5 Project management plan updates

.6 Project documents updates

.7 Organisational process assets updates

ProjectProcurement Management


9.3 Control Procurements

.1 Inputs.1 Project management plan.2 Project documents.3 Agreements.4 Procurement documentation.5 Approved change requests .6 Work performance data.7 Enterprise environmental factors.8 Organizational process assets

.2 Tools and Techniques.1 Expert judgement.2 Claims administration.3 Data analysis.4 Inspection.5 Audits

.3 Outputs.1 Closed procurements.2 Work performance information.3 Procurement documents updates .4 Change requests .5 Project management plan updates .6 project documents updates.7 Org process assets updates

Stakeholder Management

• The PMBOK says that stakeholder management involves the processes required to:

– identify the people, groups, or organizations (the stakeholders) that could impact or be impacted by the project;

– analyse stakeholder expectations and their impact in the project; and

– develop appropriate stakeholder management strategies.


460



©2020 ‐ 231 ‐

Project Stakeholder Management 461

10.1 Identify Stakeholders

.1 Inputs.1 Project charter.2 Procurement documents.3 Project management plan.4 Project documents.5 Agreements.6 Enterprise environmental factors.4 Organizational process assets

.2 Tools and Techniques.1 Expert judgment.2 Data gathering.3 Data analysis.4 Data representation.5 Meetings

.3 Outputs.1 Stakeholder register.2 Change requests.3 Project management plan updates.4 Project documents updates

10.2 Plan Stakeholder Engagement

.1 Inputs.1 Project charter.2 Project management plan.3 Project documents.4 Agreements.5 Enterprise environmental factors.6 Organizational process assets

.2 Tools and Techniques.1 Expert judgment.2 Data gathering.3 Data gathering.4 Decision making.5 Data representation.6 Meetings

.3 Outputs.1 Stakeholder engagement plan


ProjectStakeholder Management

Project Stakeholder Management 462

10.3 Manage Stakeholder Engagement

.1 Inputs.1 Project management plan.2 Project documents.3 Enterprise environmental factors.4 Organizational process assets

.2 Tools and Techniques.1 Expert judgement.2 Communications skills.3 Interpersonal and team skills.4 Ground rules.5 Meetings

.3 Outputs.1 Change requests.2 Project management plan updates.3 Project documents updates

10.4 Monitor Stakeholder Engagement

.1 Inputs.1 Project management plan.2 Project documents.3 Work performance data.4 Enterprise environmental factors.5 Organisational process assets

.2 Tools and Techniques.1 Data analysis.2 Decision making .3 Data representation.4 Communications skills.5 Interpersonal and team skills.6 Meetings

.3 Outputs.1 Work performance information.2 Change requests.3 Project management plan updates.4 Project documentation updates

ProjectStakeholder Management




©2020 ‐ 232 ‐

Project Life Cycle

• Because each project is unique we must be careful to manage it since there is always at least some part of the project that we have never done before.

• To assist in managing projects we normally break the activities up into a number of phases.

• Phases are important because:

– They allow for finer control and management.

– Projects are easier to describe and communicate.

– Decision points at the end of phases allow us the opportunity to review progress and make decisions about future work.

– Phases of activity can be associated with broader organisational financing and scheduling arrangements.

463

Project Life Cycle

• Phases normally end with some form of deliverable.

• In some respects, then, we can consider a phase as a mini‐project that has resources, a beginning and an end, and so on—we can therefore manage it properly.

• The set of all phases is called the project life cycle.

• There are a number of project life‐cycle models adopted by different organisations. While they are largely very similar, they have slightly different phases, end points, reviews, and so on, depending on the unique needs of the industry and the organisation.

• All project life cycles have a number of common elements.

464



©2020 ‐ 233 ‐

Project Life Cycle

• Resource usage. At the start, the levels of staffing, finance and other resources are relatively low. As the project progresses, the utilisation increases and then diminishes rapidly as the product is completed and delivered.

465

Initial Phase Final PhaseIntermediate Phases

Start FinishTime

Res

ou

rce

Lev

els

Rate of effort

Accumulative effort

Project Life Cycle466

fast

fast

slow

slowslow

slow

Time

100%

0%

Per

cent

age

Com

plet

e

A

B

0



©2020 ‐ 234 ‐

The Importance of Project Definition467

65%

5% 10%

25% 10%

85%

% of Potential Cost or Efficiency Gains Achieved or Lost

% of Total Project Cost for Typical Project

Requirements Identification, Strategy Development, and Initial Risk Assessment

Build and Introduction Into Service

The Importance of Project Definition468

High

Low

Impact of problem definition(ease of making changes)

Resource levels(cost of making changes)

Time



©2020 ‐ 235 ‐

Typical Project Life Cycles469

Conceive Develop Implement Terminate

Gather dataIdentify needEstablish:

Goals, objectivesBasic economicsFeasibilityStakeholdersRisk levelStrategyTeam

Estimate resourcesIdentify alternativesPresent proposalGain approval

Appoint teamConduct studiesDevelop scopeEstablish:

Master planBudgetCash flowWBSPolicesProcedures

Assess risksConfirm justificationPresent brief

Set up organisationSet up communicationsMotivate teamDetail technical requirementsEstablish

Work packagesDetailed scheduleInformation control systems

Procure goods and servicesExecute work packagesDirect/monitor/forecast/control:

ScopeQualityTimeCost

Resolve problems

Finalise productsReview and acceptTransfer responsibilityEvaluate productDocument resultsRelease/redirect resourcesReassign project team

Simple Project Life-cycle Phases


Implementation

Leve

l of E

ffort

Time



©2020 ‐ 236 ‐


NEED

DISPOSAL

PreliminaryDesign

DetailedDesign and

Development

Operational Useand

System Support

Constructionand/or

Production

ACQUISITIONPHASE

UTILISATIONPHASE

ConceptualDesign

NEED

DISPOSAL

PreliminaryDesign

DetailedDesign and

Development

Operational Useand

System Support

Constructionand/or

Production

ACQUISITIONPHASE

UTILISATIONPHASE

ConceptualDesign

NEED

DISPOSAL

System Design and AnalysisOperational Use

andSystem Support

Constructionand/or

Production

ACQUISITIONPHASE

UTILISATIONPHASE

Systems Engineering—Blanchard, et al


Australian Department of Defence

Need Requirements Acquisition In Service Disposal


Risk Mitigationand RequirementsSetting

Acquisition In Service &Disposal

Pre-FPR

Post-FPR



©2020 ‐ 237 ‐


US Department of Defense

Concept and

Technology

Development

System Development

and Demonstration

Production and

DeploymentSupport

Sustainment andMaintenance

Systems Acquisition(Engineering Development,

Demonstration,Production, and Deployment)

Pre-SystemsAcquisition


Software Development—Waterfall Model

REQTSANALYSIS

SYSTEMDESIGN

PROGRAMDESIGN

CODING

TESTING(Unit, Integration

System, Acceptance)

OPERATION& MAINT



©2020 ‐ 238 ‐

Incremental Development475

Increment 1 Increment 2 Increment n

Final system scope

Kernel

Increment 1 scope

Increment 1 Increment 2 Increment n

Kernel Kernel

ReqSet

Evolutionary Development476

Build 1 Build 2 Build n

Final system scope

Build 1 Build 2 Build n

Build 1 scope

InitialReqs

FurtherReqs

FurtherReqs



©2020 ‐ 239 ‐

Overlapping Incremental Builds477

Build 2

Build n

Time

RBL1 RBL2 RBLn

Build 1

Build nfielded

Build 2fielded

Build 1fielded

ReqSet

Overlapping Evolutionary Builds478



©2020 ‐ 240 ‐

Spiral Development479

Cumulative cost

Evaluate alternativesidentify, resolve risks

Determine objectives,alternatives, constraints

Develop andverify next-level product

Plan next phases

RiskanalysisRisk

analysisRiskanalysis

Riskanalysis

Prototype1

Prototype2

Prototype3

Operationalprototype

Simulations, models, benchmarks

Concept ofoperation Sof tware

requirements Sof tware productdesign

Detaileddesign

Requirementsvalidation

Design validationand verif ication

Implementation Acceptancetest

Integrationand test

Unittest

Code

Developmentplan

Integrationand test plan

Requirements planLife-cycle plan

Review

Other Project Life Cycles480

Representative Life Cycle of a Pharmaceuticals Project


Drug Sourcing

ScreeningLeadIdentified

PreclinicalINDWorkup

FileIND

Patent Process

Discovery ScreeningPreclinicalDevelopment

Ten Plus Years

Registration Workup Post-submission Activity

Phase IClinicalTests

Phase IIClinicalTests

Phase IIIClinicalTests

Formulation Stability

Process Development

FileNDA Post-registration Activity

APPROVAL

Toxicology

Metabolism



©2020 ‐ 241 ‐

481Project Managementand

Systems EngineeringP

MB

OK

Kn

ow

led

ge

Are

a

IEE

E 1

220

EIA

/IS

63

2

AN

SI/

EIA

63

2IS

O/I

EC

152

88

Integration Management

Scope Management

Time Management

Cost Management

Quality Management

Resource Management

Communications Management

Risk Management

Procurement Management

Stakeholder Management

SEStandard

PM and SE482

Construction&/or Production

Utilization Phase

RetirementPhase


Project Management

ISO/IEC 15288

ConceptualDesign

IEEE 1220

Detailed Design& Development

PreliminaryDesign

AcquisitionPhase



©2020 ‐ 242 ‐

Summary

The ten knowledge areas of the PMBOK.

• Integration Management

• Scope Management

• Schedule Management

• Cost Management

• Quality Management

• Resource Management

• Communications Management

• Risk Management

• Procurement Management

• Stakeholder Management

483

Introduction toProgram Management



©2020 ‐ 243 ‐

Program Management

A program is a group of related projects managed in a coordinated manner to obtain benefits not available from managing them individually.

Program management is the application of knowledge, skills, tools and techniques to meet program requirements.

Source: PMI website

485

CLC Programs: Optimise Capability486

“A group of related Projects, Products, and Program

activities that are managed in a coordinated way to optimise

the capability outcome within allocated resources.”


ProgramAcquisition















©2020 ‐ 244 ‐

CLC Programs and Systems487




One system … Main Battle Tank, for example.


CLC Programs and Systems488




One system … Main Battle Tank, for example.

Multiple related systems…Combat Vehicles Program eg


ProgramProject 1: System 1

Project 2: System 2

Project 3: System 3

Pre-Project 4:System 4














©2020 ‐ 245 ‐

Program Management

• Who needs to know how Programs work:

– those responsible for Programs )Program Sponsors and Managers); and

– those who are part of a Program (Project and Product Managers).

489

CLC Programs

• The common features of Programs:

– Group of related interdependent Projects, Products and activities that are expected to contribute to an overarching objective.

– Constituent Products, Projects, and activities are managed mostly separately and will likely be at different phases of the capability life cycle.

– The Program authority (Sponsor or Manager) is accountable for the combined outcomes.

490



©2020 ‐ 246 ‐

Benefits of Programs

• Support integrated capability.

• Deliver efficiencies.

• Governance and management layer:

– coordinate and synchronise related activities;

– reconcile conflicts between related efforts; and

– umbrella reference for Projects and Products.

• Traceability from Projects/Products to strategic outcomes.

491

Program Features

• A Program is:

– a group of related Projects, Products and activities;

– an enduring capability outcome;

– supports joint capability outcomes;

– managed by a Program Sponsor; and

– helps optimise capability outcomes within resources.

492



©2020 ‐ 247 ‐

Program: Delivers Capability Over Time(enduring capability from multiple systems)

493

Current Systems

2019 2025 2030

System 1

System 2

System 3

System 4

System 1

+

System 2

+

+

+


System 3

System 2

System 6

+


+

System 2

System 6

+System 7


2035

Program: Delivers Capability Over Time(enduring capability from multiple projects)

494

Current Systems

2019 2025 2030

System 1

System 2

System 3

System 4

System 1

+

System 2

+

+

+


System 3

System 2

System 6

+


+

System 2

System 6

+System 7


2035

Project

Project



©2020 ‐ 248 ‐

Program: Delivers Capability Over Time(housing, transport, recreation)

495

2019 2025 2030

2 BR Apartment

3 BR House

Carport

+

Car: 4 cyl Hatch

+

+

+

Changing circumstances, Technology changes, Obsolescence and replacement

4 BR House

4 car garage

Car 4WD

+

Required lifestyle ‘capability’: aspirations…

+Car: Electric

Townhouse

2035

2 BR Apartment

+

Solar incl car charging/ battery

Car: 4 cyl Hatch

Defence Challenge: Different Types of Programs496

• IIP Capability Program

• IIP Corporate Enabler Programs

• Delivery Programs, such as Active Electronically Scanned

Array (AESA) Radar SPO

• ‘Sub-Programs’ such as Space Situational Awareness

IAMD

Cyber (common

technology)

Fuel (common-use commodity)

Facilities(management)

IAMD (integrated capability)



©2020 ‐ 249 ‐

Three Types of Defence Programs

• System of Systems (SoS)—integrated capability.

• Family of Systems (FoS)—common‐use systems.

• Portfolio of Systems (PoS)—management grouping.

497


Defence Programs: Three Grouping Types498

Defence Programs

System of Systems (SoS)

Family of Systems (FoS)

Portfolio of Systems (PoS)

• Joint capability • operationally related • e.g. IAMD Program

• common-use systems• common requirements and

design• efficiencies (economies of

scale in production, acquisition, support)

• e.g. radar program

• operationally independent• managerially convenient• largely unrelated attributes • related by budget and mgt• e.g. infrastructure program

(E&IG)




©2020 ‐ 250 ‐

Relationships Dictated by Type of Group499

System of Systems

• Operationally related• can be common budget

Operational

Technical

Management

Program Relationships

Family of Systems

• Related technical reqs• economies of scale• can be common budget

Portfolio of Systems

• related budget and management

• Administrative convenience

Define operational dependencies (eg CONOPS, IERs) between constituent systems/elements within and across Programs.

Based on operational dependencies define technical interdependencies, shared requirements (eg interface), impacted system requirements, and standards

Manage all aspects of the SoS: CONOPS definition, stakeholder relationships, technical alignment (CM), funding, scheduling of system development, upgrades, coordination of contracting etc

Define technical commonality or relationships ie common, shared requirements and standards

Manage stakeholder relationships (incl international) , technical alignment (CM), funding, coordination of system development and upgrades, coordination of contracting etc

Manage stakeholder relationships, funding, resourcing, contracting

Type of Grouping

Constituent systems related in terms of …

Defence Programs: Three Grouping Types500

Defence Programs

System of Systems (SoS)

Family of Systems (FoS)

Portfolio of Systems (PoS)

• Joint capability • operationally related • e.g. IAMD Program

• common-use systems• common requirements and

design• efficiencies (economies of

scale in production, acquisition, support)

• e.g. radar program

• operationally independent• managerially convenient• largely unrelated attributes • Related by budget and mgt• e.g. infrastructure program

(E&IG)

Source: M.W. Maier, Architecting a portfolio of systems, Systems Engineering. 2019;1-13, wileyonlinelibrary.com/journal/sys



©2020 ‐ 251 ‐

Relationships Dictated by Type of Group501

System of Systems

• Operationally related• can be common budget

Operational

Technical

Management

Program Relationships

Family of Systems

• Related technical reqs• economies of scale• can be common budget

Portfolio of Systems

• related budget and management

• Administrative convenience

Define operational dependencies (eg CONOPS, IERs) between constituent systems/elements within and across Programs.

Based on operational dependencies define technical interdependencies, shared requirements (eg interface), impacted system requirements, and standards

Manage all aspects of the SoS: CONOPS definition, stakeholder relationships, technical alignment (CM), funding, scheduling of system development, upgrades, coordination of contracting etc

Define technical commonality or relationships ie common, shared requirements and standards

Manage stakeholder relationships (incl international) , technical alignment (CM), funding, coordination of system development and upgrades, coordination of contracting etc

Manage stakeholder relationships, funding, resourcing, contracting

Type of Grouping

Constituent systems related in terms of …

Program (SoS) T&E is also Important502

Program OT&E



©2020 ‐ 252 ‐

Program/SoS Perspectives503

• Operational Interdependencies: – CONOPS (operational, performance

objectives) for SoS.

– Derived Operational Needs, Reqs for each Node/ system.

– IERs, Interface type (options) such as voice, TDL, fuel appropriate to scenarios.

• ‘Technical’ Interdependencies: – Individual overarching system

operational needs (OCD), functionality and performance requirements Functional dependencies between systems.

– Interface Requirements incl Standards.

• Management Interdependencies: – e.g. Schedule coordination across CLC

phase and event for each system.

– Interface Control Board.

Effective Program Management

• SoS Operational effects and CONOPS: What are expected operational effects and contribution of each constituent system.

• SoS Architectures: definition and maintenance.

• SoS/Program Planning: e.g. plan (incl schedule) alignment.

• SoS Needs and Requirements development: defining common requirements, reconciling conflicts, aligning system and interoperability requirements.

• Program/SoS Governance: configuration control, decision‐making, deconfliction, ICWGs.

• ...

504



©2020 ‐ 253 ‐

Effective Program Management

• …

• Program Risk reduction: e.g. SoS modelling and simulation, analyses

• Multi‐Project Solicitation and Contracting: aligning, leveraging tendering and contracting activities across constituent activities

• SoS and system Design and Development: aligning, coordinating information exchange and design decisions across Projects

• Multi‐Product FIC: aligning, leveraging synergies across Projects/Products

• Program V&V/T&E: delivering interoperable outcomes

505

System of Systems Engineering

• Program Management can be aided by System‐of‐Systems thinking

• System‐of‐Systems problems have been described (by DeLaurentisand Maier) as problems which exhibit a number of the following traits :

– Operational Independence of Elements

– Managerial Independence of Elements

– Evolutionary Development

– Emergent Behaviour

– Geographical Distribution of Elements

– Interdisciplinary Study

– Heterogeneity of Systems

– Networks of Systems

506



©2020 ‐ 254 ‐

System or System‐of‐Systems (SoS)?507

System

Subsystem Subsystem

Subsystem Subsystem

System-of-Systems

System System

System System

A system is an integration of a number of co‐dependent subsystemsthat are interconnected

permanentlyto achieve a common purpose.

An SoS is an integration of a number of independent systems that are interconnected for a period of time

to achieve a common purpose.

Hierarchy of SoS / System / Sub‐system508

System: Constituent

SystemElement

SystemElement

Sub-System Sub-System

SystemElement

SystemElement

SystemElement

SystemElement

SystemElement

SystemElement

Sub-System Sub-System

SoS: System-of-Interest

System: Constituent System: ConstituentSystem: Constituent

Independent Systems Integrated for a period of time



©2020 ‐ 255 ‐

SoS Engineering (SoSE)

• The aims of the Systems Approach and SoSE are to:

– optimise the outcomes delivered through the new systems (Projects) and legacy (Products) which together satisfy the Program objectives;

– provide techniques that enable decision‐makers to make informed decisions on architectural solutions for System‐of‐Systems problems across technical performance and costs; and

– provide a deliberately managed approach to the definition, design and delivery of capability systems in a Program across Projects and Products.

509

OCD Approach for Programs 510

POCD Sections 1‐3: What do we need?

POCD Section 4: What do we have?

POCD Sections 5/6: What can we do to resolve?

SoS SoSe.g. SoS SoS POCD/Architecture



©2020 ‐ 256 ‐

Developing SoS Needs and Requirements 511

System

SystemElement

SystemElement

Sub‐System Sub‐System

SystemElement

SystemElement

SystemElement

SystemElement

SystemElement

SystemElement


System of Systems

System SystemSystem

Independent Systems Integrated for a period

of time Program

Hierarchy of a SoS to System 512

System

SystemElement

SystemElement


SystemElement

SystemElement

SystemElement

SystemElement

SystemElement

SystemElement


System of Systems

System SystemSystem

Independent Systems Integrated for a period

of time

What does the system have to do (function) and what other functions does it interact with (interface)?



©2020 ‐ 257 ‐

Individual Systems Needs Hierarchy (OCD) 513

1 2 n

0

...

1.1 1.2 1.n...

1.1.1 1.1.2 1.1.n...

n.1 n.2 n.n...

n.n.1 n.n.2 n.n.n...


Level 1

Level 2

Level 3

CI

COI

MOE

Level 4 MOP

Level n TPM

….

….

Mission

Functions Interfaces

The functionality is a property of the system or component, independent from whom the system or component is intended to interactwith.


System

System of Systems

System SystemSystem

1 2 n

0

...

1.1 1.2 1.n...

1.1.1 1.1.2 1.1.n...

n.1 n.2 n.n...

n.n.1 n.n.2 n.n.n...


Level 1

Level 2

Level 3

CI

COI

MOE

Level 4 MOP

Level n TPM

….

….

Mission

1 2 n

0

...

1.1 1.2 1.n...

1.1.1 1.1.2 1.1.n...

n.1 n.2 n.n...

n.n.1 n.n.2 n.n.n...


Level 1

Level 2

Level 3

CI

COI

MOE

Level 4 MOP

Level n TPM

….

….

Mission

1 2 n

0

...

1.1 1.2 1.n...

1.1.1 1.1.2 1.1.n...

n.1 n.2 n.n...

n.n.1 n.n.2 n.n.n...


Level 1

Level 2

Level 3

CI

COI

MOE

Level 4 MOP

Level n TPM

….

….

Mission

1 2 n

0

...

1.1 1.2 1.n...

1.1.1 1.1.2 1.1.n...

n.1 n.2 n.n...

n.n.1 n.n.2 n.n.n...


Level 1

Level 2

Level 3

CI

COI

MOE

Level 4 MOP

Level n TPM

….

….

Mission

SoS Mission

SoS Level 1

SoS Level 2

1 2 n…

1.1 1.n…1.2 2.1 2.n…2.2 n.1

n.n…n.2

Functions (and their performance)

Interfaces

Overarching Operational Effect

POCD(based on logical architecture)

Individual OCDs

SoS functions

Allocation of functions to

nodes/systems

SoS functions



©2020 ‐ 258 ‐


System

System of Systems

System SystemSystem

1 2 n

0

...

1.1 1.2 1.n...

1.1.1 1.1.2 1.1.n...

n.1 n.2 n.n...

n.n.1 n.n.2 n.n.n...


Level 1

Level 2

Level 3

CI

COI

MOE

Level 4 MOP

Level n TPM

….

….

Mission

1 2 n

0

...

1.1 1.2 1.n...

1.1.1 1.1.2 1.1.n...

n.1 n.2 n.n...

n.n.1 n.n.2 n.n.n...


Level 1

Level 2

Level 3

CI

COI

MOE

Level 4 MOP

Level n TPM

….

….

Mission

1 2 n

0

...

1.1 1.2 1.n...

1.1.1 1.1.2 1.1.n...

n.1 n.2 n.n...

n.n.1 n.n.2 n.n.n...


Level 1

Level 2

Level 3

CI

COI

MOE

Level 4 MOP

Level n TPM

….

….

Mission

1 2 n

0

...

1.1 1.2 1.n...

1.1.1 1.1.2 1.1.n...

n.1 n.2 n.n...

n.n.1 n.n.2 n.n.n...


Level 1

Level 2

Level 3

CI

COI

MOE

Level 4 MOP

Level n TPM

….

….

Mission

SoS Mission

SoS Level 1

SoS Level 2

1 2 n…

1.1 1.n…1.2 2.1 2.n…2.2 n.1

n.n…n.2

Functions (and their performance)

Interfaces

Overarching Operational Effect

POCD(based on logical architecture)

Individual OCDs

SoS functions

Allocation of functions to

nodes/systems

SoS functions

Common operational context

Operational, functional and performance drivers

Prior to CLC Redesign516


Project 1

FPSs

TCD

• Projects and their needs and requirements frequently:– un‐aligned and – not well coordinated (if

at all)

• Needs and Requirements development started at Project layer

Project 2 Product 3

FPSs

TCD

OCD 3

FPSs

TCD

OCD 1 OCD 2



©2020 ‐ 259 ‐



Program 1


Program Strategy


Project 1

FPSs

IPMP 1

JCNS 1

Project 2 Product 3

OCD 1




• ‘Town Plan’

JCN 1

PES 1

FPSs

IPdMP

JCNS 3

OCD 3

JCN 3

PES 3

FPSs

IPMP 2

JCNS 2

OCD 2

JCN 2

PES 2

TCD 1 TCD 2 TCD 3

Re‐use/ reference content

Program Documents: Ref for Requirements518


Program 1


Program Strategy


Project 1

Sect 1-4

FPSs

TCD

PES/IPMP

Efficient: leverage common content in ‘parent’

Aligned: Related Projects and Products have common reference

Coordinated: Related Projects, Products and activities are managed together

JCN/

JCNS 1

PES/ IPMP

JCN/ JCNS 2

PES/IPMP

JCN/

JCNS 3

Project 2 Product 3

FPSs

TCD

OCD

FPSs

TCD

Sect 5-7

OCD 1

Re‐used/ referenced content

New content

Sect 1-4

Sect 5-7

OCD 2



©2020 ‐ 260 ‐

SoS Architecture Practice for Programs

• “An architecture is the structure of components, their relationships, and the principles and guidelines governing their design evolution over time” (IEEE 610.12‐1990).

• SoS (and therefore Program) architectures provide:

– details on how constituent systems will be used (CONOPS);

– internal and external operational, functional and technical relationships and dependencies among the constituent systems;

– end‐to‐end functionality and flows of information and data (and other resources); and

– provides a common and enduring reference for decisions for Proposals, Projects and Products.

Source: Based on SEBoK Architecting approaches for SoS

519

Architectures 520

Operational View

Warfighter Relationships and Information Needs

Technical View

Prescribes Standards and Conventions

Systems View

Relates Capabilities and Characteristics to Operational

Requirements

Technical Criteria for implementing interoperability

Processing and Levels of Information Exchange Requirements

Systems Associations to Nodes, Activities, Needlines, and Requirements




©2020 ‐ 261 ‐

SoS/Program Architectures

• Provides a common and enduring reference for decisions for Proposals, Projects and Products.

• “From the single‐system community's perspective, its part of the SoS capability represents additional obligations, constraints and complexities. Rarely is participation in an SoS seen as a net gain from the viewpoint of single‐system stakeholders”

(Source: Rebovich 2009)

• SEBoK raises the practical problems and potential solutions for situations in which the SoS architecture may be constrained by a reluctance to make changes or invest in the constituent systems, which could be very mature (e.g. in sustainment) or currently productively supporting other uses. (Source: SEBoK Architecting approaches for SoS)

521

Introduction to Support Concepts and ILS



©2020 ‐ 262 ‐

Key Points

• Defence frameworks in this area are not ‘orthogonal’.

• ILS is a pivotal practice to realise Mission and Supportsystem ‘balance’ to optimise costs (LCC).

• Progressive ‘build’ of definition of the Support Concept(Initial, Final) realised through ILS plans.

• Support Concept can be viewed as being made up of fiveconstituent capability concepts corresponding to:

523

Operating Support

Engineering Support

Maintenance Support

Supply Support

Training Support

Support System Constituent

Capabilities (SSCC)

Capability Perspectives—Recap 524


Mission System

FIC









©2020 ‐ 263 ‐

Preparedness Force Structure

Force elements capable of delivering specific

effects and countering threats

Maintaining the force structure at an appropriate state of

preparedness for a range of potential operations

Defence Capability 525


Being ready to deploy on

military operations.




(Sustain, In-Service)



©2020 ‐ 264 ‐




Supporting it In‐ServiceEquipment

Mission and Support Systems



©2020 ‐ 265 ‐


Capability System


Used to focus on bringing the system into being

(equipment and its use)

What is needed to support it during the In‐service Phase




©2020 ‐ 266 ‐

Defence Capability

• Capacity or ability to achieve an operational effect.

• Operational effect relies on a combination of contributions or inputs:

– Fundamental Inputs to Capability,

– not just the equipment, and

– all inputs must be in place to deliver operational effect.

• A deficiency in any one adversely impacts the whole.

531


Organisation


SupportFacilities


Major Systems

Industry

Supplies

Capability (System)

Comprehensive, Structured



©2020 ‐ 267 ‐



• Defence groups support elements that comprise Support System through five functional constituent capabilities:




– Supply Support.


534



©2020 ‐ 268 ‐

Capability System535

Personnel

Collective Training

Facilities and Training Areas

Supplies

Support

Organisation


Industry

Operating Support

Engineering Support

Maintenance Support

Supply Support

Training Support

Mission System

Support System

Effect / Outcome

SSCC

FIC

(Materiel System)

Capability Perspectives 536


Mission System

FIC









©2020 ‐ 269 ‐

Capability Perspectives

These structures help:

• ensure everything is covered;

• define requirements of the mission system and its support system;

• delineate what each party (CM, CASG, E&IG, CIO etc organises);

• define who supplies the different elements; and

• define elements for which industry is contracted.

537

Logistics Terminology and Activities



©2020 ‐ 270 ‐

Defence Logistics Terminology

ADDP4.0 Defence Logistics: logistics is described as

“the science of planning and carrying out the movement and maintenance of forces”.

Logistics provides resources that:

• underpin combat power,

• positions those resources in the battle space,

• sustains them throughout the operation, and

• redeploys and regenerates them.*

*Ref: Defence Materiel Manual (Logistics) DMM (LOG) 04‐0‐001

Logistics

Logistics Context

• Contributing to the preparedness of the Australian Defence Organisation (ADO) through:

– Acquisition; and

– Support (through‐life) of military equipment and supplies.

Logistics

Source: Defence Materiel Manual (Logistics) DMM (LOG) 04‐0‐001

Preparedness

Maintaining the force structure at an appropriate state of preparedness for a range of potential

operations


Being ready to deploy on military operations




©2020 ‐ 271 ‐

• Materiel:

– design and development,

– acquisition,

– storage,

– movement,

– distribution,

– maintenance,

– evacuation and disposition of materiel;

• Personnel transportation;

• Facilities acquisition/construction, maintenance, operation, and disposition;

• Services acquisition or furnishing; and

• Medical and health support.

Logistics: Comprehensive View

Source: ADDP4.0 Defence Logistics

Logistics

• Materiel:


– acquisition,

– storage,

– movement,

– distribution,

– maintenance,




• Services acquisition of furnishing; and


Logistics: Comprehensive View


Logistics

Materiel Logistics



©2020 ‐ 272 ‐

• Materiel:


– acquisition,

– storage,

– movement,

– distribution,

– maintenance,




• Services acquisition of furnishing; and


Logistics: Comprehensive View Logistics

Materiel Logistics


Support Concept/s

ILS Plan

Materiel Logistics

Covers:

• Acquisition and sustainment of materiel.

• Includes the actions of:

– defining supportability requirements (see definition);

– monitoring sustainment outcomes;

– establishing and managing: repair pipeline, facilities, contracts; and

– defining stockholding policy, usage rates, demand management, performance management and disposal approach.

• Includes development of Materiel Logistics plans.

Logistics

Materiel Logistics



©2020 ‐ 273 ‐

Materiel Logistics

• Materiel Logistics brings together:

– discipline of Integrated Logistics Support (ILS); and

– planning and managing delivery of In‐Service Support (ISS).

• Where..

– In‐Service Support (ISS) involves:

• management; and

• execution of support activities.

Logistics

Materiel Logistics

ILS ISS

DEFLOGMAN Part 2, Volume 10, Chapter 3, Defence Policy on Integrated Logistic Support

Figuring out what

to do

Materiel Logistics

• Materiel Logistics brings together:

– discipline of Integrated Logistics Support (ILS); and

– planning and managing delivery of In‐Service Support (ISS).

• Where..

– In‐Service Support (ISS) involves:

• management; and

• execution of support activities.

Logistics

Materiel Logistics

ILS ISS

DEFLOGMAN Part 2, Volume 10, Chapter 3, Defence Policy on Integrated Logistic Support

Figuring out what

to do Doing it



©2020 ‐ 274 ‐

Integrated Logistics Support (ILS)

DEFLOGMAN* calls for ADO to apply principles and practices of ILS:

• during all phases of CLC;

• ensure that required Supportability and Materiel Sustainment outcomes achieved;

• ensure optimised LCC; and

• within operational, regulatory, legislative and contractual requirements and constraints.

*DEFLOGMAN Part 2, Volume 10, Chapter 3, Defence Policy on Integrated Logistic Support (Check)

Logistics

Materiel Logistics

ILS

Integrated Logistics Support (ILS)

ILS enables:

1. improved supportability* of Mission and Support Systems

2. to meet operation and preparedness requirements

3. while minimising Life‐Cycle Cost.

548

* Supportability: The degree to which Capability System design characteristics andplanned logistics support resources meet System operational and utilisationrequirements.



©2020 ‐ 275 ‐

Integrated Logistics Support 549

MissionSystem design

Acquisition Costs

Support System design

Sustainment Costs

1. 2.

For many years Defence focuson acquisition and acquisition

costs



Acquisition Costs


Sustainment Costs

1. 2.

Support and associated costs were often treated separately



©2020 ‐ 276 ‐

Integrated Logistics Support

• ILS drives recognition of the relationship between missionand support systems…


Acquisition Costs


Sustainment Costs

1. 2.


• … and the need for their definition and development to be addressed together.

3.


Acquisition Costs


Sustainment Costs

1. 2. ILS



©2020 ‐ 277 ‐


3.

MissionSystem

design/reqs

Acquisition Costs

Support System

design/reqs

Sustainment Costs

1. 2.

Mission system design drives support system requirements


3.


Acquisition Costs


Sustainment Costs

1. 2.

Mission system design drives support system requirements

TCO across acquisition and support costs drives Mission System design



©2020 ‐ 278 ‐


• ILS assists in:

– design and modification of supportable Mission Systems;and

– ensures Support System established and maintained.

555

Capability System


design and modification

established and maintained


• ILS is a disciplined approach to logistics planning and management throughout life‐cycle.

556




Logistics Planning Logistics Planning and Management

Logistics Management

ILS



©2020 ‐ 279 ‐


All activities for Supportability of Mission and its SupportSystem including:

• management,

• needs analysis and requirements determination,

• design and development,

• acquisition and procurement,

• Verification and Validation (V&V),

• Introduction Into Service,

• In‐Service Support,

• performance management, and

• Disposal.

557




ILS: Summary

• What: life‐cycle discipline for Supportability of a Materiel System.

• Why: to ensure operational and preparedness objectives are met at optimised LCC.

• When: throughout the materiel life cycle.

• How: through materiel management methodology which is:

– disciplined,

– controlled,

– methodical, and

– iterative.

558



©2020 ‐ 280 ‐

In‐Service Support (ISS)Logistics

Materiel Logistics

Logistics

ILS ISS

In‐Service Support (ISS)

• Management and execution of support activities to ensure continued attainment of the intended operational capabilities of the system or equipment during the In‐Service phase.

560





ISS



©2020 ‐ 281 ‐


• Delivered by integrated arrangement of Defence agencies and industry—that is, Support Service Providers (SSPs).

• Defence Delivery Group responsible for coordinating effort of these providers.

561

DSS Panel (79 Skill Sets at five Skill Levels) for:• Program Management Services;• Engineering and Technical Services;• Materiel Logistics Services;• Commercial Services;• Corporate Performance Services; and• Authoring and Writing Services.

Ref: Defence Materiel Manual (Logistics) DMM (LOG) 04‐0‐001

ISS delivered through Support System comprisingfive Support System Constituent Capabilities(SSCCs):


Materiel Logistics

Logistics

ILS ISS

SSCC



©2020 ‐ 282 ‐



Materiel Logistics

Logistics

ILS ISS

SSCC

Operating Support

Engineering Support

Maintenance Support

Supply Support

Training Support


Capabilities (SSCC)



Materiel Logistics

Logistics

ILS ISS

SSCC

Operating Support

Engineering Support

Maintenance Support

Supply Support

Training Support


Capabilities (SSCC)

Mission System

Support System

(Materiel System)



©2020 ‐ 283 ‐


• Defence groups support elements that comprise Support System through five functional categories:




– Supply Support.


565

SSCC Elements

1. Operating Support Capability.

– operating facilities system operators,





566



©2020 ‐ 284 ‐

SSCC Elements 567

1. Operating Support Capability. – operating facilities system operators,





Helicopter:

• Facilities system operators:

• Facilities to support helicopter operations (landing pad, hangar)• People needed to support these facilities? (groundcrew: aircraft marshallers)

• Support Equipment:

• Communications system between landing pad and pilot

• PPE (ear protection) • Specialist clothing (Hi‐Viz), PP

Landing crew manuals, SOPs

• Protocols and Interlocks to prevent hazards. Landing equipment (Recovery Assist, Secure, Traverse (RAST)

SSCC Elements

2. Engineering Support Capability.

– engineering facilities,







568



©2020 ‐ 285 ‐

SSCC Elements

2. Engineering Support Capability. – engineering facilities,







569

Scenario:

1. Faulty system (design oversight, maintenance lapse, operating outside the use

envelope) e.g. overseas system not designed to Australian conditions

2. Needs an investigation and remedy

3. Technical undertaking to determine a way forward

4. Implement it

SSCC Elements

2. Engineering Support Capability. – engineering facilities,







570

FFG example:• Evidence of fatigue: cracks superstructure, across the side of the ship• Investigation: Naval Architect, SE, Specialists engineering (materials) • Remedy: Saddle strip along the side of the hull piece of steel to stiffen up the

side of hull.• Engineering Support processes:

• Levels of engineering ‘sign off’: Chief Engineer (regulatory authority approved)

• Judgement of Significance



©2020 ‐ 286 ‐

SSCC Elements

3. Maintenance Support Capability.

– develop, establish and integrate a maintenance support system capable of sustaining a system throughout its life







571

SSCC Elements

3. Maintenance Support Capability. – develop, establish and integrate a maintenance support system capable of sustaining a system

throughout its life







572

CEAFAR Radar ‘Faces’

1. High reliability, only OEM can touch (except some modules below)

2. Timing for removal of faces progressed due to design and evidence:

• 18 months

• 3 years

• 8 years

3. Impact on cost, availability, maintenance regime



©2020 ‐ 287 ‐

SSCC Elements

4. Supply Support Capability.

– supply facilities,






– spares, and

– packaging.

573

SSCC Elements

4. Supply Support Capability. – supply facilities,






– spares, and

– packaging.

574

Defence (incl warehousing, MILIS) Commonwealth Funded Contractor Managed (CFCM) of a specific system

(ESM) Contracted out services: CFCM and distribution services (Linfox) Global Supply Chain: F35 Autonomic Logistics Information System (ALIS) The F 35 program's maintenance concept is:

any F-35 to be maintained in any F-35 maintenance facility, and all F-35 parts in all bases to be globally tracked and shared as needed.



©2020 ‐ 288 ‐

SSCC Elements

5. Training Support Capability.

– training facilities






575

SSCC Elements

5. Training Support Capability. – training facilities






576

Combat System training method:

Part‐task trainer:

o e.g. keyboard

o e.g. combat system

o e.g. radar system…

Command team trainer

Real ship: real and simulated inputs

At sea

Vehicle training method :

a. Car

b. Truck

c. Armoured vehicle

Formula 1:

a. Go carts

b. 500 series /open wheelers

c. F1



©2020 ‐ 289 ‐

Logistics Support actions across the CLC




Gate 0 Gate 2Gate 1

• Develop Support Concept (draft In-Service Support Concept (ISS) for input into P/OCD)

• ILSP Analysis Support Options Analysis and Costing

• Draft Support Concept for input into PES

• Conduct early Support Options Analysis and Costing

• Conduct ILS Analysis

• Develop ILSP• Develop

LSAR • LCC Baseline

• Finalise ILS Analysis • Produce complete LSAR • ISS arrangements

• Spares• Support equipment• Logistics data

• Organisational responsibilities defined in LSC for:

• CASG• Services• Support Groups• Contractors • Foreign Military

• Initial MSA drafted• Engineering,

Maintenance, Supply Support and Technical Management Plans

• Draft Disposal Plan• AIS Documentation• Transition Plan

• Multi-Agency support defined by LSC and Detailed ILS Plans

• ISS delivery covering engineering, maintenance, supply, operating and training support

• ISS management including annual support planning, performance management, quality management and contracting

• Regulatory compliance• Budgetary and Financial

incl LCC review• Risk Management• Annual Review of ILSP• MSA negotiation• Through Life Support

Review Ref: Defence Materiel Manual (Logistics) DMM (LOG) 04‐0‐001

Designing the Support System (all SSCCs)

• Design of Support System is largely the responsibility of the ILS program based on:

• Support Concept/s,

• Support processes, procedures,

• Resource requirements

• Ability to integrate with engineering efforts

578


Support SystemDesign

Support Concept/s

SSCCs

ILSP

ISS



©2020 ‐ 290 ‐

Role of a Support Concept

Support Concept

• Support Concept: A broad statement of the type and extentof support that will be established to support the plannedoperational use of the Capability System

• Materiel Systems must meet performance requirementsspecified in the Capability Definition Documents’ (CDDs’)Support Concept (SC) at the optimal LCC.

580




©2020 ‐ 291 ‐

Support Concept581

Support Concept

Operating Support Concept

Engineering Support Concept

Maintenance Support Concept

Supply Support Concept

Training Support Concept

SSCC

Support Concept: Made up of support concepts for each of the SSCC

(Of the Capability)

Ten Support Elements (old approach)

• Engineering Support;

• Maintenance Support;

• Supply Support;

• Training Support;

• Packaging, Handling, Storage and Transportation;

• Facilities;

• Support and Test Equipment;

• Personnel;

• Technical Data; and

• Computer Support.

582



©2020 ‐ 292 ‐

ILS: Delivering the Support Concept

ILS principles and practices are the means by which the Support Concept is realised and maintained:

• supportability achieved;

• support requirements defined that match Support Concept;

• support resources are acquired and implemented; and

• support provided In‐Service phase; and

• support requirements addressed for Disposal phase.

583


ILS Objectives During In‐Service Phase

• ILS Objectives During In‐Service Phase:

– maintaining or improving performance and preparedness,

– limit increases to or reducing LCC, and

– managing the logistics support implications of changes to the Materiel System.

• Logistic Support Analysis (LSA), is:

– structured process;

– defines, analyses and quantifies logistics support requirements throughout life‐cycle; and

– principal analytical tool of ILS.

584




©2020 ‐ 293 ‐

Developing a Support Concept

Support Concept

• A Support Concept describes a Support System including:

– goals,

– functions,

– organisations,

– processes, and

– resources.

586



Support Concept/s



©2020 ‐ 294 ‐

Support Concept

• A Support Concept may describe:

– a perceived future Support System, or

– high-level view of an existing SupportSystem.

• Used to define Support System requirements.

• Used as a basis to develop the ProjectIntegrated Logistics Support Plan (ILSP).

587


Support Concept/s

SSCC


Support Concept

• Used as a basis to develop the ProjectIntegrated Logistics Support Plan (ILSP).

• The ILSP details:

– how Support Concepts are to be realised;and

– details responsibilities for implementingaspects of the proposed Support System.

588


Support Concept/s

SSCC

ILSP




©2020 ‐ 295 ‐

Support Concept

• Support Concept documented as part of:

– Operational Concept Document(OCD); or

– Description of Requirement (DOR)*.

• Support Concept may be:

– annex to OCD, or

– separately documented and approved.

• Support Concepts must be integrated intothe OCD for Solicitation and Gateapprovals.

589

*Ref: DEFLOGMAN Part 2, Volume 10, Chapter 3, Defence Policy on Integrated Logistic Support,

Annex

Support Concept

OCD

DOR

OSI ?

Support Concept

• Developed progressively in support of the capability‐definition and acquisition processes, and is required:

– prior to Gate 1 Approval;

– for inclusion in each materiel acquisition solicitation package;

– for inclusion in each contract; and

– prior to Gate 2 Approval.

590

*Ref: DEFLOGMAN Part 2, Volume 10, Chapter 3, Defence Policy on Integrated Logistic Support



©2020 ‐ 296 ‐

Support Concept591




Gate 0 Gate 2Gate 1

Initial Support Concept:

Pre-Gate 0,1

Support Concepts for

each potential Mission System solution-class


single-solution class

Final Support Concept: Pre-

Solicitation

Acquisition Support Concept

Updated Support Concept for preferred tendered solution.

Updated Support Concept during

Acquisition

Updated Acquisition

Support Concept


Support Concept592




Gate 0 Gate 2Gate 1

Initial Support Concept:

Pre-Gate 0,1


each potential Mission System solution-class


single-solution class

Final Support Concept: Pre-

Solicitation

Acquisition Support Concept

Updated Support Concept for preferred tendered solution.

Updated Support Concept during

Acquisition

Updated Acquisition

Support Concept


Support concepts will likely be difference for each solution-class



©2020 ‐ 297 ‐

Support Concept593

Support Concept

Operating Support

Engineering Support

Maintenance Support

Supply Support

Training Support

SSCC

Support Concept: Made up of support concepts for each of the SSCC

Support Concept

Define for each SSCC:

• Concepts

• Requirements

• Constraints

For: Mission and Support System

Consistent with:

• Key Policies and Standards

• Future Joint Logistic Concept (FJLC)



©2020 ‐ 298 ‐

Example: Maintenance Support Concept595

Operational Level Maintenance

Intermediate Level

Maintenance

Deeper (Depot) Level

Maintenance

• Organisation• Location• Customer• Key

Performance Indicators





Intellectual Property / Technical Data

Three key considerations:

1. IP (Practical view): Technical Data + Legal Rights

2. Seek IP and TD (for a system) that you need to:

a) Use,

b) Maintain, and

c) Integrate the system

3. Make sure that the necessary IP rights are sought from Prime Contractors and their Subcontractors.

596



©2020 ‐ 299 ‐

Logistics‐related Terminology

Definitions

• Supportability: The degree to which Capability System design characteristics and planned logistics support resources meet System operational and utilisation requirements.

• Life‐Cycle Costs: The total costs (both direct and indirect) of a capability system over its entire life‐cycle, including costs associated with concept development, acquisition, operations, logistics support, and disposal.

• Sustainability: A force’s ability to continue to conduct operations, measured in terms of the personnel, equipment, facilities and consumables necessary for the force to complete its assigned operational tasks.

598




©2020 ‐ 300 ‐

Definitions

• Support Concept: A broad statement of the type and extent of support that will be established to support the planned operational use of the Capability System

• Integrated Logistic Support Plan: The ILSP is the primary logistics support management document that identifies all logistics support requirements and activities during the Acquisition, In‐Service and Disposal phases of the Capability life‐cycle. The In‐Service ILSP is used to denote that Plan used once the Capability has been accepted into service.

599


Definitions

• Capability System: This is a specific combination of the FIC, and is used as the primary management framework for the development and delivery of an endorsed level of operational capability.

• Materiel: All items of military equipment and related spares, repair parts and support equipment, (excluding real property, installations and utilities), necessary to equip, operate, maintain and support military activities without distinction as to its application for administrative or combat purposes.

600




©2020 ‐ 301 ‐

Definitions

• Mission System: The hardware and software used to accomplish the primary mission of the Defence materiel item. This element includes all integration, assembly, test and check‐out, as well as all technical and management activities associated with individual hardware/software elements.

• Support System: The organisation of hardware, software, materiel, facilities, personnel, data, processes and services required to enable the Mission System to be effectively operated and supported to meet its operational requirements.

601


Definitions

• Sustainment: The management and provision of products and services needed to meet the preparedness and performance requirements of a Materiel System, from the time of acceptance into operational service until disposal at an optimised life‐cycle cost.

• Materiel Sustainment Agreement: An agreement between a Capability Manager and DMO, which states in concise terms what In‐Service Support services and products the DMO (as supplier) will deliver, for how much and when.

602




©2020 ‐ 302 ‐

Definitions

• Logistic Support Analysis: The selective application of analytical techniques to: cause logistics support considerations to influence the design requirements and design processes of Capability Systems; and define logistics support requirements that are optimally related to the design, and optimise the logistics support required by the design, consistent with specified preparedness requirements.

• Logistic Support Analysis Record: That portion of Logistic Support Analysis documentation consisting of detailed data pertaining to the identification of logistics support resource requirements of a Capability System.

603


Integrated Logistics Support Plan (ILSP)



©2020 ‐ 303 ‐

Integrated Logistics Support Plan (ILSP)

Purpose of ILSP:

• Describe PO activities to implement Support Concept.

• Document Support Element Products and Services.

• Provide tasking and responsibility information for contractors and Commonwealth agencies.

• Inform subordinate ILSP plans.

605

Integrated Logistics Support Plan (ILSP)606

Project ILSP considerations Guidance

Project ILSP Template

Source: CASG Directorate of Materiel Logistics



©2020 ‐ 304 ‐

Integrated Logistics Support Plan (ILSP)607

TABLE OF CONTENTS

1. Introduction2. Capability system description overview3. Project stakeholders4. Logistics support analysis5. ILS management6. Support system7. Operating support constituent capability8. Engineering support constituent capability9. Maintenance support constituent capability10. Supply support constituent capability11. Training support constituent capability12. Support system validation and verification13. Specialist programs14. Planned obsolescence and disposal15. Post-production support16. Transition into operational service

Source: CASG Directorate of Materiel Logistics

ILS Analyses

608



©2020 ‐ 305 ‐

Supportability Analysis (SA)

• The principal analytical tool of ILS, is Supportability Analysis (SA) which is a structured and tailored process of defining Supportability requirements throughout the Materiel System life cycle.

• Supportability significantly influences both Materiel System preparedness, operational and support requirements, and LCC/TCO.

• SA addresses the inter‐related issues of Mission System design, Support System development and optimising resources.

• SA provides interaction between the engineering and logistic support processes.

Source: DEFLOGMAN Volume 2 Volume 10 Chapter 15

609

Logistics Support Analysis (LSA)

• In more detailed and structured applications of SA, the tailored application of DEF(AUST) 5691 is required.

• LSA provides an analytical foundation to achieve Supportability and ILS objectives.

• LSA is the analytical tool that integrates ILS and the engineering functions to ensure that the system design and operational requirements have been properly applied through a single analytical approach.

• LSA is used to optimise LCC and system performance (including reliability and availability) therefore related analyses are RAM and LCCA.

Source: DMH (LOG) 04‐01‐002

610



©2020 ‐ 306 ‐

Analyses Related to LSA

• Early LSA is referred to as Front End Logistic Support Analysis (FELSA), which provides analytical support for the investigation of alternate support concepts in the early phases of the CLC.

• LSA has a close relationship with Reliability, Availability and Maintainability (RAM) and Life Cycle Costing Analysis (LCCA).

Source: DMH (LOG) 04‐01‐002 & DMSP (LOG) 04‐0‐004

611

Life Cycle Costing Analysis (LCCA)

• LCCA is the identification and analysis of all costs incurred in acquiring, operating and supporting, and disposing of a Materiel System.

• LCCA is used to identify the budget implications of capital investment decisions and the cost impact of various design and support options for Materiel Systems.

• LCCA is a key analytical tool used by ILS personnel, In‐Service Support staff, and engineers in the development, production, and through‐life support of Materiel Systems.

612



©2020 ‐ 307 ‐

LCCA

• LCCA is used to identify LCC estimates and cost drivers.

• Each LCC estimate represents a range of plausible costs for an asset (or Materiel System), where the range is influenced by the possible variations of the key cost drivers.

• LCC can be used for comparative assessment of alternative design and support options as part of SE and LSA processes.

• LCCA can be used to improve sustainment by conducting trade‐off and sensitivity analysis.

Source: DMH (LOG) 04‐01‐002

613


614



©2020 ‐ 308 ‐





Disposal

Gate 0 Gate 2Gate 1

ApprovalsIC

Approval

IC, Government

Approval




Contestability

Activities

Smart Buyer

CM Needs




Smart Buyer


PFPS*

POCD*

PES 1JCNSJCN

FPS*

OCD*PES 2

IPMP

PES 3Reduced Risk

Sub

mis

sion

App

rova

l &

Dire

ctio

n

Sub

mis

sion

Project Activities

IMS

Sub

mis

sion

Product Activities

Contract Docs

IPMP

PDA/MAA

Contract Docs

IPdMP




Project Management


App

rova

l &

Dire

ctio

n

App

rova

l &

Dire

ctio

n


ffer

Acc

epta

nce

App

rova

l


• Key outcomes of CLC: acquire and sustain capability assets.

• Defence enters into contracts of $12 bn p.a..

• Good CLC outcomes depends on sound Procurement and contracting

• Centres around:

– ‘Solicitation’ (requesting offers or tenders)

– Contracting and

– Contract Management.

Source: Contract Template Selection and Tailoring Guide Version 2.1 April 2016

616



©2020 ‐ 309 ‐

CLC: Procurement and Contracting

• Major focus for CLC:

• Solicitation between Gates 1 and 2.

• Contract/s establishment (just after Gate 2).

• Contract management for Acquisition and Sustainment.

617






Contract Management

Contract Established

Contracting


• Form of risk mitigation:

– understanding possible solutions,

– narrowing options,

– choosing best solution, and

– defining contracted requirements.

618



©2020 ‐ 310 ‐


• Planning

1. Plan the procurement.

2. Develop ‘Request documentation’ such as RFT.

• Sourcing

3. Approach the market.

4. Evaluation.

5. Negotiation and contract signature.

• Managing

6. Contract management.

7. Disposal.

619


Relationship to CLC

• CLC Solicitation and Contracting based on the ‘Procurement Life Cycle’.

• Understanding Procurement Life Cycle is pivotal to deciding the best strategy in the PES for a major acquisition.

620







Contracting and Contract Management



©2020 ‐ 311 ‐

Relationship to CLC

• The Procurement Life Cycle can also be nested within the CLC for example, acquiring risk mitigation studies or other services.

621

Pla

nn

ing

So

urc

ing

Ma

na

gin

g

Risk Reduction

activity

Pla

nn

ing

So

urc

ing

Ma

na

gin

g

Upgrade activity





Why should I know about Proc & Contract?

• All involved in the CLC should know about procurement and contracting rules because, depending on their roles:

– Capability Manager and representatives are accountable,

– Delivery groups e.g. CASG, CIOG are responsible, and

– Enabler groups e.g. E&IG are responsible.

• Defence major capital, ICT and Facilities procurements under increasing scrutiny by:

– tenderers,

– ANAO,

– Senate Estimates and other Parliamentary Committees, and

– media.

622



©2020 ‐ 312 ‐

CLC Tender and Contracting Documents623

DWP

FOE FJOC

AMS

AJOC

What and Why How

PGPA Act

CPRs

Force Design

CPN

JCN

IIP

DIP

DPPM



PESJCNS

Smart Buyer

OCD

FPS

IPMPProjectWBS

IMS


DPG

JCFConcepts

Strategic Guidance


Portfolio

Program

Project


Key Topics for Procurement & Contracting 624

Legislative and Policy Context

Core Principles

Designing the Procurement• Method of Procurement• Approach to Market• Delivery Model

• Value for Money • Competition etc

• CPRs• DPPM


Contracting Templates

• Planning • Sourcing • Managing

• ASDEFCON Templates



©2020 ‐ 313 ‐

Legislative and Policy Context

625

Resource Management Framework

• The Commonwealth Resource Management Framework governs:

– how Defence uses and manage public resources;

– consists of legislation and policy; and

– cornerstone is PGPA Act.

626



©2020 ‐ 314 ‐

Defence Proc & Contracting Policy Context

• Defence and its officials operate in an environment of legislation and policy:

– Commonwealth, State and Territory Legislation: such ssPGPA Act.

– Commonwealth Policy: such as Commonwealth Procurement Rules (CPRs).

– Defence Policy: Defence Procurement Policy Manual (DPPM) and Defence Procurement Policy Directives.

627


Hierarchy of Commonwealth Legislation & Policy Relevant to Procurement & Contracting

Public Governance, Performance and Accountability Act 2013 (PGPA Act 2013) (+ PGPA Rule 2014)

Commonwealth Procurement Rules (CPRs)

Defence Accountable Authority Instructions (AIIs)

Mandatory Defence Policy

Defence Procurement Policy Manual (DPPM)

CPRs Defence Directives

Defence Complex Procurement Guide

Guides and Tools

Defence Simple Procurement Process

Better Practice Guides

Contracting Handbook

Templates, tools and resources

Source: DPPM



©2020 ‐ 315 ‐

Defence Proc & Contracting Policy Context

Legislation and policy can affect Defence procurement through contract, for example:

• Commonwealth legislation such as Environment Protection and Biodiversity Conservation Act 1999 (EPBC Act).

• State‐based legislation:

– Environment Protection Act 2017 (Vic).

– Professional Engineers Act 2002 (Qld).

629


Legislation: PGPA Act 2013

• PGPA Act contains provisions dealing with:

– commitment of relevant money and officials entering into contracts; and

– ‘contingent liabilities’ such as indemnities, warranties and guarantees.

• Sections 23 and 60 of the PGPA Act are key sections relating to Defence procurement.

630

Sources:

DPPM April 2017 Paragraph 21 and

https://www.legislation.gov.au/Details/C2014C00317 (PGPA Act)



©2020 ‐ 316 ‐

Commonwealth Procurement Rules

• Commonwealth Procurement Rules (CPRs):

– have effect under the PGPA Act 2013;

– set out rules that officials must comply with when they procure goods and services;

– indicate good practice;

– keystone of Government’s procurement policy framework; and

– achieving value for money is the core rule.

631

https://www.finance.gov.au/sites/default/files/CPRs

Defence Procurement Policy Manual(DPPM)

• promotes responsible and accountable spending by Defence officials;

• assists Defence officials make proper use of public resources (also known as ‘public money’);

• primary operational instructions to Defence officials tailored to Defence’s particular circumstances;

• supports proactive management of procurement risks


632



©2020 ‐ 317 ‐

Defence Procurement Policy Manual

Incorporates:

• specific CPRs, and

• additional Defence Procurement Policy Directives.


Defence Procurement Policy Manual (DPPM)

CPRs Defence Directives

633

DPPM applicability

• Applies to and must be complied with by all Defence officials.

• Defence Contractor application:

– may be extended through provisions in contracts, or

– a Contractor may be prescribed to be a Defence official

• Compliance—see paragraph 4.15 of CPR and related Note.

• Defence always under obligation to ensure that its procurement activities deliver VFM to Commonwealth.


634



©2020 ‐ 318 ‐

Compliance with DPPM, CPRs, Directives

• Officials are not permitted to depart from mandatory requirements of:

– PGPA Act,

– CPR,

– AAI, and

– FINMAN 2.

• If a Defence official departs from the DPPM in a way that results in departure from CPR, then the official will have contravened the law.

635

Procurement : Core Principles

636



©2020 ‐ 319 ‐

CPR Core Principles

• CPRs have core principles that Defence officials need to consider when planning and undertaking procurement :

– Value for Money.

– Competition.

– Non‐discrimination.

– Ethical Behaviour: balance between probity and industry engagement.

– Risk Management.

637

Value for Money

• ‘Value for Money’ is core requirement of Commonwealth procurement.

• Procurements should:

– encourage competition;

– non‐discriminatory;

– use public resources in an efficient, effective, economical and ethical manner;

– facilitate accountable and transparent decision making;

– encourage appropriate engagement with risk; and

– be commensurate with scale and scope of business requirement.

Source: DPPM Chapter 2

638



©2020 ‐ 320 ‐

Value for Money

• Does not mean lowest price goods or services.

• Must consider:

– quality;

– fitness for purpose;

– supplier’s experience and performance history;

– flexibility of proposal (such as innovation and adaptability);

– environmental sustainability; and

– whole‐of life perspective including costs.

639


Capability$

Competition

• Competitive procurement is normally means by which Defence ensures that it is receiving VFM.

• Competition considered most effective motivator for industry to reduce costs and improve performance.

640

Competitive Procurement

Industry:• Reduce costs • Improve

performance

Value for Money (VFM)

Capability$Source: DPPM Chapter 2



©2020 ‐ 321 ‐

Competition

• Competition does not necessarily mean open tender

• More than one supplier can be competitive.

• If open competition not feasible, can explore limited competition subject to relevant CPR.

641


Non‐discrimination

All potential suppliers to government must, subject to CPRs:

• be treated equitably based on:

– commercial,

– legal,

– technical, and

– financial abilities; and

• not be discriminated against due to their:

– size,

– degree of foreign affiliation or ownership,

– location, or

– origin of their goods and services.

642




©2020 ‐ 322 ‐

Non‐discrimination: Exemptions

• Exemptions can be sought:

– through measures under para 2.6 of CPR (such as protection of essential security interests);

– Australian Industry Capability (AIC) policy;

– specific Government policy decisions; and

– free‐trade agreement exemptions.

643

Source: • DPPM Chapter 2 • https://dfat.gov.au/about-us/publications/trade-investment/australia-united-states-free-trade-agreement-

guide-to-the-agreement/Documents/ausfta_guide.pdf

Proper Use of Public Resources

• Section 6 of the CPRs sets out the requirement for Defenceofficials to properly use and manage public resources.

• ‘Proper’ means:

– Efficient: maximum value for resources used.

– Effective: achieving intended outcomes incl price, quality and quantity.

– Economical: minimising cost, avoiding waste.

– Ethical: honesty, integrity, probity, diligence, fairness and consistency.

644

Source: DPPM Chapters 2 and 4, Source: CPRs 6.1‐6.5



©2020 ‐ 323 ‐

Ethical Behaviour

Officials undertaking procurement must act ethically :

• recognise and deal with actual, potential and perceived conflicts of interest;

• deal with potential suppliers, tenderers and suppliers equitably:

– seek internal or external advice when probity issues arise, and

– not accepting inappropriate gifts or hospitality;

• carefully consider use of public resources; and

• comply with all directions incl Privacy Act 1988 and Crimes Act 1914.

Source: CPR 6.6

645

Probity

• Probity is evidence of ethical behaviour:

– Complete/confirmed integrity, uprightness and honesty in a process.

– Dept of Finance website lists principles which underpin ethics and probity in Government procurement.

• Many legislative and policy documents refer to probity:

– PGPA Act (s25‐29);

– Public Service Act 1999;

– DI(G) PERS 25‐4 ‐ Post Separation Employment;

– DI(G) PERS 25‐6 – Conflicts/ declarations of interests; and

– DI(G) PERS 25‐7 ‐ Gifts, Hospitality and Sponsorship.

646

Source: DPPM para 66 and 67



©2020 ‐ 324 ‐

Commercial Acumen

• Understanding:

– how industry is/can be used for Defence business;

– commercial drivers of industry;

– how to engage with industry and manage commercial relationships; and

– dealing appropriately with potential suppliers, tenderers.

• Critical aspect of capability management.

647

$

Consistency with Government Policies

PGPA Act s21 requires:

• Defence actions that are “not inconsistent with the policies of the Australian Government”, for example:

– Cabinet decisions; and

– other Government approvals (decision or approval establishes a course or line of action).

• Defence officials exercising delegations (especially PGPA Act s23).

648

Source: DPPM p6



©2020 ‐ 325 ‐

Implementing Defence Procurement and Contracting

649

Procurement and Contracting 650







3. Approach the Market

4. Evaluation

3. Negotiation and Signature

6. Contract Management

7. Disposal

1. Procurement Plan

2. Request Documentation



©2020 ‐ 326 ‐

Planning the Procurement:

Method of Procurement, Approach to Market and Delivery Model

Considerations for Procurement

Three considerations when deciding how to proceed with a procurement:

1. Method of Procurement – open or limited tender.

2. Approach to Market – which tendering documents to use.

3. Delivery Model – type of contract arrangement with supplier.

652



©2020 ‐ 327 ‐

1. Method of Procurement

• Under the CPRs, there are two main procurement methods:

– Open tender: approach open market and invite submissions.

– Limited tender: approach only one or more potential suppliers to make submissions.

• Default position is open tender.

• Limited tender includes only one supplier (often called a ‘sole source’ procurement).

653


Selecting open or limited tender, dependent on:

• nature and structure of the market;

• extent of competition (number of competitive suppliers); and

• schedule, cost or other constraints (such as intellectual property, security, etc).

654



©2020 ‐ 328 ‐


Very limited circumstances for limited tender (CPR 10.3):

• extreme urgency;

• unsolicited innovative proposals;

• no real alternative (such as no competition technical solution); and

• additional deliveries of goods and services.

655


2. Approach to Market

• The type of approach to market includes:

– request for tender (RFT);

– request for proposal (RFP);

– request for quote (RFQ) under a standing offer panel;

– competitive evaluation;

– some other form of iterative engagement process; and

– other form of documentation.

• Not determined by open or limited tender.

656



©2020 ‐ 329 ‐

3. Project Delivery Model

• Type of contracting arrangement:

– Prime contract,

– Managing Contractor,

– Design and Construct contract, or

– Alliance contract.

657

Design Each Procurement Appropriately

1. Method of Procurement – open or limited tender.

2. Approach to Market – which tendering approach (and templates) to use.

3. Delivery Model – type of contract arrangement with supplier.

658



©2020 ‐ 330 ‐

Tendering and Contracting Templates


• Contracting templates to meet:

– different procurement needs and profiles; and

– size, complexity and nature of the procurement activity.

• Means you don’t have to start from scratch to contract.

• Templates include:

– Commonwealth Contracting Suite.

– The Australian Standard for Defence Contracting (ASDEFCON).

– Defence Suite of Facilities Contracts.

ASDEFCON used for CLC.

660



©2020 ‐ 331 ‐


• Defence contracting templates are:

– drafted and regularly updated; and

– reflect applicable:

• Commonwealth legislation;

• Commonwealth policy (including the CPR); and

• Defence policy.

• Commonwealth, State and Territory legislation and policy affecting procurement must be addressed e.g.:

– Environment.

– Work Health and Safety.

– Security.

661

Source: DPPM: p35, 36

ASDEFCON Templates

• Defence procurement:

– ASDEFCON suite; and

– 20 different templates for tendering and contracting.

• Handbooks and related training available for some templates.

Source: Department of Defence Website: Doing Business with Defence

662



©2020 ‐ 332 ‐

ASDEFCON Templates

• Defence procurement supported by ASDEFCON suite which is made up of 20 different templates for tendering and contracting.

• Associated handbooks and related training are available for some templates.

663


ASDEFCON (Strategic Materiel)ASDEFCON (Complex Materiel) Volume 2ASDEFCON (Complex Materiel) Volume 1ASDEFCON (Support)ASDEFCON (Support Short)ASDEFCON Linkages ModulesASDEFCON (Services)ASDEFCON (Standing Offer for Services)ASDEFCON (Standing Offer for Goods)ASDEFCON (Standing Offer for Goods & Maintenance Services)ASDEFCON (Shortform Goods)

ASDEFCON (Shortform Services)Request for Quotation and Purchase Order and Contract (Form SP020)ASDEFCON (Request for Information)Template Letter for Release of Draft Documents to IndustryASDEFCON (Invitation to Register)ASDEFCON (Request for Proposal)ASDEFCON Defence Asset TemplatesGovernment Furnished Facilities LicenceASDEFCON Toolbar, Style Set and User Guide

Materiel Acquisition Contracting Spectrum 664


ASDEFCON (Strategic Materiel)

ASDEFCON (Complex Materiel)

Volume 2

ASDEFCON (Complex Materiel)

Volume 1

ASDEFCON Standing Offers

Simple Procurement

Com

plex

ity



©2020 ‐ 333 ‐

ASDEFCON Template Selection

• Level of contract management and assurance is commensurate with risk and complexity.

• Nature of technical requirement (complexity) is key driver.

• Failure to relate tendering contacting effort to technical requirement can result in:

– excessive unnecessary work; and

– increased risk.

665

Source: Contract Template Selection and Tailoring Guide, Version 2.1 April 2016

ASDEFCON Template Selection 666

Nature of technical

endeavour

Level of acquisition

risk and complexity

Best fit ASDEFCON

Template

• Documentation• Contract Mgt• Assurance

Extent of system design and development

Risk of system development success

Requires different levels of:• Documents• Reviews• Evidence

If risk is high then significant management:• Plans • System Reviews• Reporting requirements• Assurance activities



©2020 ‐ 334 ‐

ASDEFCON Template Selection

Nature of technical

endeavour

Level of acquisition

risk and complexity

Best fit ASDEFCON

Template

• Documentation• Contract Mgt• Assurance

667

Technical complexity and risk DRIVES Project work effort and cost

Extent of system design and development

Risk of system development success

Requires different levels of:• Documents• Reviews• Evidence

If risk is high then significant management:• Plans • System Reviews• Reporting requirements• Assurance activities

ASDEFCON Templates

• Most ASDEFCON templates for tendering are structured to include:

– a covering letter to tenderers;

– conditions of tender with response volumes;

– a draft contract and where appropriate; and

– a draft statement of work (SOW).

668




©2020 ‐ 335 ‐

ASDEFCON Template Selection: SOW

• SOW captures scope and nature of work incl technical requirements.

• ‘Technical requirements’ are significant drivers of the complexity and risks of the procurement.

SOW drives template selection.

669


Pivotal Role of SOW

• SOW details work to be done during contract:

– Supplier, such as produce documents; and

– Customer, such as review documents.

• SOW needs to be accurate:

– Unnecessary work requirements increases cost without commensurate increase in value.

– Insufficient work requirements (esp technical) can jeopardise outcomes.

670




©2020 ‐ 336 ‐

Pivotal Role of SOW

Before selecting a contracting template it is essential to:

• understand the technical nature of the activity;

• be clear about goods and/or services to be acquired;

• develop a sound SOW:

– work to be done, and

– who does the work.

SOW drives VFM.

671

Understand Technical Risk and Complexity 672

Assurance level

Technical Risk,

Complexity

Project and Supplier effort, $



©2020 ‐ 337 ‐


Captured in:• SOW• Specifications

Extent of tender and contract:• Documentation (e.g. DIDs)• Assurance activities (e.g System

Reviews)• Effort by staff

Assurance level

Technical Risk,

Complexity



Technical Risk,

Complexity


$DID 200

DID 100

DID 200DID 100

DID 100

DID 100 $$$DID 100

Assurance level



©2020 ‐ 338 ‐

ASDEFCON Strategic Materiel

Preliminary Pages

Part 1 ‐ Conditions of Tender

Part 1 ‐ Annexes to the Conditions of Tender

Part 2 ‐ Draft Conditions of Contract

Part 2 ‐ Attachments to Draft Conditions of Contract

Part 3 ‐ Draft Statement of Work

Part 3 ‐ Annexes to the Draft Statement of Work

Part 3 ‐ Data Item Descriptions

Part 3 ‐MSR Checklists

675

Part 3 ‐ Statement of Work

Purpose:

• communicate Commonwealth requirements and standardsfor work to be carried out under the Contract and

• allocate work responsibilities between the Commonwealth and the Contractor.

676



©2020 ‐ 339 ‐


Brings together all ‘technical’ aspects (requirements and Practices) relevant to the CLC into a contract including:

• Project Management.

• Systems Engineering.

• Integrated Logistics Support.

• Configuration Management.

• Verification and Validation.

• Health, Safety and

• Environment.

677


SOW makes statements such as:

“The Contractor shall perform all activities necessary to manage, design, develop, construct, integrate, test, deliver, install and obtain Certification and Acceptance of the Supplies by the Commonwealth in accordance with the Contract.”

“The Contractor shall allocate the requirements for the Materiel System defined in the FPS at Annex A to the SOW into a System Specification (SS) for the Mission System and a Support System Specification (SSSPEC) for the Support System.”

678

Source: ASDEFCON (Strategic Materiel) template Section 2



©2020 ‐ 340 ‐

Part 3 ‐ Data Item Descriptions (DID)

• A Data Item Description (DID) is a document defining the information or data deliverables required of a tenderer or contractor.

• DIDs detailed as Annex to SOW.

679

Source: ASDEFCON (Strategic Materiel)


• A Data Item Description (DID) is a document defining the information or data deliverables required of a tenderer or contractor.

• What the Tenderer or Contractor has to produce.

• DIDs detailed in Annex to SOW.

680


Tender Life Cycle Cost Model (TLCCM)



©2020 ‐ 341 ‐


• Within a solicitation or contract:

– Each DID is uniquely numbered to identify the ‘data item’.

– Format is defined eg DID preparation instructions including a table of contents and descriptions of each section.

– Specific required content, for example:

“the Tender Life Cycle Cost Model shall provide sufficient detail to enable the Commonwealth to understand the LCC model developed by the tenderer”

681



• DIDs are selected from ‘superset’:

– Tender Document Requirements List (TDRL); or

– Contract Data Requirements List (CDRL).

• Tender or Contract Data requirements are determined to be core or optional.

• Annex C to the Draft Statement of Work (V3.1) provides the comprehensive list of possible Data Items.

682



©2020 ‐ 342 ‐

Part 3: Mandated System Review Checklists

• System reviews are an important form of assurance.

• MSR defines Commonwealth’s requirements and minimum expectations for reviews during Contract.

• Includes ‘exit criteria’ for assessing successful completion of review.

• Extent of assurance through system reviews (number, depth, type) depends on the nature of the work (SOW: risk, complexity).

• Examples of MSR during system development:

– Integrated Baseline Review (IBR).

– System Requirements Review (SRR).

– System Definition Review (SDR).

683


Tailoring the ASDEFCON Template684

Template

Information to be provided by

Tenderer/Contractor

Work to be done

SOW MSR

Reviews to be conducted during

contract

TDRL/CDRL

List of Data Requirements:

Data Items

Mandated, Highly Desirable

• CoA requirements standards for work

• allocate work responsibilities to CoA & Contractor



©2020 ‐ 343 ‐


Duties with Respect to Risk Management

• PGPA Act requires Commonwealth entities to manage risk.

• Officers of the Commonwealth must observe their obligations on risk management and risk control.

• Defence must establish and maintain:

– system of risk oversight and management; and

– system of internal control for the entity.

686

Source: PGPA Section 16



©2020 ‐ 344 ‐

Assurance in Capability Management

• Assurance provides confidence to decision‐makers and managers:

– arguments presented are sound and based on evidence;

– claimed status is accurate; and

– outcomes satisfy organisational objectives.

• Assurance conducted across the entire CLC.

• Assurance across all dimensions of capability management including:

– technical,

– safety,

– financial, and

– seaworthiness.

687

Risk Management



©2020 ‐ 345 ‐


• PGPA Act seeks to improve the high level accountability of all Commonwealth entities through focusing on:

– their duties,

– internal controls, and

– the way they engage with, and manage, risk.


689


So…

The accountable authority of a Commonwealth entity must establish and maintain:

– an appropriate system of risk oversight and management for the entity; and

– an appropriate system of internal control for the entity.

690




©2020 ‐ 346 ‐

Defence Risk Management

“Risk management is to be integrated into all planning, approval, review and implementation processes, at all levels, to ensure that risk is one of the major considerations in decision‐

making. Risk assessments are to be conducted in all new activities and functions.”

30/2015 CDF/OUT/2015/682 The Joint Directive by CDF and Secretary of Department of Defence on the Management of Risk in Defence

Defence Risk Management: evidence

The Joint Directive emphasises that a key principle applying to all decisions is to accept and treat individual risks based on evidence.

692



©2020 ‐ 347 ‐

Definitions

• Risk: effect of uncertainty on objectives.

• Risk Management: coordinated activities to direct and control an organisation with regard to risk.

• Risk Control: action to reduce or eliminate threats to organisational objectives

693

Source: AS/NZS ISO 31000 Risk Management pp 1‐2

Risk Management Process 694

Risk Assessment

Monitoring and Review

Communication and

Consultation

Establishing the Context

Risk Identification

Risk Analysis

Risk Evaluation

Risk Treatment

Source: AS/NZS ISO 31000:2018



©2020 ‐ 348 ‐

Risk Management and the CLC

• Core requirement of CLC is a deliberate approach to risk:

– Must understand and assess risks.

– Must have targeted approach to risk management and control.

– Decisions are made with understanding of risks.

– Must not be risk averse in decision‐making.

695

Risk Management in the CLC

General risk management process:

1. Identify the risk ‘events’ or occurrences.

2. Estimate the likelihood of these happening (probability).

3. Estimate what the impact will be.

4. Figure out the level of risk and ranking between risk events.

5. Plan what to do to control, reduce, eliminate the risk events.

6. Implement risk mitigation, reduction.

696



©2020 ‐ 349 ‐

Risk Management and the CLC

Multiple risk frameworks in Defence relevant to CLC include but are not limited to:

• CLC Risk Mitigation Phase emphasising risk treatment.

• Smart Buyer Risk Framework.

• Technical Risk Assessment (TRA),

• Technical Implementation Risk Assessments (TIRA),

• Schedule Compliance Risk Assessment (SCRAM).

• Technical Risk Management.

697


Approvals Strategy


Strategy

Commercial Strategy

PES

JCNS

Risk/Driver Profile Analysis/Tailoring Capability Need

Strategy

Needs

Strategic

Security

Technology

Industry Capability

Commercial

Financial

Schedule


Defence Integration

Technology

Industry

Capability

Schedule

Commercial

Project & FIC

Context

Asset Management

Strategy



©2020 ‐ 350 ‐

CLC Risk Management: Acquisition Categories 699

Risk Category Risk Event Treatment/ Mitigation

Requirements Requirements incompleteNot verifiableAmbiguous

Additional requirements development Technical trial to determine constraintsPeer review

Technology Not matureUnproven

Develop technology further, trialField in increments

Schedule Schedule not achievable Redevelop WBS and schedule

Commercial Limited competition in market Contract with appropriate performance incentives

Project Integration Related Projects misaligned Establish Prime System Integrator to manage interdependencies

Defence Integration FIC delivery misaligned Establish Steering and review group

Financial Schedule slippage affects milestone achievement

Establish Program level so that flexibility to accommodate changes

Strategic Changing threat situation Ensure growth in system requirements and capabilities

Industry Industry not investing in field Funding to establish industry capability

CLC Risk Management: Acquisition Categories 700

Risk Category Risk Event Treatment/ Mitigation

Requirements Requirements incompleteNot verifiableAmbiguous

Additional requirements development Technical trial to determine constraintsPeer review

Technology Not matureUnproven

Develop technology further, trialField in increments

Schedule Schedule not achievable Redevelop WBS and schedule

Commercial Limited competition in market Contract with appropriate performance incentives

Project Integration Related Projects misaligned Establish Prime System Integrator to manage interdependencies

Defence Integration FIC delivery misaligned Establish Steering and review group

Financial Schedule slippage affects milestone achievement

Establish Program level so that flexibility to accommodate changes

Strategic Changing threat situation Ensure growth in system requirements and capabilities

Industry Industry not investing in field Funding to establish industry capability



©2020 ‐ 351 ‐



Risk Mitigation andRequirementsSetting

In-Service andDisposal

Gate 0 Gate 2Gate 1



Disposal

Risk Reduction

Risk ReductionForce

Design







Smart Buyer Risk

Profile

Trade‐off studies

Trade‐off studies




Gate 0 Gate 2Gate 1

PES





©2020 ‐ 352 ‐







System Reviews

Smart Buyer Risk

Profile


Trade‐off studies

Trade‐off studies




Gate 0 Gate 2Gate 1

PES





Risk Reduction continues after Gate 2 through System Engineering and other practices including System Review activities

Expectations of Risk Approach to CLC

• A structured and deliberate approach to risk management processes supports PGPA duties through:

• reducing and controlling risk; and

• clear consideration of risks in decision‐making.

• Conscious risk reduction mindset:

– throughout the CLC (not just to Gate 2); and

– targeted risk control actions focused on identified risks.

704



©2020 ‐ 353 ‐

Assurance

Meaning of Assurance

• Assurance:

– a positive declaration intended to give confidence; a promise. Source: Oxford Dictionary

– grounds for justified confidence that a claim has been or will be achieved. Source: ISO/IEC15026‐1:2013

• Compliance Assurance: measures instituted by a government agency to ensure that the provisions of its regulations are being met. Source: http://www.businessdictionary.com

• Technical Assurance: process by which the technical integrityof a product, process, or system is monitored and maintained. Source: http://www.businessdictionary.com

706



©2020 ‐ 354 ‐

Assurance Cases707

“Reasoned, auditable artefact created that supports the contention that its top-level claim (or set of claims), is satisfied, including systematic argumentation and its underlying evidence and explicit assumptions that support the claim(s)”

AS4360 (Risk Management)

Claims Evidence Arguments

that support the…

Assurance Cases

Assurance Cases contain the following:

• one or more claims about properties;

• arguments that logically link the evidence and any assumptions to the claim(s);

• a body of evidence and possibly assumptions supporting the arguments for the claim(s); and

• justification of the choice of top‐level claim and the methodof reasoning.

708



©2020 ‐ 355 ‐

Assurance in Capability Management

• CLC assurance activities are conducted:

– across the whole CLC;

– across various dimensions of capability management (egtechnical, safety, financial, seaworthiness);

– to provide confidence to decision‐makers and managers; and

– to assure compliance with legislative and regulatory obligations.

709




Gate 0 Gate 2Gate 1

Program of Assurance Activities

• Many different assurance activities across the CLC.

• Program, Product and Project Sponsors need to:

– plan assurance ie schedule and allocate resources;

– ensure necessary evidence is being collected to support assurance cases; and

– achieve efficiencies through leveraging activities.

• Assurance activities should be tailored to circumstances.

• Should establish a clear view of Assurance Program and capture this in the IPMP and appropriate subordinate plans.

710



©2020 ‐ 356 ‐

Types of Assurance across the CLC

• Contestability. • Gate Reviews • Independent Assurance Reviews (IARs).• Deep Dive Reviews. • Schedule Compliance Risk Assessment Method (SCRAM).• Mandated System Reviews. • Audit. • Reporting. • Validation and Verification (V&V).• Test and Evaluation (T&E).• Certification. • QA: Supplier and Product Assurance.• Engineering Assurance.

711

Examples of Assurance across the CLC712




Gate 0 Gate 2Gate 1



©2020 ‐ 357 ‐


• Key assurance activity during Investment Approval Pathway.

• Reviews force design outputs and all Gate submissions.

• Ensures:

– alignment with strategic and resource guidance;

– an acceptable basis for decision‐making; and

– plans can be executed.

• Reviews risk assessments and treatment strategies.

• Reviews cost and schedule estimates.

• Independent assurance reviews and ‘deep dives’.

713

Review Panels

• Independent assurance that augments reporting.

• Reviews health of Program, Product or Project:

– Gate Reviews.

• Capability Manager or Program Sponsor and/or the Delivery Group initiates.

• Independently chaired panel before all Gates and critical milestones.

– In‐Depth Reviews.

• Program Sponsor, VCDF or DepSec Strategic Policy and Intelligence or Delivery Group Head initiates.

• Independently chaired.

• As a result of a significant trigger or particular concern.

714

Source: Interim CLC Manual 2017



©2020 ‐ 358 ‐

Program‐level Health Checks

• Responsibility of Program Sponsor.

• Conducted on regular basis: typically tri‐annual basis

• Supports progress reporting to Capability Manager, members of Program Steering Group and other key stakeholders.

• Standardised across IIP.

• Reduces need for additional performance reporting.

715


Independent Assurance Reviews (IAR)

• CASG’s assurance framework.

• Provides reliable advice on:

– continuing viability of capability investment decisions; and

– health and outlook of Programs, Projects, Products.

• Chartered Board with skills and experience.

• Lead up to key Project milestones or annually.

• Sustainment reviews in lead up to major events in Product Life Cycle:

– such as mid‐life upgrades; or

– periodically, one to three years.

716

Source: CASG Business Framework 2017Source: Interim CLC Manual 2017



©2020 ‐ 359 ‐

Strategy and Concepts Phase: Lead Times to Gate 0717


Capability Manager Gate Review (CMGR)

• Capability Manager‐led governance forum.

• Not compulsory (choice of CM).

• Quality control point for Projects/Programs prior to IC.

• Opportunity for:

– high level consultation; and

– identify and resolve key concerns.

• Contestability advice either:

– Stand‐alone Contestability Brief; or

– Sponsor’s Paper/Business Case with embedded Contestability advice.

718



©2020 ‐ 360 ‐

Deep Dive Reviews

• Led by Force Design Division:

– supported by Program Sponsor and Contestability Division (as appropriate);

– scheduled in Force Design Forward Work Plan; and

– focuses on a Program, cross‐Program or Capability Stream.

719


SCRAM

• The Schedule Compliance Risk Methodology (SCRAM):

– structured approach to identifying Project risks and issues with technical or engineering origin;

– understand impact on Project schedule outcomes; and

– evidence and recommendations for treatment of risks and issues.

• Considers:

– requirements definition;

– system design, development, production;

– system integration and test; and

– software development.

720



©2020 ‐ 361 ‐

When Can SCRAM be Applied?

• Projections of schedule outcomes at any point in CLC e.g.:

– for Smart Buyer up to Gate 2.

– assess Project health from Gate 0 to Acceptance.

• ‘Due diligence’ assessments during for handovers.

• Identify sources of technical implementation risk.

• Determine practical risk mitigation actions.

• Focus on:

– system development,

– software development, and

– system integration.

721


• Technical Regulation:

– Confidence to Capability Managers.

– Safety and technical integrity of systems and equipment.

– Fitness for service, safety and environmental compliance.

722



©2020 ‐ 362 ‐


• Seaworthiness:

– Defence Seaworthiness Management System Manual (DSwMS) (Jun 17).

• Airworthiness:

– Defence Aviation Safety Regulation (DASR) introduced in 2016 and replaced the Military Operational and Technical Airworthiness Regulations.

• Land Technical Regulation (Landworthiness):

– Technical Regulation of ADF Materiel Manual – Land.

• Explosive Ordnance Regulation:

– DI (G) LOG 4‐1‐006 ‐ Safety of Explosive Ordnance.

723

Audit

• Cornerstone of good public sector governance.

• Objective assessments of whether public resources are managed responsibly and effectively to achieve intended results.

• Audit helps:

– public sector organizations achieve accountability and integrity,

– improve operations, and

– instill confidence among citizens and stakeholders.

724

Source: The Role of Auditing in Public Sector Governance 2nd edition Jan 2012



©2020 ‐ 363 ‐

Range of Audits

• Three main categories of audits: dependent on relationship between auditor and the person being audited:

– first‐party,

– second‐party, and

– third‐party audits.

725

Source: https://advisera.com

Range of Audits

• Third‐Party Audits:

– Organisation engages an independent party to perform an audit.

– Organisation wants to create a quality management system (QMS) that conforms to a standard set of requirements (eg ISO 9001).

• …

726



©2020 ‐ 364 ‐

Range of Audits

• …

• Second‐party audit:

– Audit of a supplier to ensure that they are meeting requirements in contract or other agreement.

– All or part of the contract or agreement can be audited.

– On‐site reviewing of processes or off‐site review of documents.

– Not relevant to certification.

727

Range of Audits

• …

• First‐Party Audits:

– Often called internal audits.

– Organisation audits processes in the quality management system.

– Audit assesses if processes as conducted:

• meet standard, and

• rules the organisation has set itself.

728



©2020 ‐ 365 ‐

ANAO

• Relevant activities of ANAO:

– Performance audits of Australian Government programs and entities; and

– Assurance reviews of Australian Government entities.– Source: https://www.anao.gov.au/about/legislation‐and‐standards

729

ANAO

• Relevant activities of ANAO:

– Performance audits of Australian Government programs and entities;

– Assurance reviews of Australian Government entities.– Source: https://www.anao.gov.au/about/legislation‐and‐standards

• ANAO Auditors use:

– financial audits,

– performance audits,

– investigations, and

– advisory services.

730



©2020 ‐ 366 ‐







System Reviews

Smart Buyer Risk

Profile


Trade‐off studies

Trade‐off studies




Gate 0 Gate 2Gate 1

PES




Mandated System Reviews provide assurance for satisfaction of acquisition activities

Mandated System Reviews

• Based on System Engineering

• Provides assurance on achievement of progress for contracted work.

• Form of Assurance Case for each step in system development, production and delivery.

732




©2020 ‐ 367 ‐

Mandated System Reviews

• Pivotal System Reviews (most materiel acquisitions) include:

– Integrated Baseline Review (IBR).

– System Requirements Review (SRR).

– System Definition Review (SDR).

– Preliminary Design Review (PDR).

– Detailed Design Review (DDR).

– Support System Detailed Design Review (SSDDR).

733


T&E Categories

• Developmental Test and Evaluation (DT&E)

– Largely undertaken in the Acquisition Phase.

– Support design and development effort.

– Generally undertaken by contractors.

• Acceptance Test and Evaluation (AT&E)

– Formal acceptance testing on behalf of customer.

– Between the Acquisition and Utilisation Phases.

• Operational Test and Evaluation (OT&E)

– Focuses on functional or operational testing of the system

– Generally undertaken by users following acceptance.

– Some OT&E (called Preview T&E) can occur earlier during Acquisition Phase, particularly for large, phased projects.

734



©2020 ‐ 368 ‐

Verification and Validation (V&V)

• Systems engineering process aims for a system that is:

– verified against the documentation produced (MOPs); and

– validated against the original needs, goals and objectives (MOEs).

• V&V ensures that we have both:

– built the system right (verification); and

– built the right system (validation).

• T&E supports V&V.

735

Methods of V&V

• T&E

• Demonstration

• Experiment

• Analysis

• Modelling

• Simulation

• Inspection/examination

• Similarity

• Certification

• Implication

736

Decreasing cost and time

Decreasing rigour and credibility

Source: Don Greenlee, “T&E As An Element of SE and Vice Versa: It’s Only Fair Play”, SETE Conference, 8 Nov 2004.



©2020 ‐ 369 ‐

Methods of V&V737

AT&E

AT&E

AT&E

AT&E

AT&E

AT&E

Facilities

Training

Support

Supplies

Personnel

SyRS


Capability System Development

Acquisition Phase Utilization Phase

In-service

DeliveredCapabilitySystem

StRSOrganisation

Major System AT&E

OT&E

Validation

Verification

Phases of the CLC



©2020 ‐ 370 ‐

Overview: Phases of the CLC

The CLC is a four‐phase, risk‐based decision‐making process which:





739




CLC Gates

There are three decision gates:

– Gate 0: Defence decision to progress to next Gate. All proposals go through Gate 0.

– Gate 1: Government decision to progress proposals to Gate 2 including specific option(s).

– Gate 2: Government decision to acquire a fully defined and costed capability.

740



Setting


Gate 0 Gate 2Gate 1




©2020 ‐ 371 ‐





Disposal

Gate 0 Gate 2Gate 1

ApprovalsIC

Approval

IC, Government

Approval




Contestability

Activities

Smart Buyer

CM Needs




Smart Buyer


PFPS*

POCD*

PES 1JCNSJCN

FPS*

OCD*PES 2

IPMP

PES 3Reduced Risk

Sub

mis

sion

App

rova

l &

Dire

ctio

n

Sub

mis

sion

Project Activities

IMS

Sub

mis

sion

Product Activities

Contract Docs

IPMP

PDA/MAA

Contract Docs

IPdMP




Project Management


App

rova

l &

Dire

ctio

n

App

rova

l &

Dire

ctio

n


ffer

Acc

epta

nce

App

rova

l




Setting


Gate 0 Gate 2Gate 1



©2020 ‐ 372 ‐





Disposal

Gate 0 Gate 2Gate 1

ApprovalsIC

Approval

IC, Government

Approval




Contestability

Activities

Smart Buyer

CM Needs




Smart Buyer


PFPS*

POCD*

PES 1JCNSJCN

FPS*

OCD*PES 2

IPMP

PES 3Reduced Risk

Sub

mis

sion

App

rova

l &

Dire

ctio

n

Sub

mis

sion

Project Activities

IMS

Sub

mis

sion

Product Activities

Contract Docs

IPMP

PDA/MAA

Contract Docs

IPdMP




Project Management


App

rova

l &

Dire

ctio

n

App

rova

l &

Dire

ctio

n


ffer

Acc

epta

nce

App

rova

l

Strategy and Concepts Phase

• Draws on force design cycle (DCAP) to:

– evolve joint capability concepts, and

– identify capability needs.

• Identifies current, forecast or potential:

– capability gaps,

– risks,

– issues, and

– opportunities that may need further investment.

• Develops capability options.

• Basis for a CM to develop the Gate 0 Proposal.

• Emphasis on ‘Joint force by Design’.

744



©2020 ‐ 373 ‐

Strategy and Concepts: Force Design745



Setting


Gate 0 Gate 2Gate 1

Force Design Framework (DCAP)

• Force Design:

– Centralised.

– Core function of Strategy & Concepts.

– ‘Joint Force by Design’: integration and interoperability.

• Defence Capability Assessment Program (DCAP):

– Annual, Agile, Fundamental modes.

– Prioritised capability investment recommendations for IIP.

Force Design

• Identifies force design options.

• Force Design Division uses combination of activities:

– experimentation,

– war‐gaming,

– simulation and modelling,

– operations analysis, and

– options development and analysis.

746

Source: Adeladian (Researchers working in the Defence, Science & Technology Organisation's (DSTO) Future Operations Centre Analysis Laboratory (FOCAL) Photo courtesy of DSTO

Source: https://www.dst.defence.gov.au/research‐area/operations‐analysis



©2020 ‐ 374 ‐

Strategy and Concepts: Force Design747



Setting


Gate 0 Gate 2Gate 1


• Output: Joint Capability Narrative (JCN)• Capability Manager (CM) assigned • Output: Joint Capability Needs Statement (JCNS)

Need defined: What?

Strategy and Concepts: Smart Buyer748



Setting


Gate 0 Gate 2Gate 1




Approvals Strategy


Strategy

Commercial Strategy

PES

JCNS

Needs

Strategic

Security

Technology

Industry Capability

Commercial

Financial

Schedule


Defence Integration

Asset Management

Strategy



©2020 ‐ 375 ‐


Approvals Strategy


Strategy

Commercial Strategy

PES

JCNS

Risk/Driver Profile Analysis/Tailoring Capability Need

Strategy

Needs

Strategic

Security

Technology

Industry Capability

Commercial

Financial

Schedule


Defence Integration

Asset Management

Strategy


• Approval Strategy:

– intended path to approval (two pass, one pass, NSC, Ministers etc.), and the reasons for that decision.

• Authorities such as National Security Committee (NSC), One/Two Ministers.

• Pathway, such as:– fast track from Gate 0 to Gate 2; and

– significant risk reduction studies Gate 0 to Gate 1. • Asset Management Strategy

– FIC Management.

– Capability Relevance.

– System(s) Maintenance, Changes and Tech Regulation.

750



©2020 ‐ 376 ‐


• Governance and Management Strategy:

– Single or Multi‐layer Governance.

– Change Management.

– Communications Strategies.

– PMO (Program/Project) Structure and Approach.

• Commercial Strategy:

– Business Intelligence.

– Relationships.

– Strategic Agreements.

– Contractual Provisions.

751




Setting


Gate 0 Gate 2Gate 1




• Delivery Group assigned• IPM assigned and IPMT initiated • Output: Project Execution Strategy

Strategy defined: How?

Approvals Strategy


Strategy

Commercial Strategy

PES

JCNS

Needs

Strategic

Security

Technology

Industry Capability

Commercial

Financial

Schedule


Defence Integration

Asset Management

Strategy



©2020 ‐ 377 ‐

Strategy and Concepts: Contestability753



Setting


Gate 0 Gate 2Gate 1





ContestabilityFramework

Approvals Strategy


Strategy

Commercial Strategy

PES

JCNS

Needs

Strategic

Security

Technology

Industry Capability

Commercial

Financial

Schedule


Defence Integration

Asset Management

Strategy

Contestability Model across the CLC754

• Current focus on Gate considerations.• Will be conducted across CLC.

Source: Department of Defence



©2020 ‐ 378 ‐

Strategy and Concepts: Contestability755



Setting


Gate 0 Gate 2Gate 1






• Contestability Division engaged • Output: Assurance statement

Assurance: Is proposal OK?

Approvals Strategy


Strategy

Commercial Strategy

PES

JCNS

Needs

Strategic

Security

Technology

Industry Capability

Commercial

Financial

Schedule


Defence Integration

Asset Management

Strategy

Strategy and Concepts: Gate 0756



Setting


Gate 0 Gate 2Gate 1







Gate 0 ProposalProject Proposal

Approvals Strategy


Strategy

Commercial Strategy

PES

JCNS

Needs

Strategic

Security

Technology

Industry Capability

Commercial

Financial

Schedule


Defence Integration

Asset Management

Strategy



©2020 ‐ 379 ‐

Gate 0 Proposal: Features

• Sufficiency: sufficient argument to make a decision.

• Discipline in Documentation: appropriate level of detail.

• Tailored: approach appropriate to risk, complexity.

757

Gate 0 Proposal: Components758

Joint Capability Needs Statement (JCNS)

Project Execution Strategy (PES)

Sponsor Paper

+

+

What?

How?

Why?



©2020 ‐ 380 ‐




Sponsor Paper

+

+

Overarching business argument for investment

What?

How?

Why?


What?

How?

Why?

Joint Capability Needs Statement (JCNS)What is the capability need (gap)


Sponsor Paper

+

+




©2020 ‐ 381 ‐


What?

How?

Why?

Project Execution Strategy (PES)How will investment (Project) be undertaken

Sponsor Paper

+

+



Gate 0 Proposal: Elements

• Sponsor Paper:

– Business Case argument.

– Contestability Statement.

– Total Cost of Ownership (TCO).

– Industry considerations.

• Joint Capability Needs Statement (JCNS).

• Project Execution Strategy (PES):

– must be based on Smart Buyer analysis;

– must not use templated content; and

– must not be a ‘cookie cutter’ application of other efforts.

762



©2020 ‐ 382 ‐

Gate 0 Proposal: Intent

Proposes activities and outcomes to next Gate including:

• Risk reduction activities.

• Funding requirements.

• Expected outcomes, such as:

– requirements definition,

– down‐selection of options,

– risk profile, and

– costings.

• Industry engagement.

763

Industry Engagement

• Prior to Gate 0, CM and Delivery Groups are expected to engage with industry to:

– support analysis,

– promote innovation,

– procure industry services, and

– test concepts.

764



©2020 ‐ 383 ‐

Strategy and Concepts: Gate 0765



Setting


Gate 0 Gate 2Gate 1








Proposal submitted: Business Case

• Output: Gate 0 Proposal comprising: Submission; JCNS; PES

Strategy and Concepts: IC Consideration766



Setting


Gate 0 Gate 2Gate 1










Investment Committee consideration



©2020 ‐ 384 ‐

Gate 0 – Overview

• Internal Defence decision.

• Proposal sponsored by Capability Manager (CM)

• Approves further development of feasible and achievableoptions with agreed requirements, timeframes, and funding:

– to Gate 1; or

– directly to Gate 2.

• Gate 0 approval is issued by the VCDF.

• Gate 0 Proposal evolves for Gate 1 and Gate 2.

767

Gate 0 ‐ Outcomes

• Project Direction:

– Expected outcomes for next Gate.

– Resources allocated.

– Key issues and risks for next business case/proposal.

• Formal endorsement of PES,

• If going straight to Gate 2 can initiate entry into IIP through higher delegation.

768



©2020 ‐ 385 ‐

Strategy and Concepts: IC Consideration769



Setting


Gate 0 Gate 2Gate 1










IC consideration • Output: Project Direction• Output: Product Delivery

Agreement

Approved/Not Approved




Setting


Gate 0 Gate 2Gate 1



©2020 ‐ 386 ‐





Disposal

Gate 0 Gate 2Gate 1

ApprovalsIC

Approval

IC, Government

Approval




Contestability

Activities

Smart Buyer

CM Needs




Smart Buyer


PFPS*

POCD*

PES 1JCNSJCN

FPS*

OCD*PES 2

IPMP

PES 3Reduced Risk

Sub

mis

sion

App

rova

l &

Dire

ctio

n

Sub

mis

sion

Project Activities

IMS

Sub

mis

sion

Product Activities

Contract Docs

IPMP

PDA/MAA

Contract Docs

IPdMP




Project Management


App

rova

l &

Dire

ctio

n

App

rova

l &

Dire

ctio

n


ffer

Acc

epta

nce

App

rova

l


Two aspects:

• Reducing the risk to the Commonwealth of:

– Failure:

• capability not provided, and

• excessive cost and unacceptable delays.

– Waste of taxpayer funds.

– Other adverse outcomes such as safety.

• Defining requirements sufficiently:

– Certainty of what is being acquired (legal obligation).

– Basis for accepting suppliers (and paying supplier).

772



©2020 ‐ 387 ‐


• Objective of Phase:

– reduce risk and define requirements:

• sufficient basis for government approval to acquire;

• establish a firm contractable position for acquisition; and

• Project prepared for Acquisition Phase.

773

Risk Mitigation



©2020 ‐ 388 ‐

Risk Mitigation in the CLC

Managing risk is an absolutely crucial part of the redesigned CLC.

“We often think that having a 6,000 line item risk register will solve all our problems; it doesn't. So where our focus is now on

identifying the risk at that point of the life cycle that is appropriate, and then working out the controls, making sure those controls are effective and monitoring the outcomes. We really need to rethink what we think risk management is all

about”.

VADM Ray Griggs, VCDF 2016

775

What is Risk in the Context of the CLC?

• CLC‐related risk is that capability investment (Project) will fail:

– delivered capability will not meet the need,

– costs become unaffordable,

– will be too late to address capability gap,

– can’t be maintained, and

– unsafe.

• Impact is that:

– Defence capability is deficient, and

– taxpayer money is wasted.

776



©2020 ‐ 389 ‐

Risk Reduction Mindset and Actions

• Risk reduction needed so that:

– approvals to spend public monies:

• based on confidence, and

• are defendable; and

– less likelihood that the Project will fail.



Disposal

Risk Reduction

Risk ReductionForce

Design

Reducing level of risk as risky aspects are treated/

Risk Mitigation and Smart Buyer

Smart Buyer is a structured approach for this process:

1. Define risk and drivers categories for Project and Product.

2. Identify risk events and impacts (analysis, workshops).

3. Capture drivers profile:

– risk rating;

– ranking.

4. Plan risk reduction (PES and IPMP).

5. Get approval and funding for risk reduction work.

778



©2020 ‐ 390 ‐







System Reviews

Smart Buyer Risk

Profile


Trade‐off studies

Trade‐off studies




Gate 0 Gate 2Gate 1

PES



Requirements Setting



©2020 ‐ 391 ‐

RM and RS Activities ‐ Purpose

• Requirements definition needed so that there is:

– clear understanding of what is being acquired; and

– sound basis to seek tenders and contract.

781

Requirements documents

Contract

Requirements Setting Overview

• Purpose: Define what is to be acquired:

– clear basis (legal obligation) for spending public monies;

– need it to enter into a contract; and

– can confirm that what has been delivered is acceptable.

782



Disposal

Risk Reduction

Risk ReductionForce

Design

Increasingly specific requirements which become ‘contract-ready’ specifications.



©2020 ‐ 392 ‐

Requirements Setting Overview

• Activity: Convert approved high level needs (JCN, JCNS) into contractable requirement—that is, contract documents.

• Method: Structured Systems (Requirements) Engineering.

• How much is to be done?: Sufficient to:

– provide adequate certainty about requirements;

– meet risk appetite of decision‐makers; and

– be used to seek tenders and contract.

• Who is involved?: CM, Systems Engineer / Requirements SME, FIC providers, and Delivery Group/s.

783

Source: Interim CLC Manual, Para 2.69

Sufficiency of Requirements

“Requirements need to be developed to a sufficient level of specificity to support industry engagements, capability

acceptance, and detailed analysis (particularly of implications for the fundamental inputs to capability) to understand the full

scope and broad feasibility and risks of the proposal.”

784



©2020 ‐ 393 ‐

Requirements Traceability785

DWP

FOE FJOC

AMS

AJOC

What and Why How

PGPA Act

CPRs

Force Design

CPN

JCN

IIP

DIP

DPPM



PESJCNS

Smart Buyer

OCD

FPS

IPMPProjectWBS

IMS



DPG

JCFConcepts

Strategic Guidance


Portfolio

Program

Project

Requirements: Program to Proposal‐level 786

DWP

FOE FJOC

AMS

AJOC

What and Why How

PGPA Act

CPRs

Force Design

CPN

JCN

IIP

DIP

DPPM



PESJCNS

Smart Buyer

OCD

FPS

IPMPProjectWBS

IMS



DPG

JCFConcepts

Strategic Guidance


Portfolio

Program

Project



©2020 ‐ 394 ‐



Program 1


Program Strategy


Project 1

FPSs

TCD

IPMP


Aligned: Related Projects and Products have common reference

JCNS 1

IPMP

JCNS 2

IPMP

JCNS 3

Project 2 Product 3

OCD

FPSs

TCD

OCD

FPSs

TCD

OCD



Program 1


Program Strategy


Project 1

Sect 1-4

FPSs

TCD

IPMP


Aligned: Related Projects and Products have common reference JCNS 1

IPMP

JCNS 2

IPMP

JCNS 3

Project 2 Product 3

OCD

FPSs

TCD

OCD

FPSs

TCD

Sect 5-7

OCD


New content



©2020 ‐ 395 ‐


DWP

FOE FJOC

AMS

AJOC

What and Why How

PGPA Act

CPRs

Force Design

CPN

JCN

IIP

DIP

DPPM



PESJCNS

Smart Buyer

OCD

FPS

IPMPProjectWBS

IMS



DPG

JCFConcepts

Strategic Guidance


Portfolio

Program

Project

Requirements: Core documents790

Functions and Performance Specifications: • What each systems’ functions are • How well they must perform them • Any constraints

Test Concept Document: • How the capability will be tested/proven

FPS 2

JCN

JCNS

OCD

FPS 1

TCD

Operational Concept Document: • Operational Needs of the whole Capability • All FIC



©2020 ‐ 396 ‐

Requirements Scope

• All FIC.

• Joint Force: Integration and Interoperability.

• Legislative and Regulatory Requirements.

• Whole of Product Lifecycle.

• Must be unambiguous and verifiable.

791

Mission System

Support System

Capability System

FPS 2

FPS 1

FPS 1

Organisation


SupportFacilities


Major Systems

Industry

Supplies

Capability (System)

Requirements for Mission System792


Capability System FPS 1

Systems engineering, requirements engineering, Integrated Logistics Support Practices apply.



©2020 ‐ 397 ‐

Requirements for Mission System

• Capability: operational, function, and performance.• Integration, Interoperability:

– C4ISR Interfaces.– Physical integration on platforms.

• Installation• Materiel Safety (such as WHS, Hazardous Chemicals).• Security.• Human factors.• Reliability, Maintainability, Obsolescence, Supportability.• Software. • Electromagnetic Environmental Effects (E3).• Environmental factors.

793

Requirements for Support System794


Capability System FPS 1



©2020 ‐ 398 ‐

Requirements for Support System

• Personnel requirements for maintenance activities.

• Sovereign support capability requirements.

• Technical data requirements (maintenance manuals).

• Location constraints.

• Component packaging.

• Transportability.

• Deployability, fault isolation and maintainability.

• Disposal requirements.

Systems engineering, requirements engineering, Integrated Logistics Support Practices apply.

795

Requirements Effort Across the CLC796

Use of Requirements

•Down-select solution classes

•Cost, Schedule Estimates

•Value Proposition

•Down Select to a solution class Cost/Capability tradeoffs

•Analysis of alternatives

•Down Select solution options

•Discriminate between vendor solutions

•Cost/Capability tradeoffs

•Government endorsed requirements as reference for upgrades etc

Level of effort

• Requirements monitoring throughout

•Refinement as a result of SRR

• Test and Trials design

JCN JCNS POCD PFPS

OCD FPS

• System Specification • Support System Specification• Functional Baseline• Product Baseline



Setting


Gate 0 Gate 2Gate 1



©2020 ‐ 399 ‐

Requirements Expertise797


Delivery Group Head

Program Manager


Manager





SME

Requirements SME

IPT


Engineering Function

• Policy and Practice• Requirements Advice • Engagement of Industry support• Requirements Service

Risk Mitigationand

Requirement Setting



©2020 ‐ 400 ‐

RM and RS Activities are Interdependent

• Interdependent activities (broadly a cycle):

– improve understanding of what is needed;

– reduce or eliminate risky aspects;

– make choices (such as ‘design’ decisions, down‐select options); and

– define requirements ready for contract.

799



Disposal

Risk Reduction

Risk ReductionForce

Design

RM and RS Activities are Interdependent 800

Make requirements/

‘design’ decisions

Reduce/treat risk factors

Understand needs/ context

Options

Reduce/treat risk factors

Make requirements

/ ‘design’ decisions

Options

Define more detail

Define more detail

$



©2020 ‐ 401 ‐

RM and RS Activities are Interdependent 801



Disposal

Risk Reduction

Risk ReductionForce

Design

LowerRisk

More‐specific requirements

+ • Authorities confident to spend• Defendable decisions

RM and RS – Incremental Commitment

• Progress achieved as more definitive proposals are presented at each decision point (Gates 0, 1, 2).

• Level of risk and definition of requirements corresponds to level of commitment (spending) by Defence.

802

Risk Reduction

Risk Reduction



©2020 ‐ 402 ‐


• Gate 0: higher uncertainty is acceptable when low levels of funding is being committed (eg just for risk reduction activities).

803

Risk Reduction

Risk Reduction

Commit funds for risk reduction activities




Gate 0 Gate 2Gate 1


• Gate 1: risk or uncertainty must be reduced so that there is confidence to approve funds in IIP.

804

Risk Reduction

Risk Reduction





Gate 0 Gate 2Gate 1

Commit funds for Project (IIP)



©2020 ‐ 403 ‐


• Gate 2: risk or uncertainty must be low enough that the Commonwealth is prepared to enter into a contract.

805

Risk Reduction

Risk Reduction





Gate 0 Gate 2Gate 1


Enter into major acquisition contract/s

RM and RS – Sufficient Definition to Contract

• Requirements derived so tenders can be sought and contract established

806

Risk Reduction

Risk Reduction





Gate 0 Gate 2Gate 1


Enter into major acquisition contract/s

FPS 2

JCN

JCNS

OCD

FPS 1

TCD

Operational Concept Document

Function and Performance Specifications

Test Concept Document



©2020 ‐ 404 ‐


(Gate 1)



Setting


Gate 0 Gate 2Gate 1

RM and RS

• Reduced risk profile

• Better defined requirements

• Options selected

808



Disposal

Risk Reduction

Risk ReductionForce

Design




©2020 ‐ 405 ‐

RM and RS

• Reduced risk profile

• Better defined requirements

• Options selected

809



Disposal

Risk Reduction

Risk ReductionForce

Design


Preliminary OCD, FPS, TCD

Gate 1 ‐ Purpose

• Gate 1 used:

– complex and high risk proposals

– government decision required to narrow field of options

• Approve proposals to proceed to Gate 2.

• CM is responsible for Gate 1 Proposal.

810



Setting


Gate 0 Gate 2Gate 1



©2020 ‐ 406 ‐

Gate 1 Proposal: Components May Include811

What?

How?

Requirements Statement

Updated PES

Integrated Project Management Plan (IPMP) to Gate 2

Why? Sponsor Paper

+

+

+

Draft Submission to Government Why?

+

Gate 1 Proposal

Gate 1 Proposal describes:

• results of risk reduction activities since Gate 0;

• progress in reducing options;

• progress in requirements definition,

• progress in cost estimation;

• plans (incl risk mitigation work) to proceed to Gate 2; and

• Industry engagement outcomes.

812



©2020 ‐ 407 ‐

Gate 1 Outcomes

• Government decision to:

– select specific option or options; and

– proceed with proposal to Gate 2 against agreed plan:

• timeframes,

• technical requirements, and

• financial commitments.

• Approval to engage industry through solicitation activities.

• Update to Project Direction.

• Gate 1 approval not a commitment to acquire.

813

Gate 0 to Gate 1: Summary 814




Gate 0 Gate 2Gate 1

• Output: Achieved reduced risk profile

• Output: - Project in IIP - approval to conduct solicitation

• Output: Contestability statement

Gate 1 Proposal

• Output: Gate 1 Proposal including: - draft Approval Submission to Govt- proposed option/s- updated PES - cost, schedule estimates- IPMP




• Output: Requirements Documentation eg Preliminary OCD, FPS, TEMP

GovernmentApproval



©2020 ‐ 408 ‐


Solicitation and

Source Selection





Solicitation and Source Selection Documents 816

Defence Documents

ASDEFCON Suite including:

• Conditions of Tender

• Conditions of Contract

• SOW

• OCD, FPS, TEMP

• Data Item Descriptions (DIDs)

Tenderer Responses

Tender documents which details the offer includes:

• Compliance Matrix

• Specifications

• Plans

• Costs

• Schedules

Source Evaluation

•Tender Evaluation

•Source Evaluation Report Must be robust and fully defendable



©2020 ‐ 409 ‐

Risk Mitigation and Requirement Setting (Gate 2)





Summary of pre‐Gate 2 Activities

• Risk Reduction.

• Requirements development.

• Options Refinement.

• Cost and Schedule Estimation.

• Industry Solicitation and Evaluation.

• Source Selection report development.

• Initial negotiations (if appropriate).

• Update PES.

• Project Management and Sustainment Planning.

818



©2020 ‐ 410 ‐

Gate 2 Proposal

• Proposal:

– Final PES.

– Draft Government Submission.

– Contestability Statement.

– Solicitation outcomes: Preferred Contractor.

• IC considers the proposal before Government.

819

Gate 2 Outcomes

• Government decision to acquire a fully defined and costed capability including:

– acceptance of risks;

– authority to conduct acquisition and sustainment; and

– assignment of budget, schedule, scope.

• Government approval:

– Allows commencement of the Acquisition Phase.

– Defence has authority, budget and timeframe to acquire a selected Product.

820



©2020 ‐ 411 ‐





Gate 0 Gate 2Gate 1

• Output: - reduced risk profile including options- final requirements docs (OCD, FPS, TEMP)

Risk Reduction /Requirements

Definition


Gate 0 Gate 2Gate 1



Definition

Solicitation

• Output:- Source Evaluation Report: preferred

solution / tenderer- Negotiating position






©2020 ‐ 412 ‐


Gate 0 Gate 2Gate 1




Definition

Solicitation







Gate 0 Gate 2Gate 1



Gate 2 Proposal

• Output: Gate 2 Proposal including: - draft Approval Submission to Govt- final PES- preferred contractor - updated PES - cost, schedule estimates


Definition

Solicitation








©2020 ‐ 413 ‐


Gate 0 Gate 2Gate 1


• Output: approval to acquire


Gate 2 Proposal




Definition

Solicitation



GovernmentApproval





Gate 0 Gate 2Gate 1


• Output: approval to acquire


Gate 2 Proposal




Definition

Solicitation



GovernmentApproval






©2020 ‐ 414 ‐

Summary of What to Take to the IC827

Use Gate 0 Gate 1 Gate 2Government CabSub or MinSub CabSub or MinSub


• IC Synopsis • Sponsor Paper:

- Business Case argument

- Contestability Statement

- Total Cost of Ownership (TCO)

- Industry considerations

• JCNS

• PES

• IC Synopsis • Sponsor Paper- no

longer than 3 pages • Draft Approval

Submission to Government either Ministerial submission or Cabinet Submission

• Draft Approval Submission to Government either Ministerial submission or Cabinet Submission

Key Considerations

Business Case, RiskAssessment and mitigation actions, Acquisition and Sustainment Strategies, IPMP, Cost Estimates, Workforce Estimates, Whole FIC

Business Case, Risk Assessment and mitigation actions, costs and schedule estimates, IPMP, Requirements (OCD, FPS, TEMP)

Business Case, Risk Assessment and mitigation actions, costs and schedule estimates,IPMP, Requirements (OCD, FPS, TEMP), Source Evaluation

Acquisition







©2020 ‐ 415 ‐

Acquisition

• Objective: acquire Capability:

– inclusive of FIC; and

– introduce it into service.

• Activity:

– Delivery Group formally transitions systems to CM.

• Primary task: IPM manages Project in accordance with:

– Gate 2 approval; and

– corresponding documents and agreements.

829

Acquisition Key Documents 830




IMSIPMP

Product Delivery

Agreement

Key Points

• IPM conducts acquisition in accordance with:• Gate 2 outcomes• Approved PES• Approved PDA• Approved IPMP including IMS• Contracts• Other approved agreements such as

strategic partnership agreements

Gate 2 Outcomes


PES

Contracts

Other approved agreements

Integrated Project Management Plan (IPMP)

Integrated Master Schedule (IMS)



©2020 ‐ 416 ‐

Acquisition: FIC

• IPM is responsible for delivery of FIC in two ways:

– Delivers FIC for which lead Delivery Group is responsible.

– Coordinates and integrates all FIC.

• Respective FIC delivery groups accountable for delivering their elements as agreed in plans/agreements (IPMP, PDA).

831

FIC

Materiel (CASG)

ICT (CIOG)

Facilities (E&IG)

Training (CM)

Integrated Project

Organisation

Command &Management

SupportFacilities


Major Systems

Industry

Supplies

Capability

Acquisition – Transition to In‐Service Phase 832




• Transition from Acquisition key milestones:– Initial Operational Capability (IOC).

– Final Operational Capability (FOC).

• At FOC the Project is closed and IPMT stood down.


IOC/OC (2)

FOCIOC/OC (3)

IOC (1)

Sustainment

Acquisition



©2020 ‐ 417 ‐


• Transition progressed through:

• Initial Operational Capability (IOC) releases.

• Final Operational Capability (FOC).

IOC (2)

FOC

IOC (3)

IOC (1)





Initial Operational Capability (IOC)

• IOC is the capability state relating to the in‐service realisationof the first subset of a capability system that can be employed operationally.

• Declaration of IOC is made by the Capability Manager, supported by the results of OT&E and declaration by the Delivery Group that the FIC have been delivered.

• IOC can be declared when one or more subsets of the capability can be deployed on operations.

• IOC considers all FIC required to deliver the subset of capability required.

834



©2020 ‐ 418 ‐

Final Operational Capability (FOC)

• FOC is the capability state relating to the in‐service realisation of the final subset of a capability system that can be employed operationally.

• Declaration of FOC is made by the Capability Manager, supported by the results of OT&E and declaration by the Delivery Groups that the FIC have been delivered.

• FOC is declared when the entire capability can be deployed on operations.

• FOC considers all FIC required to deliver the full capability

835






IOC (2)

FOC

IOC (3)

IOC (1)

• At FOC:

• Project closed.

• IPMT stood down.

• Integrated Product Manager IPdM assumes responsibility.

• IPMT transitioned to IPdMT and populated for sustainment effort.

• Sustainment conducted during Acquisition Phase from IOC.



©2020 ‐ 419 ‐






In‐Service and Disposal Phase

• In‐Service and Disposal Phase:

– operates capability;

– sustains Products that form the capability throughout their operational life; and

– withdraws the Products from service before disposed of or sold.

838



©2020 ‐ 420 ‐

IOC

IOC

In‐Service and Disposal Phase 839

• In‐Service and Disposal Phase commences when:

– Products accepted by CM from Delivery Group; and

– declaration of IOC.

• Acquisition and Sustainment can occur concurrently between IOC and FOC.




Gate 0 Gate 2Gate 1

Sustainment

Disposal

Acquisition

IOC FOC…

In‐Service and Disposal Phase

Acceptance of capability by CM is key objective based on:

• compliance:

– legislative requirements (such as environment andsafety); and

– regulatory requirements (such as seaworthiness);

• appropriate transition into in-service phase; and

• acceptable sustainment arrangements.

840



©2020 ‐ 421 ‐

In‐Service and Disposal: Key Documents841




Gate 0 Gate 2Gate 1

PDA

IPdMP

• Integrated Product Manager (IPdM) appointed.

• Integrated Product Management Team (IPdMT) established.

• Product Delivery Agreement / Materiel Support Agreement.

• Product Delivery Schedules.

• Integrated Product Management Plan.

PdS

IPdM

IPdMT

Can be established earlier if appropriate

Must be established before IOC, FOC

Evolved from IPMP during the Acquisition Phase

In‐Service and Disposal: Sustainment is Core842




Gate 0 Gate 2Gate 1

• Sustainment: in‐service support activities. • Focus: meeting specified preparedness requirements at minimised life‐cycle cost.

• Successful sustainment outcomes rely on good Product Management from earliest stages of CLC.

Sustainment

Product life cycle



©2020 ‐ 422 ‐

Sustainment

• Defence defines sustainment as provision of:

– personnel, logistics and other support required tomaintain and prolong operations or combat; and

– goods and services required to achievepreparedness (readiness and sustainability) goals forlife of Defence element.

843

Sustainment

• Sustainment activities include:• routine sustainment work

– Maintenance; and– provision of spares, supplies.

• managing changes to:– preparedness levels; and– operating concept.

• managing:– obsolescence,– incorporating planned technology refresh,– upgrades to maintain capability, and– OEM recalls.

844



©2020 ‐ 423 ‐

Sustainment Business Cycle845




Gate 0 Gate 2Gate 1

Sustainment

• Meet specified preparedness requirements at minimised life‐cycle cost.

• PDA/MSA:

– reviewed, updated at least annually:

– ensure resources match agreed performance levels,

– basis for budget allocations, and

– basis for sustainment performance management and reporting.

Sustainment Business Cycle846




Gate 0 Gate 2Gate 1

Sustainment

• PGPA Act requires all Commonwealth entities to report results against plans in an annual performance statement.

• “Parliamentary committees over several years have stated an interest in Defence’s reporting of its sustainment performance and, in particular, obtaining greater insight into that performance”.

Source: ANAO Report No. 2 2017–18 Defence’s Management of Materiel Sustainment, Para 1.4



©2020 ‐ 424 ‐

Sustainment Business Cycle: Annual Review847

Planned vs ActualPerformance

PDA

PdS

Sustainment Performance Measurement System (SPMS)

Time

Ava

ilabi

lity

Agreement

Product Delivery Agreement

Product Schedules

Re-prioritised sustainment funds

Time

Ava

ilabi

lity

CM revises annual bid to Defence Enterprise Business Committee (EBC)

Sustainment Data

SPMS

Sustainment Planning and Management848




Gate 0 Gate 2Gate 1

Sustainment

• IPdMs manage updates to PDAs/PdSs and budget estimates including:

– Sustainment Plans and Schedules.

– Cost Estimates.

– Risks and emergent changes.

– Communicating impacts.

– Cost‐capability trade‐offs.



©2020 ‐ 425 ‐

Projects Within the In‐Service Phase




Gate 0 Gate 2Gate 1Upgrade Project

• Projects can be established during In‐Service and Disposal Phase.

• Project construct and Project Management principles apply including:

– Project Sponsor appointed.

– IPM appointed.

– IPMT established.

849

Product Management/ Sustainment/ ILS 850




Gate 0 Gate 2Gate 1

Sustainment

• Successful sustainment relies on Materiel Logistics/ Integrated Logistics Support practice early in CLC.

• Analyses such as:

• Supportability Analysis.

• Logistics Support Analysis (LSA).

• Reliability Availability Maintainability (RAM).

• Life Cycle Costing Analysis (LCCA).



©2020 ‐ 426 ‐

ILS

• Ensures that availability, supportability, and lifecycle cost of capability is considered during design and development of mission and support system.

• ILS practitioners:

– influence system requirements and design;

– define support elements for capability lifecycle; and

– contribute to planning and management of support system.

851

Disposal / Retirement

• Process of removing systems from service:

– unsuitable, or

– surplus.

• Must be approved by appropriate CM.

• Materiel Logistics Disposal and Sales (MLDS) responsible for planning and implementation.

• Divided into minor and major disposals:

– Sale

– Scrap

– Transfer

852

– Gifting

– Conversion/re‐use

– Destruction



©2020 ‐ 427 ‐

Disposal / Retirement

• Directorate of Military Disposals:

– responsible for disposal of major Defence equipment and capability platforms.

• The role of the directorate is to:

– plan and facilitate disposals of major items;

– provide a centre of expertise in disposals; and

– maintain a register of interest from public organisationsfor disposal of Defence major items.

• Governed by both Australian and foreign government legislation and policy.

• You can register your interest in the disposal of a Defenceasset such as an Army vehicle.

853

https://www.defence.gov.au/CASG/DoingBusiness/Internationalengagementandexportsupport/Military%20disposals.asp

CLC Artefacts and Documents



©2020 ‐ 428 ‐

Meaning of Artefact

• We will use artefact as any means of communicating information associated with the CLC including documents, models, plans, architectures, and proposals.

855





Disposal

Gate 0 Gate 2Gate 1

ApprovalsIC

Approval

IC, Government

Approval




Contestability

Activities

Smart Buyer

CM Needs




Smart Buyer


PFPS*

POCD*

PES 1JCNSJCN

FPS*

OCD*PES 2

IPMP

PES 3Reduced Risk

Sub

mis

sion

App

rova

l &

Dire

ctio

n

Sub

mis

sion

Project Activities

IMS

Sub

mis

sion

Product Activities

Contract Docs

IPMP

PDA/MAA

Contract Docs

IPdMP




Project Management


App

rova

l &

Dire

ctio

n

App

rova

l &

Dire

ctio

n

Contract Management

Off

er

Acc

epta

nce

App

rova

l



©2020 ‐ 429 ‐

Implementing the CLC (Example) 857



Risk Reduction,

Requirements DefinitionOCD, FPS,

TCD

Solicitation RFT, SER


POCD, PFPS, PTCD


Contract Mgt Force Design:

JCNContract Mgt

Define Need:JCNS

Smart Buyer Risk

Profile and

Strategy definition:

PES

SE Review

Risk Mgt

Assurance Reports

Product MgtProject Mgt


Contesta-bility





Scope of Artefacts Being Covered

• Key CLC artefacts can be divided into two broad categories:

– Program for proposals or as common references for subordinate Projects/Products.

– Project/Product for proposals.

858



©2020 ‐ 430 ‐

Implementing the CLC

• Next section will use the examples introduced on Day 1:

– IAMD; and

– Electronic Support (ESM).

• Examples will step us through the key CLC artefacts and documents leading up to Gate 2.

• Following slides are provided for reference reflecting latest known guidance with focus on new documents (to Gate 2).

859

CLC Artefacts Covered in this Course860

DWP

FOE FJOC

AMS

AJOC

What and Why How

PGPA Act

CPRs

Force Design

CPN

JCN

IIP

DIP

DPPM



PESJCNS

Smart Buyer

OCD

FPS

IPMPProjectWBS

IMS



DPG

JCFConcepts

Strategic Guidance


Portfolio

Program

Project



©2020 ‐ 431 ‐

Key CLC Artefacts

• Program‐reference:

– Capability Program Narrative (CPN).

– Program Strategy.

– Program Integrating Operational Concept (PIOC).

• …

861

Key CLC Artefacts

• …

• Proposal Artefacts at Program, Project, or Product level:



– Project Execution Strategy (PES).

– Business Case which supports Proposals and Submissions.

– Integrated Project Management Plan (IPMP).

– Capability Definition Documents (CDD).

• Operational Concept Document (OCD).

• Function and Performance Specification (FPS).

• Test and Evaluation Master Plan (TEMP).

862



©2020 ‐ 432 ‐

Program Artefacts

Program Example: IAMD

• The term ‘IAMD’ commonly used by defence organisations.

• Generally described as defence against:

– conventional air threats eg aircraft, unmanned aerial vehicles, helicopters, (air defence); and

– missiles eg ballistic and cruise missiles (missile defence).

864



©2020 ‐ 433 ‐


• Integrated:

– Operational and technical collaboration between systems.

– Military advantage.

865



• Largely based on data or information exchange.

• Focus on Command Control Communication Computer Intelligence Surveillance and Reconnaissance (C4ISR) elements.

• C4ISR are “systems, procedures, and techniques used to collect and disseminate information”.

866



©2020 ‐ 434 ‐

IAMD Key Components

• Key components of IAMD system:

– Sensors: detect threats.

– Command and Control: Battle Management System (BMS):

• information collection, processing, dissemination.

– Effectors/weapons: respond in some way to the threat.

• IAMD also uses ‘layers’ of defence for the different types of threats so:

– Short‐range.

– Medium‐range.

– Long‐range.

867

IAMD: In Summary

• Air Defence: conventional air threats eg aircraft, unmanned aerial vehicles, helicopters.

• Missile Defence: ballistic and cruise missiles, hypersonic.

• Unified Operations: information exchange/ interoperability.

• Layered Defence.

868




©2020 ‐ 435 ‐

Possible Components of IAMD869


Eg HF, VHF


Joint Battle Management System

Deployable Ground Weapons


Eg Frigates

Airborne Relay Sensor

Sensor

Sensor

Command and Control

Effector

Effector

Effector

IAMD: SoS and Program

• IAMD is an example of a System of Systems (SoS) which corresponds to a CLC Program.

• Constituent systems correspond to constituent Projects and Products.

870

Project A

Project B

Project C

IAMD SoS


Eg HF, VHF


Joint Battle Management System

Deployable Ground Weapons


Eg Frigates

Airborne Relay










Project A

Project B

Project C

IAMD Program



©2020 ‐ 436 ‐

Australian Defence Force IAMD

• ADF IAMD Program announced in 2016 Defence White Paper.

• “A modern and integrated ground‐based air defence system is needed to protect our deployed forces from increasingly sophisticated air threats, both globally and within our region”. Ref: Minister for Defence, 10 April

2017

• Good reference: The Sir Richard Williams Foundation.

871

Three Elements of ADF IAMD

1. Upgrade of ADF’s existing air‐defence system:

– Includes C4I systems and sensors.

– Long range‐air‐defence.

– Vigilare (250 separate interfaces).

872

https://www.airforce.gov.au/technology/aircraft/intelligence‐surveillance‐and‐reconnaissance/e‐7a‐wedgetail



©2020 ‐ 437 ‐


2. Joint Battle Management System (BMS):

– Coordinate and synchronise ADF operations.

– Interconnect platforms, systems, sensors.

– Across air, land, sea, space, cyber.

– Provides shared situational awareness.

873

Source: http://www.defence.gov.au/dmo/EquippingDefence/LAND‐75‐ph3.4‐BMS


3. Ground‐based air‐defence capability (GBAD):

– Surface to air system (short‐range).

– Improves protection for deployed personnel (incl man‐portable systems).

874

http://www.australiandefence.com.au/news/2‐billion‐for‐nasams‐gbad‐system



©2020 ‐ 438 ‐

Elements of IAMD

• First two IAMD Projects:

– Land19 Phase 7B: Army’s Ground Based Air Defence missile system comprising Radar plus Missile.

– AIR 6500: Upgrade or replacement of the ADF's existing air defence systems.

875

Land19 Phase 7B

AIR 6500 Phase 1

AIR 6500 Phase 2

Indicative only










Project A

Project B

Project C

IAMD Program

Recap of Program Layer

876



©2020 ‐ 439 ‐

Program

A program is a group of related projects managed in a coordinated manner to obtain benefits not available from managing them individually. Program management is the application of knowledge, skills, tools and techniques to meet program requirements.

Source: PMI website

A Program, in the context of managing Defence capability, is defined as a group of related Projects, Products, and activities that are managed in a coordinated way to optimise capability outcomes within allocated resources.

Source: Interim Capability Life Cycle Manual

877

Objectives of Programs

• Programs in the Defence context generally of two types:

– Operational outcomes eg joint capability.

– Resource commonality eg common systems or resources (eg fuels) which provide efficiencies.

878

Integrated Air and Missile Defence (IAMD)

Fuel



©2020 ‐ 440 ‐

Program Approach—Benefits

• Can better prioritise across Defence Portfolio.

• Improves the strategic view for government direction.

• Efficiencies across similar Products and Projects.

• Facilitates Joint Force by Design.

879

CLC Program Artefacts880

DWP

FOE FJOC

AMS

AJOC

What and Why How

PGPA Act

CPRs

Force Design

CPN

JCN

IIP

DIP

DPPM



PESJCNS

Smart Buyer

OCD

FPS

IPMPProjectWBS

IMS



DPG

JCFConcepts

Strategic Guidance


Portfolio

Program

Project



©2020 ‐ 441 ‐

Program Artefacts as a Common Reference

• Program‐level artefacts provide an overarching reference for constituent Projects and Products.

– Program: Parent artefact

– Project and Product: Subordinate artefacts

• Aligned: Related Projects and Products reference common Program information to enable aligned and, where appropriate, joint force outcomes.

• Efficient: Each subordinate artefact leverages the parent artefact so that only the essential ‘delta’ is developed.

881

Program Artefacts: Aligning Project/Products 882


Program 1


Program Strategy


Project 1

FPSs

TCD

IPMP

JCNS 1

Project 2 Product 3

OCD




• ‘Town Plan’

JCN 1

PES

FPSs

TCD

IPMP

JCNS 3

OCD

JCN 3

PES

FPSs

TCD

IPMP

JCNS 2

OCD

JCN 2

PES



©2020 ‐ 442 ‐

Program Layer as Reference for Requirements883


Program 1


Program Strategy


Project 1

Sect 1-3

FPSs

TCD

PES/IPMP



PES/IPMP

JCNS 2

PES/IPMP

JCNS 3

Project 2 Product 3

OCD

FPSs

TCD

Sect 4-6

OCD 1


New content

Sect 1-3

FPSs

TCD

Sect 4-6

OCD 2

Program Layer as Reference for Plans884


Program 1


Program Strategy


Project 1

Sect 1-3

FPSs

TCD

PES/IPMP



PES/IPMP

JCNS 2

PES/IPMP

JCNS 3

Project 2 Product 3

OCD

FPSs

TCD

Sect 4-6

OCD 1


Sect 1-3

FPSs

TCD

Sect 4-6

OCD 2



©2020 ‐ 444 ‐

Program References: Aligning Project/Products 887


Program 1


Program Strategy


Project 1

FPSs

TCD

PES1/ IPMP1

JCN1/

JCNS 1

PES2/IPMP2

JCN2/

JCNS 2

PES3/IPMP3

JCN3/

JCNS 3

Project 2 Product 3

OCD

FPSs

TCD

OCD

FPSs

TCD

OCD




• ‘Town Plan’


• Raised by Force Design Division

• Enduring Program‐level direction including concepts and requirements.

• ‘What’ and ‘Why’.

888



©2020 ‐ 445 ‐


• Provides the Capability Manager with a synopsis of:

– operational environment,

– constraints,

– governance,

– Joint Force needs, and

– sustainment arrangements and priorities where relevant.

• Distils strategic and conceptual guidance into actionable deliverable terms.

• Contestability reviews the strategic fit of the CPN.

889

Possible IAMD CPN – Key Components

• Vision of what IAMD is and how it will operate to address the threat.

• Narrative of:

– IAMD operational context including threats;

– what the Program is trying to achieve operationally;

– constituent capabilities and how they will need to work collectively;

– interoperability, integration and commonality constraints internal and external to the Program:

• materiel solutions; and

• support arrangements.

890



©2020 ‐ 446 ‐

Possible IAMD CPN—Why

eg: Increasingly sophisticated air and missile threat to deployed forces:

– globally and within our region; and

– likelihood that it will increase in years ahead.

891

Why: Threat

Possible IAMD CPN—What

eg: Require modern and integrated ground‐based air defencesystem:

– integration of offensive and defensive operations against air‐breathing and missile threats, to counter an enemy’s ability to degrade or disrupt our operations and projection of combat power in a contested environment; and

– fuse and share information to enhance accuracy and speed of ADF's systems response to threats.

892

What: Operational Effects



©2020 ‐ 447 ‐


eg: Flexibility for further enhancement to handle more complex threats and to integrate new technologies as they emerge.

What: Required Features

893

Possible IAMD CPN—What (I2)

eg: IAMD is a shared responsibility that will require integrated operations between all three Services, supported by Government Agencies, and integrated, where appropriate, with allied and coalition forces.

eg: better connect the communications, sensor and targeting systems of various platforms so that they can more effectively combine their capabilities, generating greater potency and lethality”.

Eg: ensuring that the delivered system is able to fuse and share information to enhance the accuracy and speed of ADF's systems response to air and missile threats”.

894

What: Integration and Interoperability Sources: • https://gateway.icn.org.au/project/4022/air‐6500‐joint‐battle‐management‐and‐integrated‐air‐and‐missile‐defence‐system• Integrated Air and Missile Defence Study: The Challenge of Integrated Force Design Air Vice‐Marshal John Blackburn April 2017



©2020 ‐ 448 ‐


eg: Must include:

– expanded access to air and space situational awareness information, including through space‐based systems;

– ground‐based active electronically scanned array radars;

– consider integrating CEA phased array radar in a ground‐based role; and

– meet defined sovereign capabilities (including support).

895

What: Specific Inclusions and constraints


For example:

• Upgrade of the ADF’s existing air‐defence systems, including C4I systems and sensors.

• Joint Battle Management System to better coordinate and synchronise ADF operations.

• Future ground‐based air‐defence system:

– short‐range man‐portable surface to air system; and

– medium‐range surface‐to‐air missile system.

896

What: Actionable Deliverable Terms



©2020 ‐ 449 ‐

Program Integrating Operational Concept(PIOC)

897



Program 1


Program Strategy


Project 1

FPSs

TCD

PES1/IPMP1

JCN1/

JCNS 1

PES2/IPMP2

JCN2/

JCNS 2

IPMP

JCNS 3

Project 2 Product 3

OCD

FPSs

TCD

OCD

FPSs

TCD

OCD




• ‘Town Plan’



©2020 ‐ 450 ‐

PIOC: Overview

• Who develops it?

– Program Sponsor; and

– requires endorsement from Joint Force Authority (VCDF)

• When is it developed?

– when a Program is established and then maintained.

• Support provided by VCDF Group:

– Joint Force Authority (JFA);

– Force Integration Division (FID):

• Joint Integration and Capability Assurance (JICA); and

• C4ISR Design Authority.

899

PIOC: Intent

• Top‐down design documents on Integration and Interoperability.

• Achieve a Joint Force by Design.

• Limit ‘after market’ integration.

• Uniform, consistent overarching design direction to constituent systems (related Programs, Projects, and Products).

• Reduce detail in subordinate documentation.

• Identify I2 risks and define risk reduction actions.

900



©2020 ‐ 451 ‐

PIOC: Architecture Information 901

Source: http://www.defence.gov.au/casg/EquippingDefence/JCG02‐JointCapabilitiesGroup

PIOC: Architecture Information 902

Operational View

Warfighter Relationships and Information Needs

Technical View

Prescribes Standards and Conventions

Systems View

Relates Capabilities and Characteristics to Operational

Requirements

Technical Criteria for implementing interoperability


Systems Associations to Nodes, Activities, Needlines, and Requirements




©2020 ‐ 452 ‐

PIOC Possible Content: Operational

Operational view:

• mission; scenarios; policies and doctrine; needs and constraints

• Program boundary and content

• IAMD operations (scenarios): Concept of Operations (CONOPS)

• Operational roles and responsibilities

• Collaboration requirements in coalition/sovereign operations

• Operational dependencies including definition of Information Exchange Requirements (IERs)

903

PIOC Possible Content: Traceability

• Traceability to relevant higher level guidance, for example:

– Joint Supporting Concept.

– Integration Operational Concept (IOC) Integrating Objectives.

– directed I2 requirements eg Mode 5 IFF or Link 16.

904



©2020 ‐ 453 ‐

PIOC: Captures Detail on I2 Requirements

• General features:

– Fully networked sensors and shooters.

– Resilient, ubiquitous, interoperable network.

– Joint priorities and formats.

• Specific Requirements

– Use of Tactical Data networks (TDL).

– Information Integration: receiving, processing, fusing mass information from AS and Coalition networks:

• Satellite and UAV imagery.

• electronic and signals intelligence.• space‐based infrared systems.

• voice and data intelligence inputs.

905

PIOC: Identifies Applicable Systems for I2

• Integration aspects:

– extant/planned communications systems,

– extant/planned command and control, and

– extant/planned geospatial and intelligence products.

• Interoperability aspects:

– E‐7 Wedgetail,

– Air Warfare Destroyer (Aegis),

– SEA 5000 Future Frigate,

– P8,

– Triton,

– F‐35A,

– F/A‐18 Super Hornet and Growler,

– Key Allies.

906



©2020 ‐ 454 ‐

PIOC: Specify Technical Requirements907

Introducing a Reference Model for Measures of Merit for Coalition Interoperability, Andreas Tolk, June 2003

Source: http://fi-ghent.fi-week.eu/fia-session-i-linked-open-data/

Open Systems Interconnection

(OSI) model

Coalition Interoperability

“Tolk” Model

PIOC: ‘Umbrella’ Design Document (I2)

• Provides design guidance in form of:

– Program needs;

– Program‐level architectures:

• derived from joint war fighting architectures; and

• supported by C4ISR Design Authority.

– Program‐wide process and technical standards—such as Technical Data Links Interoperability (Link 11,16, 22); and

– Joint Force requirements including US Interoperability.

• Can use Defence Architecture Frameworks.

• IAMD would consult with C4ISR Design Authority.

908



©2020 ‐ 455 ‐

PIOC: Sets up Program Assurance

• Program T&E is achieved through coordination of T&E activities for constituent Projects and Products.

909

Program Strategy

910



©2020 ‐ 456 ‐



Program 1


Program Strategy


Project 1

FPSs

TCD

PES1/IPMP1

JCN1/

JCNS 1

PES2/IPMP2

JCN2/

JCNS 2

IPMP

JCNS 3

Project 2 Product 3

OCD

FPSs

TCD

OCD

FPSs

TCD

OCD




• ‘Town Plan’

Program Strategy


– Program Sponsor on behalf of the CM based on the CPN.


– When a Program is established and then maintained.

• What is its intent?

– Ensures Program‐level capability (CPN) over time.

– Maintains pipeline of proposals/ activities to meet CPN.

– Gaps and opportunities managed/ prioritized.

912



©2020 ‐ 457 ‐

Program Strategy: Delivering CPN over Time913

Eg Current Air Defence Systems

2019 2025 2030

System 1

System 2

System 3

System 4

System 1

+

System 2

+

+

+


System 3

System 2

System 6

+

Required IAMD Capability (CPN)

+

System 2

System 6

+System 7


2035

Program Strategy

• Why is it produced?

– defines how CPN will be achieved.

– primary document for leading, managing and developing capabilities to satisfy Program outcomes.

– helps Program Sponsor coordinate activities of:

• Capability Manager,

• Delivery Groups, and

• Enabling Groups.

– assists industry guidance and planning.

914



©2020 ‐ 458 ‐

Program Strategy

What is in the Program Strategy?

• Integrated planning view of Projects and Products including FIC.

• How Program will acquire, transition and sustain agreed capabilities.

• Coordination of sustainment for all Products.

• Program‐level industry opportunities and constraints.

• Program‐level risks and risk mitigation.

915

IAMD Program: Project Elements 916

Upgraded or Replaced C4I

Ground Based Sensors

Land19 Phase 7B

AIR 6500 Phase 1

Medium-Range Ground Based Air and Missile

Defence Effector

AIR 6500 Phase 2Gate 0 – Feb 20 Gate 1&2 – Apr 22

Short-Range Ground Based Air and Missile

Defence Effector

Contributing Projects: SEA4000, SEA5000, AIR5077, AIR6000…

Overlapping FIC requirements and planning • Common training and workforce• Coordinated Sustainment

IOC FY22/23

IOCFY25/26

FOCFY28/29

IOC2023

FOC2025

FOCFY28/29



©2020 ‐ 459 ‐

IAMD Program Strategy

• “The critical issue is that an IAMD Program cannot be built purely bottom‐up if it is to be both effective and affordable; a top‐down direction and focus is essential. There is a need for an IAMD Program Roadmap, that is a Directive and not only a recommendation.”

Reference: Williams Foundation Integrated Air and Missile Defence Study 2017

917

Possible Program Strategy Content*

• Govt direction, strategic guidance.

• Defined outcomes and outputs (including priorities).

• Resource, funding, FIC allocation requirements and priorities.

• Key risks, risk mgt actions incl escalation approach.

• Identification of all constituent Proposals, Projects, Products, relationships/dependencies across operational, technical and programmatic aspects including :

– schedule and delivery milestones;

– activities (eg interface definition);

– resourcing including budget and workforce; and

– FIC elements.

• …

918

*No guidance available at time of ‘printing’.



©2020 ‐ 460 ‐

Possible Program Strategy Content

• …

• Linkages and critical dependencies with other Programs

• Stakeholders, Governance and Management forums.

• Requirements (including standards) for Integration and Interoperability.

• Program‐level assurance program including T&E concept.

• Activities to transition into service and sustainment.

• Development gaps and opportunities to inform Force Design.

• Information management incl Program architecture info.

• 12‐month (rolling) Plan: review points, milestones.

• Key Performance Metrics.

919

Program Strategy Reviews

Reviews of Program Strategy:

– Program Sponsor responsible for periodic reviews of Program Strategy to identify, mitigate risk in Program.

– IC may direct that Contestability conducts a review.

920



©2020 ‐ 461 ‐

Program CLC Artefacts921

Artefact Description Developed by Authority

CPN: Narrative which inform required capability of the subject group of capability systems

Force Design Division

Force Design Division

PIOC: Operational and other features of the capability grouping both within the Program and relationships with other Programs

Program Sponsor Program Sponsor

Endorsed by Joint Capability Authority

Program Strategy:

Activities, management arrangements, including integrated schedule across related Projects and Products within the Program

Program Sponsor Program Sponsor

Program Architectures:

Program features using Defence Architecture Framework (DAF) conventions

Program Sponsor/C4ISR Design Authority

Program Sponsor/C4ISR Design Authority

Proposal‐level Artefacts

922



©2020 ‐ 462 ‐


DWP

FOE FJOC

AMS

AJOC

What and Why How

PGPA Act

CPRs

Force Design

CPN

JCN

IIP

DIP

DPPM



PESJCNS

Smart Buyer

OCD

FPS

IPMPProjectWBS

IMS



DPG

JCFConcepts

Strategic Guidance


Portfolio

Program

Project

CLC Case Study



©2020 ‐ 463 ‐

CLC Proposal Case Study

• Aspects of CLC re‐design have been implemented in successful projects.

• This Case Study based on an actual Defence project that has used elements of CLC approach.

• We will look at how CLC may have been applied focusing on S&C and RM&RS Phases:

– approach to be adopted;

– activities to be undertaken; and

– documents to be produced.

925

SEA 1448 Ph4A Project: ESM

• Electronic Support Measures (ESM):

– Used on RAN ships to detect and identify (classify) adversary’s radars.

– A bit like a music recognition application.

• Comprises antenna and processing equipment.

• Integrates and displays on the Combat System.

926

Sources: https://images.defence.gov.au/https://www.harris.com/solution/es‐3701s‐precision‐radar‐esm‐system



©2020 ‐ 464 ‐

SEA 1448 Ph4A Project: Key Factors

• Multiple platforms across 3 ship classes.

• Installation must be synchronised with availability of ships.

• Different installation requirements dependent on class:

– physical installation differences; and

– differences in Radio Frequency (RF) ‘noise’ situation.

• Multiple system vendors to create the system.

• Multiple installation contractors to install systems on ships.

• Time pressure to enable deployment of vessels with this capability.

927

Implementing the CLC—Example 928



Risk Reduction,

Requirements DefinitionOCD, FPS, TEMP

Solicitation Tendering & Contracting

docs


POCD, PFPS, TEMP


Contract MgtForce Design: JCN

Contract Mgt





Define Need:JCNS

Smart Buyer Risk

Profile and Strategy definition:

PES

SE Reviews

Risk Mgt

Assurance Mgt

Product MgtProject Mgt


Contesta‐bility



©2020 ‐ 465 ‐

Case Study: SEA 1448 Phase 4A

We will look at the case study in terms of what would have been done and produced under the CLC touching on:

• CLC process, frameworks and management constructs such as Programs and Smart Buyer.

• Enabling Practices:


– Project Management.

– ILS.


– Risk Management and Assurance.

• Then we will look at it in terms of artefacts and documents to be developed.

929

Joint Capability Narrative (JCN)

930



©2020 ‐ 466 ‐

JCN


– Force Design Division (Force Options and Plans Branch).


– When a capability need or enabling gap or opportunity identified.


– Used to task appropriate CM to develop a more detailed JCNS.

– Prepared as the rationale for an investment proposal.

931

JCN

• What is in a JCN?

– Provides a conceptual framework for a defined gap or opportunity and ensures joint needs are clearly aligned with strategic guidance.

– Articulates gaps, risks, issues or opportunities and the CM’s plan to meet the problem posed.

– Articulates time, resource constraints and strategicconsiderations.

932



©2020 ‐ 467 ‐

ESM Example: Capability Gap 933

In the case of the ESM…

Navy recognised a vulnerability for their platforms.

Determine Gaps and Opportunities

Prioritise and identify possible options

Recommend response

Approve recommended response

Assess current force

CM identified gap

JCN

• In the absence of JCN, use FSR Narratives and IIP funding profiles as reference.

• Contestability reviews the JCN as one of the Force Design outputs.

• JCNs are still being developed.

934



©2020 ‐ 468 ‐


935

JCNS


– Program Sponsor as tasked by CM through a tasking statement.


– When a capability need or enabling gap or opportunityidentified through a JCN and the CM assigns a Program Sponsor.

– A key output of the Strategy and Concepts Phase.


– An agreed statement of military or enabler need, which determines the capability required to deliver on strategic guidance.

936

Source: Update Interim CLC Manual



©2020 ‐ 469 ‐

Strategic Guidance and the JCNS

• In the absence of the JCN and/or CPN, the JCNS must clearly link to (but not repeat) most recent strategic guidance:

– FSR Narratives.

– Defence White Paper 16.

– Force Structure Review.

– Defence Planning Guidance (DPG).

– Australian Military Strategy (AMS).

– relevant Strategic Policy and Joint Concepts.

– IIP funding profiles.

937

• Strategic Guidance: RAN ships need be able carry out their mission safely and defend themselves.

JCNS

• What is in it?

– high level statement of an identified and bounded capability need and available option sets;

– represents a defined and bounded system solution to the capability gap

– …

938




©2020 ‐ 470 ‐

ESM Capability Gap 939

Capability Gap

Capability performance gauged on the basis of: • ability to detect and classify radars/threats(ranges and types); and

• Reliability.

Leve

l of C

apab

ility

Decline in performance due to aging system

Higher performance expected due to:• more challenging

threats• Improved

available technology

JCNS

• What is in it?

– high level statement of an identified and bounded capability need and available option sets;

– represents a defined and bounded system solution to the capability gap

– …

940

• Capability gap/need: system that can detect and classify contemporary radars and operate with required reliability

• Action: Replace existing ESM system • Options:

• augment current system with extra functionality• existing whole system product with lower performance• integrated solution created for RAN

• Solution: Integrated solution that fully meets capability need




©2020 ‐ 471 ‐

JCNS: Hierarchy of objectives

• What is in it?

– …

– system need described as a hierarchical structure of objectives including FIC to address the gaps and opportunities posed in the JCN;

– …

941


JCNS: Hierarchy of Objectives 942

Ability to classify radars

Provide data to combat system

Ability to detect radars



©2020 ‐ 472 ‐

JCNS: Hierarchy of Objectives

• What is in it?

– …

– system need described as a hierarchical structure of objectives including FIC to address the gaps and opportunities posed in the JCN;

– …

943

Hierarchy (priority) of capability objectives: • ability to detect and classify radars; • ability to record the technical and operational data of those

radars, • ability to provide data to the combat system for tactical

purposes, and • design and support arrangements to provide very high reliability.


JCNS: System Characteristics

• What is in it?

– …

– system characteristics;

– …

944




©2020 ‐ 473 ‐

JCNS: System Characteristics 945

Source: https://www.nasa.gov/content/electromagnetic-spectrum/

59o

44o

Bearing

Frequency Spectrum

Dynamic Range

JCNS: System Characteristics

• What is in it?

– …

– system characteristics;

– …

946

System characteristics: • frequency spectrum of interest • dynamic range (low to high power)• ability to discriminate signal of interest from other EM radiation • precision of angle of arrival for bearings to locate the transmitter• number of receivers needed for surveillance of the necessary

spectrum




©2020 ‐ 474 ‐

JCNS: Joint Capability and FIC Integration

• What is in it?

– …

– contribution to joint capability with FIC integration issues highlighted and interdependencies defined;

– …

947

Joint Capability and FIC integration : • use a common system on multiple classes: ANZAC, AWD, LHD; • interface commonality especially with combat management

systems; and• efficiencies in training, maintenance and spares etc.


JCNS: Relationship with Other Programs

• What is in it?

– …

– relationship with other Programs;

– …

948




©2020 ‐ 475 ‐

JCNS: Relationship with Other Programs949

EW Libraries

Facility Refurb

Anti-Ship Missile Defence (ASMD) Project

SEA 1448 Ph4A Project: ESM

LHD Project AWD Project


• What is in it?

– …

– relationship with other Programs;

– …

950


Relationship with other Programs : • facility development (such as JP 500 EW – EW Operations Support

Facility);• development of EW libraries; and• major ship programs (such as ASMD).



©2020 ‐ 476 ‐


• What is in it?

– …

– describes CM’s plan to meet the problem posed by the JCN.

951


Capability Manager’s Plan: • establish Stand‐alone Project for common‐use system;• leverage and align with related efforts;• align with docking cycle for ASMD upgrade; and• achieve commonality across ship classes

JCNS: Review

• Who reviews and/or approves the JCNS?

– Contestability Division reviews JCNS to test if:

• aligns with Strategic Guidance;

• aligns with resourcing provisions; and

• can be delivered within resourcing direction.

– Presented at Gate 0 for approval by IC.

– Defence Committee (DC) reviews JCNS only for:

• most complex, politically sensitive, novel, high risk;

• where diverges from established policy; and

• needs to endorse further development of selected options.

952




©2020 ‐ 477 ‐

Key Features Required of the JCNS

• Strategic Alignment and Program Coherence.

• Justification: evidence supported by logic, traceability.

• Prioritisation of Needs in plain English.

• Consideration of Joint Force, Integration and Interoperability.

• Consideration of all FIC.

• Scheduling issues.

• Systems approach:

– structured derivation of requirements,

– recognition of SoS, and

– clear bounding of the system need to reflect capability gap or opportunity.

953


954



©2020 ‐ 478 ‐




Setting


Gate 0 Gate 2Gate 1





PES – Key Points


– Delivery Group in close consultation with CM.


– prior to Gate 0 and evolves after that,

– remains relevant until project closure,

– may be updated as Project progresses, and

– presented in conjunction with Business Case/Proposal and JCNS.

956



©2020 ‐ 479 ‐

PES – Key Points

• What is it’s purpose?

– high‐level, tailored statement of strategy alternatives and recommended implementation strategy approach for realising capability need;

– supports IC decision making at Gates 0, 1 and 2;

– sets broad direction for the entire asset lifecycle:

• whole Project and Product;

• Total Costs of Ownership (TCO); and

• all FIC.

– …

957

PES Development

• What is it’s purpose?

– …

– document key Project factors, Risks and Drivers,

– proposes ‘information gathering’ activities (risk reduction and requirements setting activities),

– common reference for FIC providers and FIC integration.

– identifies necessary resources and schedule, and

– shapes subordinate plans including Integrated Project Management Plan (IPMP).

958



©2020 ‐ 480 ‐

PES: Considerations

• To develop the PES you need to address ALL factors that affect implementation including:

– Operational Need.

– Technical requirements, constraints.

– Commercial factors including industry structure, required competition (for VFM), company capabilities.

– Financial arrangements.

– Project Management possibilities and constraints:

• types of PM approaches,

• scheduling and resourcing needs, and

• resourcing.

– Transition into Service.

– Support/Sustainment factors.

959

PES: Considerations

• There is no template for your Project.

• You need to be able to propose and argue the best BALANCEacross these considerations to realise the capability need.

• PES document structure will change but the elements of a business argument essentially remain the same.

• The technical complexity of Defence projects requires that IPM, Project Sponsor must understand the technical factors.

960



©2020 ‐ 481 ‐

PES: Understand the Solution Context

For the ESM case study need to understand:

• Operational factors, for example:

– Operational imperative to deliver capability.

– Availability of platforms.

• Technical factors, for example:

– Solution will be based on a number of subsystems.

– Technical risks.

• Support factors, for example :

– Sovereign support capability.

– Opportunities for efficiencies.

• Commercial and Project Management factors, for example :

– Ability to leverage off other acquisition activities.

961

PES: ESM Context

• Electronic Support Measures system is based on integration of a number of sub‐systems.

• Installation on different classes of ships.

• Some of the sub‐systems are still under development.

• Sub‐systems developed by different vendors.

962

Sources: https://images.defence.gov.au/https://www.harris.com/solution/es‐3701s‐precision‐radar‐esm‐system



©2020 ‐ 482 ‐

Case Study: ESM Risks and Drivers

• Technical:

– Installation/Platform Integration complexity.

– Different parts of the system being developed to different timelines.

– Structural and other issues unknown (antenna mast).

– Combat system integration (software and hardware issues).

963


• Project Management:

– Upgrade cycle that was set by Anti‐Ship Missile Defence (ASMD) Program Risks identified included:

• Two programs (ASMD and ES) out of sync.

• Time pressures.

• Overseas design and production of significant part of system with local platform installation.

964



©2020 ‐ 483 ‐


• Commercial:

– Multiple interdependent vendors (Saab, Excelis, BAE, CEA).

– Need for continuity of vendor workforce through the different phases of the Defence approval lifecycle.

– Price and Schedule unclear.

• T&E:

– Opportunity: ANZAC (HMAS Perth) at Pacific Missile Range Facility (PMRF) for missile firings.

965

Case Study: Risk Reduction Activities

Targeted and funded risk reduction activities:

• Technical:

– Measurement of RF Environment:

• measurements:

– signal levels/ field density of the top‐side of the vessel (top of ANZAC mast)

– ‘live’ trials (PMRF) feasibility eg wrt other emitters

• understand the ship’s RF environment

– secure key data for design and placement of ES

–define filtering, blanking, shielding (Mexican hat)

– …

966

Sources: https://images.defence.gov.au/



©2020 ‐ 484 ‐



• Technical:

– …

– Ship Survey:

• Practical installation eg measuring cable runs.

• Installation of system elements below deck eg will the equipment racks fit in the spaces provided.

• Use of pre‐existing ‘services’ eg power.

• Will it fit in space and weight provisions (budget).

967

Excelis/Harris

Ref: Harris.com



• Technical:

– …

– Requirements validation workshops:

• Confirming feasibility of FPS requirements.

• Each vendor reviewed FPS.

• Discussed and resolved issues eg interfaces and integration of systems.

968



©2020 ‐ 485 ‐



• Technical:

– …

– Product Maturity / System development timeline.

• Product vendors continually upgrade their product lines:

–Saab upgrading 9LV combat system.

–Excelis upgrading ES system product.

• Vendors contracted to work together to understand implications of each development.

• System software and hardware upgrades analysed to ensure synchronized outcomes at the right time.

969

Combat System upgrade ES System product development

Radar systems evolution



• Technical:

– Combat System Integration workshops.

• Key vendors (Saab, Excelis, CEA) exchanged hardware and software models of their systems to develop an integrated solution.

970



©2020 ‐ 486 ‐



• Implementation:

971

…

Docking for ASMD upgrade

1QTR 2010 3QTR 2010 2QTR 2012 3QTR 2017

Delivery of ES Systems

…

eg

2011 2017



• Implementation:

– Factors:

• 10 systems: 8 platforms and two ashore.

• ES systems delivered one at a time.

• Installation on platform took a matter of weeks.

– Opportunities:

• Remove and install equipment.

• Fitted For But Not With (FFBNW).

• System Integration Lab.

• Continuity of Workforce.

972



©2020 ‐ 487 ‐



• Implementation:

973

• FFBNW: • Remove equipment• Run cables• Prepare installation spaces

…


1QTR 2010 3QTR 2010 2QTR 2012 3QTR 2017


…

eg

2011 2017



• Implementation:

974

Establish System Integration Lab (SIL)

…


1QTR 2010 3QTR 2010 2QTR 2012 3QTR 2017


…

eg

2011 2017



©2020 ‐ 488 ‐



• Implementation:

975

Establish System Integration Lab (SIL)• system integration and interface ‘proving’ prior to installation• system software development (test new releases of hardware and software) • operator and command team training

…


1QTR 2010 3QTR 2010 2QTR 2012 3QTR 2017


…

eg

2011 2017

Key Discussion Areas for PES

1. Project Summary: background including relationship between this proposal and other Projects or Products.

2. Project Factors: key risks, drivers and other factors that will shape the PES.

3. Approval Strategy: which Gates and Government approvals.

4. Asset Management Strategy: describes the Acquisition and Sustainment Strategy alternatives and rationale for the preferred Strategy.

5. Governance and Management Strategy: Single or Multi‐layer Governance, PMO (Program/Project) Structure

6. Commercial Strategy: Business Intelligence, Relationships, Strategic Agreements, Contractual Provisions.

976



©2020 ‐ 489 ‐

1. Project Summary

• Relationships with other Programs, Projects and Products.

• Life of Type: How long capability is expected to be in service

• High‐level resourcing and years of expenditure.

• Key schedule dates:

– Approval schedule re Gates

– Introduction into service timeline (IOC and FOC).

• Governance.

977

2. Project Factors

• Project Risk and Drivers profile determined using Smart Buyer Decision Making Framework and categories.

• PES includes potential actions in response to key risk or drivers.

978



©2020 ‐ 490 ‐

Examples: Factors that Shape Strategies

• Factors that shape strategies include but are not limited to:

– Risk and Driver profile (including extent of risk mitigation activities).

– Budget limitations: risk reduction, acquisition, support.

– Industry structure and competitive environment.

– Workforce: Defence and Industry.

– Time constraints: such as Planned Withdrawal Date (PWD) of current assets.

– Costs of tendering for industry and Commonwealth.

– Extant source selection outcomes for similar systems.

– Sovereign capability requirements.

979

3. Approvals Strategy

• Risk‐Based Approach to Defence Investment Approvals Framework considers four categories of risk:

– Finance.

– Requirements.

– Technical and Integration.

– Industrial and Strategic.

• No significant risks or decisions required from Government:

– can proceed directly from Gate 0 to Gate 2; and

– can be approved by Minister for Defence and Minister for Finance, rather than going to NSC.

980



©2020 ‐ 491 ‐

Case Study: Approvals Strategy

• Common ES system for RAN – AWD, ANZAC, LHD, Subs.

• Under the CLC, SEA 1448 Phase 4A could have potentially had approval at Gate 0 to seek next approval to acquire at Gate 2.

• Government approval documented in Project Direction.

981

4 ‐ 6. Asset, Gov and Mgt, Com Strategies

• Assessment of advantages and disadvantages for each of the strategy alternatives considered.

982



©2020 ‐ 492 ‐

Case Study: ESM Procurement method

• Procurement method:

– Options: open or limited tender.

– Method adopted:

• AWD Project – Open Tender (5 tender responses) .

• SEA 1448: Limited tender:

– leveraging AWD competition outcomes; and

–differences in requirements such as interfaces, combat system, racks.

983

Case Study: ESM Approach to Market

• Approach to Market:

– Options: RFT, RFP, RFQ, competitive evaluation, other iterative engagement process.

– Approach adopted:

• AWD used RFT.

• SEA 1448 limited RFT:

–previously used ITR, RFQ; and

–had to adjust based on related procurement.

984



©2020 ‐ 493 ‐

Case Study: ESM Project Delivery Model

• Project Delivery Model:

– Prime System Integrator (PSI): Commonwealth (MEW SPO):

• Commonwealth acquires systems.

• Systems provided as GFE to ship installer.

• Test in System Integration Lab before installation.

– System and Installation Contractors: CoA contracted:

• Prime contract with Excelis who in turn subcontracted, JEDS, SWRI, Ultra Electronics.

• SAAB and BAE for system design and installation.

• CSC for simulators for the LBTS.

• CEA for radar blanking interfaces.

985

Case Study: Contracting Template

• Contracting Template:

– ASDEFCON Complex:

• plus some elements (including DIDs) from Strategic Materiel.

– No FMS needed in this case – commercial buy OK.

986



©2020 ‐ 494 ‐

4. Sustainment Strategy

• Examples of Sustainment Strategies include but are not limited to:

– In‐house/Outsource Hybrid.

– Maximum Outsourced Support Solution.

• Areas of consideration for Sustainment Strategies include but are not limited to:

– cost and ability to support preparedness requirements;

– necessary engineering support;

– different levels of maintenance;

– supply support (including stores and distribution); and

– training support.

987

ESM Sustainment Approach

• Prime support ‘agent’: JEDS for all subsystem elements of the ES system.

• SAAB in‐service support contractor for combat system elements of the ES system.

• Integration facility to support system development.

• Training: Train the trainer—that is, vendors trained Navy to deliver operator and maintainer training.

• Sparing and Maintenance: Contractor Managed Commonwealth Asset (CMCA) (eg warehouse) responsibility assigned to JEDS for sparing, repair and helpdesk etc.

988



©2020 ‐ 495 ‐

6. Project Management Strategy

• Project Management as integrating discipline address all FIC:

– Delivery.

– Coordination.

– Integration

• Overview provides basis for IPMP and IMS.

• Key information gathering activities (including risk mitigation activities).

• Resources (including enabling budget for delivery groups).

• Governance bodies, roles and responsibilities.

• Schedule.

989

Case Study: ESM Project Management

Factors to be considered:

• System development and production vendors and locations.

• Access to platforms for integration.

• Multiple stakeholder engagement:

– several system vendors;

– several installation‐related vendors; and

– several FIC providers and enablers.

• IPMT composition eg structural, RF, SW integration expertise.

• Significant Risk Reduction activities.

990



©2020 ‐ 496 ‐

Case Study: ESM Project Management

• Navy to:

– provide x platforms on an agreed timeline;

– provide y crews for training; and

– other sea assets for test program eg other vessels to test ES system performance.

• DSTG to:

– provide advice on the maturity of the technology by a certain date; and

– help develop the test program and analyse the results.

• Airforce to provide test assets for sea trials.

• Joint Organisations (JEWOSU) to provide test libraries and operational libraries.

991

Case Study: Project Management992

Subsystem 1

Subsystem 2

Subsystem 3Integration

T&E

ES

M S

yste

m

Platform 1

Platform 2

Platform 3

Platform Preparation, Installation and Integration

System Development and Production

Platform 10

…

Ship Set 2

Ship Set 3

Ship Set 10

…

Support System

Other FIC FIC

/ SS

CC



©2020 ‐ 497 ‐

Integrated Project Management Plan (IPMP)

993

IPMP – Key Points

• Describes in more detail how PES will be implemented

• Demonstrates that:

– strategy can be implemented within budget, schedule, quality and risk; and

– risks are manageable and acceptable.

• All FIC activities, deliverables and dependencies.

• Common reference for stakeholders (including IPT):

– Sponsor.

– FIC Providers.

– CASG Line Management.

– Project Office staff.

994

Source: IPMP Guide



©2020 ‐ 498 ‐

IPMP – Key Points

• Basis for subordinate plans such as Systems Engineering Management Plan (SEMP).

• Basis for each FIC provider to report progress.

• Activities, roles and responsibilities, resources needed to deliver strategy.

• Includes the Integrated Master Schedule (IMS):

– major management control/decision points (i.e. stages);

– major products and outcomes for each stage;

– activities and resources required; and

– sequencing and dependencies.

995

Source: IPMP Guide

IPMP – Subordinate Plans

Subordinate plans include:

• Project Management Planning Guidance.

• Engineering Planning Guidance (for Systems Engineering Management Plan (SEMP).

• Sustainment Planning Guidance.

• Commercial Planning Guidance.

• Acceptance into Operational Service Planning Guidance.

• Project Office Management.

996

Source: IPMP Guide



©2020 ‐ 499 ‐

ESM example: Engineering Planning

• Systems Engineering Plan:

– Requirements: different requirements across different classes needed to be defined and reconciled.

– Analysis planning: technical issues across different engineering disciplines (such as physicalmounting of antenna on mast, radio frequency (RF) interference with other emitters).

– Integration planning:

• ES system integration.

• Shipboard integration (such as power, combat system).

• Staged to fit platform availability .

997

IPMP: ESM Roles and Responsibilities

• Navy:

– Provide x platforms on an agreed timeline.

– Provide y crews for training.

– Other sea assets for test program (such as other vessels to test ES system performance).

• DSTG:

– Provide advice on technology by a certain date.

– Help develop the test program and analyse the results

• Airforce to provide test assets for sea trials.

• Joint Organisations (JEWOSU): provide test libraries and operational libraries.

• Regulators including seaworthiness, training.

998

Source: IPMP Guide



©2020 ‐ 500 ‐

Annex A: PM Planning Guidance

A.1 Project GovernanceA.2 Project AssuranceA.3 Stage / Detailed PlanningA.4 Project Work Breakdown StructureA.5 Integrated Master ScheduleA.6 Integrated Project TeamA.7 Battle RhythmA.8 Risk and Contingency ManagementA.9 Issue ManagementA.10 Stakeholder ManagementA.11 Transition to SustainmentA.12 Acceptance into Operational Service A.13 Project Closure

999

Source: IPMP Guide

Capability Definition Documents (CDD)

1000



©2020 ‐ 501 ‐


DWP

FOE FJOC

AMS

AJOC

What and Why How

PGPA Act

CPRs

Force Design

CPN

JCN

IIP

DIP

DPPM



PESJCNS

Smart Buyer

OCD

FPS

IPMPProjectWBS

IMS



DPG

JCFConcepts

Strategic Guidance


Portfolio

Program

Project

Capability Definition Documents (CDD)

• The Operational Concept Document (OCD) is the capstone document that captures the scope of, and intent for, the proposed Capability.

• The Function and Performance Specification (FPS) specifies the formal requirements for the Materiel System and provides the basis for design and qualification testing of the system.

• The T&E Master Plan (TEMP) considers T&E requirements within the life‐cycle management of the Capability System. The TEMP is elaborated further by the contractor in the V&V Plan.

1002



©2020 ‐ 502 ‐

CLC Needs and Requirements Hierarchy1003


Program 1


Program Strategy


Project 1

OCD

FPS

TEMP

IPMP

JCNS 1


IPMP

JCNS 2

IPMP

JCNS 3

Project 2 Product 3

OCD

FPS

TEMP

OCD

FPS

TEMP

Program Level Supports Sufficiency Goal 1004


Program 1


Program Strategy


Project 1

OCD

FPS

TEMP

IPMP

Requirements development practices using Program-level needs and requirements information supports FPR and CLC expectations of sufficiency through use of common references and re-use.

JCNS 1


IPMP

JCNS 2

IPMP

JCNS 3

Project 2 Product 3

OCD

FPS

TEMP

OCD

FPS

TEMP



©2020 ‐ 503 ‐

Needs and Requirements Re‐use1005

FPS

TEMP

OCD

Needs and Requirements Re-use


Sections 1-4

Sections 5-6

Re-use

Re-use

Re-use

Needs and Requirements developed specifically for Project

Transformation of Operational Needs1006

Transformationdocumented in OCD

Specification documented in FPSSpecifications

Ope

ratio

nal

Nee

ds

Trans

form

atio

n

Warfighter Domain

Well Understood

by Warfighters

ImplementationDomain

Well Understood by Acquirers & Developers

OCDUnderstood by

all partiesT&E expectations documented in TCDTEMP



©2020 ‐ 504 ‐

OCD, FPS, TEMP Relationship1007

1 2 n

0

...

1.1 1.2 1.n...

1.1.1 1.1.2 1.1.n...

n.1 n.2 n.n...

n.n.1 n.n.2 n.n.n...


Level 1

Level 2

Level 3

CI

COI

MOE

Level 4 MOP

Level n TPM

….

….

Mission

OCD

FPS

DraftTEMP

Prepared by Stakeholders (CM)


1 2 n

0

...

1.1 1.2 1.n...

1.1.1 1.1.2 1.1.n...

n.1 n.2 n.n...

n.n.1 n.n.2 n.n.n...


Level 1

Level 2

Level 3

CI

COI

MOE

Level 4 MOP

Level n TPM

….

….

Mission

OCD

FPS

Augmented/prepared by Delivery Group (CASG, CIOG)

(+)

TEMP

DraftTEMP



©2020 ‐ 505 ‐


1 2 n

0

...

1.1 1.2 1.n...

1.1.1 1.1.2 1.1.n...

n.1 n.2 n.n...

n.n.1 n.n.2 n.n.n...


Level 1

Level 2

Level 3

CI

COI

MOE

Level 4 MOP

Level n TPM

….

….

Mission

OCD

FPS

SSS

SS

TEMP

V&VPlan

Prepared by Contractor/Sub-contractors

DraftTEMP

OCD

• Communicates the solution‐independent needs of the warfighter to all stakeholders, including acquirers and developers, in a language that all parties can understand.

• Describes capability from an operational perspective.

• Facilitates an understanding of the overall system goals for the materiel system.

• Details missions and scenarios associated with operations and support of the Materiel System.

• Provides a reference for determining ‘fitness for purpose’.

• Provides a justifiable basis for the formal requirements for the Materiel System, as captured in the FPS.

• Details the FIC needed to realise the Capability System in operational service.

1010



©2020 ‐ 506 ‐

OCD Template1011

0. EXECUTIVE SUMMARY

0.1 Identification and Justification

0.2 Key Boundary Issues

0.3 Project Schedule

0.4 Capability System Mission and Critical Operational Issues

0.5 Existing Capability Description

0.6 Materiel System Solution‐class

0.7 Fundamental Inputs to Capability

1. SCOPE

1.1 Capability Identification

1.2 Document Purpose & Intended Audience

1.3 Justification for Capability

1.4 System Boundary and Acquisition Assumptions

1.5 Key Timeframes for Capability

2. DEFINITIONS AND REFERENCED DOCUMENTS

2.1 Referenced Documents

2.2 Glossary of Terms

3. SOLUTION‐INDEPENDENT CAPABILITY NEEDS

3.1 Mission Overview

3.2 Operational Policies and Doctrine

3.3 Capability System End‐user classes

3.4 Summary of Operational Scenarios

3.4.1 Common Scenario Attributes

3.4.2 Scenario 1 ‐ Scenario Title

3.4.2.1 Summary of Situation

3.4.2.2 Summary of Military Response

3.4.2.3 Summary of Operational Needs

3.4.3 Scenario 2 ‐ Scenario Title

3.4.4 Scenario N ‐ Scenario Title

3.5 Summary of Consolidated Operational Needs

3.6 Solution‐class‐Independent Constraints

OCD Template1012

4. EXISTING SYSTEM

4.1 Existing System Overview

4.2 Existing System Operational Capability Comparison

4.3 Existing System Internal Shortcomings

4.4 Existing System Planned or Active Upgrades

4.5 Existing System Internal User classes

4.6 Existing System Internal Functionality

4.7 Summary of Existing System Internal Scenarios

5. SYSTEM SOLUTION‐CLASS DESCRIPTION

5.1 Materiel System Description

5.2 Mission System Architecture

5.3 Materiel System Interfaces

5.4 Materiel System Internal User classes

5.5 Materiel System Functionality and Performance

5.6 Materiel System Support Concepts and Requirements

5.7 Materiel System Constraints

5.8 Materiel System Evolution and Technology Forecast

5.9 Summary of Materiel System Internal Scenarios

5.9.1 Internal Scenario 1 ‐ ‘A Typical Day’s Operation’

5.9.1.1 Summary of Situation

5.9.1.2 Summary of Process Flows and Interactions

5.9.1.3 Summary of Materiel System Requirements

5.9.2 Internal Scenario 2 ‐ Scenario Title

5.9.3 Internal Scenario N ‐ Scenario Title



©2020 ‐ 507 ‐

OCD Template1013

6. CONSOLIDATED FUNDAMENTAL INPUTS TO CAPABILITY (FIC) REQUIREMENTS

6.1 FIC Related Guidance

6.2 Major Systems FIC Element Requirements

6.3 Facilities and Training Areas FIC Element Requirements

6.4 Support FIC Element Requirements

6.5 Supplies FIC Element Requirements

6.6 Organisation FIC Element Requirements

6.7 Command and Management FIC Element Requirements

6.8 Personnel FIC Element Requirements

6.9 Collective Training FIC Element Requirements

6.10 Industry FIC Elements Requirements

6.11 FIC Impacts on Supporting Capabilities

6.12 Summary of Overall FIC Responsibilities

6.13 FIC Development Forecast

A. ANNEX A ‐ EXTERNAL SCENARIOS

A.1 Capability System Operational Scenarios

A.1.1 Common Scenario Attributes

A.1.2 Scenario 1 ‐ Scenario Title

A.1.2.1 Scenario 1 ‐ Situation Requiring ADF Action

A.1.2.2 Scenario 1 ‐Military Response

A.1.2.3 Scenario 1 ‐ Operational Needs

A.1.3 Operational Scenario 2 ‐ Scenario Title

A.1.4 Operational Scenario N ‐ Scenario Title

A.2 Consolidated Operational Needs

OCD Template1014

B. ANNEX B ‐ EXISTING SYSTEM INTERNAL SCENARIOS

B.1 Internal Scenario 1 ‐ ‘A Typical Day’s Operation’

B.1.1 Internal Scenario 1 ‐ Situation

B.1.2 Internal Scenario 1 ‐ Details of Process Flows and Interactions

B.1.3 Internal Scenario 1 ‐ Identified Shortcomings

B.2 Internal Scenario 2 ‐ Scenario Title

B.3 Internal Scenario N ‐ Scenario Title

C. ANNEX C ‐MATERIEL SYSTEM INTERNAL SCENARIOS

C.1 Internal Scenario 1 ‐ ‘A Typical Day’s Operation’

C.1.1 Internal Scenario 1 ‐ Situation

C.1.2 Internal Scenario 1 ‐ Details of Process Flows and Interactions

C.1.3 Internal Scenario 1 ‐Materiel System Requirements

C.2 Internal Scenario 2 ‐ Scenario Title

C.3 Internal Scenario N ‐ Scenario Title

C.4 Consolidated Materiel System Functionality and Performance



©2020 ‐ 508 ‐

FPS

• Specifies formal requirements for the Materiel System.

• Provides the basis for design and qualification testing of the system.

• Provides the vehicle for the capture of formal, verifiable and unambiguous requirements, ‘distilled’ from the OCD.

• Is intentionally written using formal language, with all requirements in the FPS traceable to needs in the OCD.

• Addresses the total Materiel System, but will later be developed into a Mission System specification and a Support System specification, usually by a prime contractor or prime system integrator.

• FPS requirements may also need to be decomposed and/or allocated for the purposes of individual acquisition contracts.

1015

FPS Template1016

Section 1 – Scope

1.1 – Identification

1.2 – System Overview

1.3 – Document Overview

Section 2 – Applicable Documents

Section 3 – Requirements

3.1 – Missions

3.2 – System Boundaries and Context

3.3 – Required States and Modes

3.4 – System Capability Requirements

3.5 – Availability

3.6 – Reliability

3.7 – Maintainability

3.8 – Deployability

3.9 – Transportability

3.10 – Environmental Conditions

3.11 – Electromagnetic Radiation

3.12 – Architecture, Growth and Expansion

3.13 – Safety

3.14 – Environmental Impact Requirements

3.15 – Useability and Human Factors

3.16 – Security and Privacy

3.17 – Adaptation Requirements

3.18 – Design and ImplementationConstraints

3.19 – System Interface Requirements

Section 4 – Precedence and Criticality of Requirements

Section 5 – Verification

Section 6 – Requirements Traceability

Section 7 – Notes



©2020 ‐ 509 ‐

TEMP Template1017

SECTION I - SYSTEM DESCRIPTION 1.1 Mission Description 1.1.1 Operational Need 1.1.2 Mission(s) to be Accomplished

1.1.3 Specified Environment 1.2 System Description 1.2.1 Key Functions 1.2.2 System Architecture and Interfaces

1.2.3 Unique System Characteristics 1.3 Critical Operational Issues (COI) 1.4 System Threat Assessment 1.5 Required Operational Characteristics

1.5.1 Key Operational Effectiveness Characteristics 1.5.2 Key Suitability Characteristics 1.5.3 Thresholds

1.6 Key Technical Characteristics

SECTION II - PROGRAM SUMMARY 2.1 Project Phases and V&V Phases 2.2 Stakeholder Responsibilities with respect to V&V 2.3 Integrated Schedule 2.4 Funding Aspects of the V&V process

SECTION III – DT&E OUTLINE 3.1 Critical DT&E Issues 3.2 DT&E to Date 3.3 Future DT&E

3.3.1 DT&E Phases and Objectives 3.3.2 DT&E Activities and Scope of Testing 3.3.3 Critical DT&E Resource Requirements 3.3.4 Constraints and Limitations associated with D&TE

SECTION IV – VALIDATION OUTLINE 4.1 Critical Validation Issues 4.2 Validation to Date 4.3 Future Validation

4.3.1 Validation Phases and Objectives 4.3.2 Validation Activities and Scope of Testing 4.3.3 Critical Validation Resource Requirements 4.3.4 Constraints and Limitations associated with Validation

SECTION V – ACCEPTANCE V&V (AV&V) OUTLINE 5.1 Critical AV&V Issues 5.2 AV&V to Date 5.3 Future AV&V

5.3.1 AV&V Phases and Objectives 5.3.2 AV&V Activities and Scope of Testing 5.3.3 Critical AV&V Resource Requirements 5.3.4 Constraints and Limitations associated with AV&V

SECTION VI - SAFETY 6.1 Assessment of Safety 6.2 Critical Safety Issues 6.3 Safety Management for V&V activities

SECTION VII - SPECIALTY TEST PROGRAMS 7.1 Specialty Test Program Requirements 7.2 Specialty Test Program - Critical Issues

SECTION VIII – SUPPORTABILITY TEST PLAN

SECTION IX – TRANSITION PLAN

SECTION X – SPECIAL RESOURCE SUMMARY 10.1 Schedule of V&V activities with special resource requirements 10.2 Special Resource Requirements for V&V activities

SECTION XI – HUMAN RESOURCE LIMITATIONS

CDD Guide v2.2



©2020 ‐ 510 ‐

Develop OCD, FPS, and TEMP1019

CDD Guide v2.0 OCD Section

(3)(1 & 3) (4) (5/6)

Develop OCD, FPS, and TEMP1020

What dowe need?

What dowe have?

What canwe do?

Is everythingstill OK?

1 to 3OCD Section 4 5/6



©2020 ‐ 511 ‐

Define CS Context and Background1021

1.1 (1.1)

Identify Capability

1.2 (1.2)

Identify Stakeholders

1.3 (1.3)

Identify Capability rationale

1.4 (1.4)

Identify Capability System

boundaries (solution-class-independent)

1.5 (1.5)

Identify key timeframes for

Capability System

1.6 (3.1)

Identify primary and secondary

mission objectives

1.7 (3.2)

Identify operational policies and

doctrine

1.8 (2.1/2.2)

Establish and maintain Glossary and list of Referenced Documents

Define Capability System Needs1022

2.1 (3.3)

Identify all End-user classes

2.2 (3.4)

Select minimal set of

operational scenarios

2.3 (3.4)

Describe future situation requiring ADF

action

2.4 (3.4)

Describe military

response / CONOPS

2.5 (Annex A)

Capture and model

business / operational

processes of End-user

2.6 (3.4)

Extract operational

needs for each business

process step

2.7 (3.5)

Consolidate operational

needs

2.8 (3.6)

Define Capability System

constraints (solution-class-independent)

2.9 (3.5/3.6)

Prioritise Capability

System needs (solution-class-independent)

for each Operational Scenario and End-user class



©2020 ‐ 512 ‐

Describe Existing System Capability1023

3.1 (4.1)

Provide overview of

Existing System

3.2 (4.1)

Identify Existing

System End-user classes

3.3 (4.2/1.3)

Identify capability gap

3.4 (4.3)

Identify Existing System

shortcomings

3.5 (4.4)

Identify planned

upgrades

3.6 (4.5)

Identify Existing System

Internal User classes

3.7 (4.6)

Identify Existing System internal

functionality

3.8 (4.7)

Describe Existing System internal

scenarios

internal scenarios not required

Define Materiel System Requirements1024



©2020 ‐ 513 ‐

Selected Important Activities

1.2 Identify Stakeholders1026

1.1 (1.1)

Identify Capability

1.2 (1.2)


1.3 (1.3)


1.4 (1.4)



1.5 (1.5)


Capability System

1.6 (3.1)


mission objectives

1.7 (3.2)


doctrine

1.8 (2.1/2.2)




©2020 ‐ 514 ‐


• Strictly speaking a stakeholder could be defined as someone who has a stake in the project—that is, someone who is affected by the system in some way, or can affect the system in some way.

• More usefully, a stakeholder is defined as someone (or some organisation) who has a right to influence the outcome of the system, rather than someone who is simply affected by the system.

1027


• Even our better definition does not assist us to identify our stakeholders automatically. If a stakeholder has a right to influence the requirements, we need to identify what or who gives them that right. Even then, we need to examine candidate stakeholders more carefully. For example:

– Do all stakeholders have equal rights?

– If not, who decides which have higher priority?

– What do we do if stakeholders do not agree?

– If a group of people is considered to be a stakeholder, do they all have a voice, or is a spokesperson to be elected/nominated?

– How do we discount requirements collected from a stakeholder who is clearly confused and whose contributions are unenlightening?

1028



©2020 ‐ 515 ‐

1.4 Identify CS Boundaries1029

1.1 (1.1)

Identify Capability

1.2 (1.2)


1.3 (1.3)


1.4 (1.4)



1.5 (1.5)


Capability System

1.6 (3.1)


mission objectives

1.7 (3.2)


doctrine

1.8 (2.1/2.2)


Context Diagrams

• To assist with bounding the system, a tool called a context diagrammay be used to illustrate the related systems, relevant regulatory environments, stakeholders, external systems, interfaces, and so on.

• Different systems may of course have significantly different context diagrams.

1030



©2020 ‐ 516 ‐

This is NOT a Context Diagram1031

SystemUnder

Consideration

How does this system fit in with the rest of the world?

Context Diagram1032

Power entrypanel

Powerpoint

Power DistributionSubsystem

HouseSystem

AlarmSystem

PSTN

Resident

Monitoring Agent Monitoringsystem

Power Grid

Intruder

Police Neighbours

Environment



©2020 ‐ 517 ‐

Consider External Interfaces

• Interfaces with existing or future external systems must also be defined as these will place considerable requirements on the system under development.

• While these external systems are not directly related to the system, the success of the fielded system is often determined by its ability to interface to its external environment.

• For example, while it is possible to build a perfectly functional aircraft without consideration of air traffic control regulations, the aircraft would be useless because it would not be allowed to operate.

1033


• The definition of an interface requires considerably more detail than simply identifying and naming the interface. Broadly there are three main steps in interface definition:– Interface Description. The interface is given a name, short title and identifier. The nature of the interface is described in terms of who, what, when, where, why, how.

– Interface Impact Analysis. The interface is analysed in terms of its impact on the system. In particular, any constraints imposed by the system are identified. A risk analysis is conducted to determine the impact of the interface on the operation and design of the system.

– Interface Control Analysis. Each external interface must be analysed to determine the extent to which it can be controlled so that designers and operators of the system are not at the mercy of its external interfaces.

1034



©2020 ‐ 518 ‐

External Interfaces1035

Power entrypanel

Powerpoint

Power DistributionSubsystem

HouseSystem

AlarmSystem

PSTN

Resident

Monitoring Agent Monitoringsystem

Power Grid

Intruder

Police Neighbours

Environment

E01

E02

E03E04

E05/6

E07

E08

E09

E10


• Once it has been defined, each interface has to be documented and managed. Interface management is very important because systems (and the projects that deliver them, for that matter) often live or die by their interfaces. This is even more evident in modern systems where the sheer number of interfaces and their complexity are a significant source of risk in system development.

• The definition of a system’s external interfaces assists in defining the system’s scope—interface management is therefore an important part of the scope management activities undertaken by the project manager. It is highly likely that the scope of a system would be affected should there be a change to any aspect of a system’s external interfaces throughout its development.

1036



©2020 ‐ 519 ‐

1.6 Identify Mission Objectives1037

1.1 (1.1)

Identify Capability

1.2 (1.2)


1.3 (1.3)


1.4 (1.4)



1.5 (1.5)


Capability System

1.6 (3.1)


mission objectives

1.7 (3.2)


doctrine

1.8 (2.1/2.2)


Identify Mission (and Operational Needs)

• Because the user has most probably stated the mission for the system in a fairly general way, every project should begin with a concise statement of the mission, elaborated by statements of the system‐level needs.

• The mission statement is then expanded and qualified by short declarative statements of the system operational needs (best expressed in a functional hierarchy).

• Level 1 Operational Needs are normally relatively broad, each of which spawns a number of more‐specific Level 2 Operational Needs, each of which spawns a number of more‐specific Level 3 Operational Needs, and so on.

• Level 3 or 4 is sufficient for the OCD—lower level needs spawn system requirements in the FPS (and subsequently in the SS and then the SSS).

1038



©2020 ‐ 520 ‐

Secondary Missions

• Secondary mission objectives can be considered on the assumption that the Capability System will eventually be in place. These secondary objectives take advantage of the existence of this Capability System, given that, without it, they would have to be satisfied in another way.

• For example, an air‐to‐air refueller platform may have a secondary mission objective as a communications relay. If the refuelling role did not exist, the communications‐relay capability may be achieved by some other means, such as a suitably equipped unmanned aerial vehicle.

1039

1.7 Identify Policies and Doctrine1040

1.1 (1.1)

Identify Capability

1.2 (1.2)


1.3 (1.3)


1.4 (1.4)



1.5 (1.5)


Capability System

1.6 (3.1)


mission objectives

1.7 (3.2)


doctrine

1.8 (2.1/2.2)




©2020 ‐ 521 ‐

1.7 Identify Policies and Doctrine

• Identify operational and policies such as:

– international treaties;

– agreements regarding operation in international waters or airspace;

– compliance with environmental, heritage, and land rights legislation;

– compliance with spectrum management regulations;

– doctrine relating to the primary and secondary missions; and

– interoperability requirements, which may be considered here, but are usually considered as part of the derivation of the operational needs and solution‐class requirements.

• We discuss these in more detail later as enterprise constraints.

1041

18 Glossary and Referenced Documents1042

1.1 (1.1)

Identify Capability

1.2 (1.2)


1.3 (1.3)


1.4 (1.4)



1.5 (1.5)


Capability System

1.6 (3.1)


mission objectives

1.7 (3.2)


doctrine

1.8 (2.1/2.2)




©2020 ‐ 522 ‐

1.8 Glossary and Referenced Documents

• The aim of this step is to initially create and then maintain a glossary of defined terms and acronyms, and a list of referenced documents. The set of terms used in each of the OCD, FPS and TEMP may not always overlap, but wherever common terms and documents are referenced, the terminology and references should be the same.

• A project‐wide integrated dictionary should be established, consisting of both a glossary of terms and acronyms and a list of referenced documents. A filtered set of this dictionary should be incorporated into the OCD and other CDD, as applicable.

1043

Define Capability System Needs1044

2.1 (3.3)


2.2 (3.4)



2.3 (3.4)


action

2.4 (3.4)

Describe military

response / CONOPS

2.5 (Annex A)

Capture and model



2.6 (3.4)

Extract operational


process step

2.7 (3.5)


needs

2.8 (3.6)



2.9 (3.5/3.6)






©2020 ‐ 523 ‐

2.1 Identify all End‐user Classes1045

2.1 (3.3)


2.2 (3.4)



2.3 (3.4)


action

2.4 (3.4)

Describe military

response / CONOPS

2.5 (Annex A)

Capture and model



2.6 (3.4)

Extract operational


process step

2.7 (3.5)


needs

2.8 (3.6)



2.9 (3.5/3.6)




2.1 Identify all End‐user Classes

• The aim of this step is to identify all the End‐user classes (End‐users that has a common set of needs) in conjunction with establishing the scenarios for the Capability System.

• This step is typically iterative because the identification of an End‐user class may require additional operational scenarios (next step) in which they appear, and vice‐versa.

• The set of End‐user classes should identify the people who are external to the 'black box' Capability System and who are the End‐users of the system products or capabilities.

• The roles and needs of people inside the Capability System (Internal Users), such as operators, maintainers and trainers, is addressed later (in Section 5.4), during preparation of the internal, solution‐class‐dependent description.

1046



©2020 ‐ 524 ‐

2.2 Select Operational Scenarios1047

2.1 (3.3)


2.2 (3.4)



2.3 (3.4)


action

2.4 (3.4)

Describe military

response / CONOPS

2.5 (Annex A)

Capture and model



2.6 (3.4)

Extract operational


process step

2.7 (3.5)


needs

2.8 (3.6)



2.9 (3.5/3.6)




2.2 Select Operational Scenarios

• Once the mission and high‐level operational needs have been articulated, the top‐down process is continued through an examination of the range of operational scenarios that the stakeholders propose for the system.

• The examination begins with a description of the general operational environment for the system to identify all of the environmental factors that may have an effect on the operation of the system.

• Specific operational scenarios are then described in users’ language to depict the full range of circumstances under which the system is required to operate.

• It is not necessary to describe every possible scenario, but all types of operation must be represented. Scenarios also need to represent all stakeholder perspectives.

1048



©2020 ‐ 525 ‐


• These scenarios, or use cases, provide valuable guidance to the system designers and form the basis of major events in the Acquisition Phase such as acceptance testing of the system as it is introduced into service.

• Despite any more detailed technical verification and validation procedures, the system’s fitness for purpose is fundamentally related to its ability to perform in accordance with the operational scenarios defined at this stage.

• In many cases it is also useful to define the various modes of operation for the system products under development. Designers need to understand if the system is to exist in a number of different modes even if it is as simple as the difference between the fully operational mode or the training mode.

1049


• Complex systems may have their requirements stated in a number of modes. For example, a modern fighter aircraft may have modes defined for air‐to‐air combat, ground attack, reconnaissance, naval operations, non‐tactical flights, and so on. Each mode must be associated with the particular conditions (mission, operational, environmental, configurational, and so on) that define it.

• In our aircraft example, a number of modes may be defined for international and domestic operation including taxi, take‐off, cruise, approach, landing, turn‐around, and so on. Modes may also be defined for maintenance and for administrative movement of the aircraft.

1050



©2020 ‐ 526 ‐


• Users tend to think in terms of the systems operation to suit their purposes—care has to be taken to define exception conditions.

• For example, a pilot of a combat aircraft will naturally describe a number of modes and states during which adversary aircraft are engaged and destroyed, but will need some prompting to describe what happens when the pilot’s aircraft is hit and the pilot must eject.

• At every stage in each scenario, we must ask the question “What could go wrong here?”

1051

Define Capability System Constraints1052

2.1 (3.3)


2.2 (3.4)



2.3 (3.4)


action

2.4 (3.4)

Describe military

response / CONOPS

2.5 (Annex A)

Capture and model



2.6 (3.4)

Extract operational


process step

2.7 (3.5)


needs

2.8 (3.6)



2.9 (3.5/3.6)






©2020 ‐ 527 ‐

Project and Enterprise Constraints

• Before focusing on the detail of the desired system, it is essential to identify the project and enterprise constraints that are relevant to the system and its acquisition. This analysis provides essential information about the development environment for the system and begins the top‐down approach to system development.

• Enterprise constraints include any organizational policies, procedures, standards or guidelines that guide system development and procurement. These constraints can include partnering relationships with other companies, contracting policies and so on.

1053

Project and Enterprise Constraints

• Project constraints include the resource allocations to the project as well as any externally imposed deliverables and acquisition timeframes.

• Many companies have enterprise‐wide standards for processes such as quality assurance and systems engineering and these methodologies guide the manner in which projects can operate.

• Additionally, the enterprise may require the project to report progress in a particular way or to implement particular metrics, tools and documentation procedures.

1054



©2020 ‐ 528 ‐

Identify External Constraints

• In addition to enterprise‐imposed constraints, there are wider external constraints on system development that arise from the requirement for conformance to national and international laws and regulations, compliance with industry‐wide standards, as well as ethical and legal considerations.

• Other external constraints include the requirement for interoperability and the capabilities required for interfacing to other systems.

• Again, an important aspect of top‐down design is to understand these constraints before considering lower‐level system requirements.

1055


• External constraints could include:– Business environment. The system will no doubt be affected by changes in the broader business and economic environment, particularly those related to cost, pricing, availability, and licensing.

– Conformance to laws and regulations. Conformance to laws is binding within a national or international legal construct; regulations are normally provided by governing bodies within the application domain of the development.

– Compliance with standards. Industry standards provide similar constraints to laws and regulations, except that compliance with any particular standard may be at the discretion of the developer, unless the standard is mandated by the enterprise or by the contract.

– …

1056



©2020 ‐ 529 ‐


• External constraints could include:

– …

– Ethical considerations and social responsibility. System developers have a moral and ethical responsibility to the owners and users of the system, as well as to the community.

– Interoperability and or interfacing requirements. Since it is rare that a system would stand alone, interoperability and interface considerations must be taken into account during development.

– Operating environment. The system will have to exist within an operational environment that will provide constraints in terms of temperature, humidity, and radiation as well as robustness to shock.

1057

Identify Design Constraints

• Design constraints include those factors that directly affect the way in which the system design can be conducted. Of course, a number of enterprise, project and external constraints (such as budgets, regulations, and standards) will flow down and be inherited as design constraints.

• Typical design constraints include the state‐of‐the‐art of relevant technologies, the skill sets of available engineers and tradespersons, as well as extant methodologies and tools to assist in the design, development, construction, and production of the system.

• Additionally, bounds such as all‐up weight may be a design constraint for an aircraft system if it is to land on certain classes of airfield.

1058



©2020 ‐ 530 ‐

Overview of CLC Artefact Development

• Artefacts are developed over the CLC to perform a number of functions:

– Recording evidence and decisions.

– Supports considered analysis and records rationale.

– Allows demonstration of traceability.

– Supporting risk reduction.

– Establishes authority and certainty.

– Provides continuity of position, expectations, and agreed outcomes.

– Bounds the scope and enabling parameters.

1059

Submissions

and their passage through Defence and Government



©2020 ‐ 531 ‐

Core Objectives of the CLC 1061




Successful Implementation

Approvals to progress Proposal








This is not the ‘end-game’




©2020 ‐ 532 ‐







This is the ‘end-game’








This is the ‘end-game’

The Project and Product need to be set up for success




©2020 ‐ 533 ‐







Capability Manager Accountable






Disposal

Gate 0 Gate 2Gate 1

ApprovalsIC

Approval

IC, Government

Approval




Contestability

Activities

Smart Buyer

CM Needs




Smart Buyer


PFPS*

POCD*

PES 1JCNSJCN

FPS*

OCD*PES 2

IPMP

PES 3Reduced Risk

Sub

mis

sion

App

rova

l &

Dire

ctio

n

Sub

mis

sion

Project Activities

IMS

Sub

mis

sion

Product Activities

Contract Docs

IPMP

PDA/MAA

Contract Docs

IPdMP




Project Management


App

rova

l &

Dire

ctio

n

App

rova

l &

Dire

ctio

n

Contract Management

Off

er

Acc

epta

nce

App

rova

l




©2020 ‐ 534 ‐





Disposal

Gate 0 Gate 2Gate 1

ApprovalsIC

Approval

IC, Government

Approval




Contestability

Activities

Smart Buyer

CM Needs




Smart Buyer


PFPS*

POCD*

PES 1JCNSJCN

FPS*

OCD*PES 2

IPMP

PES 3Reduced Risk

Sub

mis

sion

App

rova

l &

Dire

ctio

n

Sub

mis

sion

Project Activities

IMS

Sub

mis

sion

Product Activities

Contract Docs

IPMP

PDA/MAA

Contract Docs

IPdMP




Project Management


App

rova

l &

Dire

ctio

n

App

rova

l &

Dire

ctio

n


ffer

Acc

epta

nce

App

rova

l

Business Case

Business Case

Business Case

Defence CLC Business Case

1068



©2020 ‐ 535 ‐

Business Case Development

• Business Cases incorporate different documents depending on the purpose.

• Intent remains the same – Business Argument.

• There are different ‘rules’ at each Gate – you need to find the latest.

1069

Business Case Framework1070

Reference throughout BBC sections is: https://treasury.govt.nz/information‐and‐services/state‐sector‐leadership/investment‐management/better‐business‐cases‐bbc

based on

NZ Treasury Better Business Case Guide



©2020 ‐ 536 ‐

Better Business Case (BBC) Guide: CLC

• In 2016 the BBC approach was adapted to Defence CLC.

• Still on VCDF website.

• Based on BBC Five Case Model mapped to JCNS and PES and covering submission documents.

• BBC framework by NZ government (and UK Gov)

• Systematic method for programs or projects.

• Internationally recognised best practice standard—that is, the five‐case model.

1071

1072

IC agrees to resourcing, timeframes and outcomes to reach next Gate

IC agrees to proposed Project Execution Strategy (PES)

IC agrees options based upon a broad consideration of strategic and economic

Informed By Joint Capability Needs Statement Informed by PES

Strategic Case Economic Case Financial, Commercial and Management Cases

Proposal of resources needed, timeframes, and outcomes required to reach the next Gate

Proposal of detailed risk-based tailored Project Execution Strategy.

Argument on the method, considerations, and rationale used to select the options if needed.

Description of strategic risks, issues, and constraints relevant to the proposal

Argument that proposal aligns with strategic (capability and business) intentand is consistent with priorities

Joint Capability Needs

Statement (JCNS)

IC agrees that overall proposal meets Defence constraints for strategic intent and portfolio priorities

IC notes risks, issues and constraints for the Proposal

• High level statement of an identified and bounded capability need and available option sets linked to specific strategic guidance

• Contribution to joint capability with FIC integration issues highlighted and interdependencies defined

Business

Case

Components

Better

Business Case

Structure

• A short statement of what decisions are being sought from VCDF.

• If Project already in IIP then need is reconfirmed if there has been change to strategic landscape, otherwise just restated.

• Capability Need and the Investment Proposal is justified within context of Defence strategic landscape and identified Portfolio and Program priorities.

• Scope of Capability Need is agreed in terms of capability objectives, outcomes, and requirements.

• Proposal fits in with other relevant strategic ‘business’ intentions eg ICT Roadmap

• Value Proposition: the overall Investment Proposal, as known at the time, represents value to Defence outcomes relative to other investments.

• Is the expected financial allocation to get to the next Gate affordable and consistent with Defence priorities.

• Informed by Smart Buyer Risk Analysis, Joint Capability Needs Statement and Program Strategy:

• Consistent with due diligence obligations the IC is informed of risks, issuesand opportunities for theoverall proposal.• IC is informed of constraints that will impactoption selection andimplementation e.g.enablers, resources.• IC is informed ofdependencies and potentialimpacts on other parts ofDefence, industry etc.*• Stakeholders are identifiedand key interests understood

• IC is advised of the Critical Success Factors which have been used to evaluate the options including key factors:

Value proposition of each option (value for money if information available)

Supplier capacity and capability (market analysis)

Potential affordability Potential achievability For a direct to Gate 2

proposal, IC is advised of the options considered, the short-listing, and rationale for the preferred option/s. The Value Proposition of each option is described.

Where options require further development the argument is presented here for a Gate 1 decision.

• Proposed Project Execution Strategy (PES) based on Smart Buyer Framework for preferred option/s agreed on:*

• Tailored approval Pathway for Gates, decision delegations, time-bounding and plan (to next Gate);

• Tailored Acquisition and Sustainment Strategy including Industry Engagement and solicitation method

• Risk Reduction activities that address program and project risks consistent with Investment Committee’s risk appetite

• Sufficient documentation (tailored Information requirements)

• Cost and Schedule estimates (broad for overall investment and accurate for work to next Gate);

• Project execution Workforce • Management of Project/Program

dependencies • Governance and Assurance approach

• The resources required to reach the next Gate based on the PES are justified and available for implementation including:

• Cost of risk reduction activities and all other project costs to reach the next Gate.

• Agreement to schedule to next Gate.

• Project delivery Workforce

• Specific decisions for the proposal including:

• Guidance from VCDF on escalation criteria and thresholds for return to IC.

• Any other next steps

Business Case Guide: Tailored for particular gate based upon sufficiency of information required for decision

IC Actions



©2020 ‐ 537 ‐

Better Business Case

The objective of Better Business Cases is to provide objective analysis and consistent information to decision‐makers, to enable them to make smart investment decisions for public

value.

1073

Source: https://treasury.govt.nz/information‐and‐services/state‐sector‐leadership/investment‐management/better‐business‐cases‐bbc

Better Business Case

• Builds a business case proposal by answering five core questions:

– What is the compelling case for change?

– Does the preferred option optimise value for money?

– Is the proposed deal commercially viable?

– Is the investment proposal affordable?

– How can the proposal be delivered successfully?

1074

Source: http://www.treasury.govt.nz/statesector/investmentmanagement/plan/bbc/framework



©2020 ‐ 538 ‐

Business Case Development

The five cases are addressed within the business case development process:

1075

Better Business Case in Short

• Strategic Case – The big picture

• Economic Case – The options

• Financial Case – Do the numbers stack up?

• Commercial Case – Who delivers

• Management Case – Governance

1076

Source: Building Better Business Cases Association for Project Management, N. Wensleyhttps://www.slideshare.net/assocpm/building‐better‐business‐cases



©2020 ‐ 539 ‐

Business Cases are not just Written

• Business Cases are based on:

– Research

– Evidence

– Analysis

– Choices

– Decisions

• Supported by:

– Methods

– Techniques

1077

BBC Guidance

• Use BBC in a ‘fit for purpose’ way.

• Can be used for ANY Program, Project of any:

– scale, and

– risk and uncertainty.

• A Business case turns an idea (“Think”) into a proposal (“Plan”).

• Resources to develop business case should be proportionate to scale of the proposal.

1078

https://treasury.govt.nz/information‐and‐services/state‐sector‐leadership/investment‐management/better‐business‐cases‐bbc/bbc‐and‐investment‐management‐life‐cycle



©2020 ‐ 540 ‐

CLC Context: One Investment Better than Another?1079

Proposed Investment (eg Project)

Whole Defence Capability Portfolio

https://images.defence.gov.au/assets/archives (M113 Armoured Personnel Carrier

Two Types of Business Case in BBC Guide 1080

• Programme / Program

• Project




©2020 ‐ 541 ‐

Program to Project Business Cases 1081

AcquisitionStrategy and Concepts Risk Mitigation and Requirements Setting


Project

Product


ProgramAcquisition Strategy and Concepts



Acquisition Strategy and Concepts Risk Mitigation ad Requirements Setting


Acquisition Strategy and Concepts Risk Mitigation and Requirements Setting


A Good Business Case Should Demonstrate

• investment has value, importance and relevance;

• implementation is feasible and can be properly managed;

• organisation has capability to deliver the benefits;

• organisation’s resources are working on the highest value opportunities; AND

• inter‐dependencies are managed (optimum sequence).

1082

Source: Department of Finance ICT Business Case Guide, October 2015



©2020 ‐ 542 ‐

Program Business Cases

• Program: group of related Projects, Products and activities.

• Program Business Case comprises:

– Strategic vision.

– Roadmap of how to get there.

– How to manage change.

• Can be used for:

– Policy change, such as FPR.

– Capability Change, such as IAMD.

1083


Project Business Cases

• Project:

– fixed period,

– fixed objectives.

• Project Business Case:

– Indicative Business Case.

– Detailed Business Case.

– Implementation Business Case.

• Business Cases can be combined.

1084




©2020 ‐ 543 ‐

Purpose of a Business Case

• Provide information on benefits, costs and risks of proposal.

• Basis for effective decision making.

• Captures the reasoning for initiating an investment.

• Demonstrates resources support specific business need.

• Basis for planning and implementation.

• Basis for demonstrating ongoing viability of investment.

1085

Source: Department of Finance ICT Business Case Guide, October 2015


• Primary CLC decision document.

• Seeks approval to progress to next gate.

• Produced by Project Sponsor with IPMT.

• Sponsored by CM at each gate.

• Evolving document from Gate 0 to Gate 2:

– increases in depth, and

– information certainty.

• Generally significant lead time.

1086



©2020 ‐ 544 ‐


• Defence Business Cases must be:

– understandable,

– jargon‐free,

– scrutinised, and

– provide most accurate and timely advice Defence can prepare at the time.

• No Templates.

• No guidance available from lessons learnt.

1087

Business Case Definitions

• Live and working document.

• Communicates benefits and value of the endeavour.

• Drives decision‐making.

• Continuous reference to ensure progress aligned to the business objectives.

1088







©2020 ‐ 545 ‐

Submissions use Business Case Practice 1089





Submissions are based on Business Cases


BBC Approach for the CLC

Same underlying approach no matter what the Business Case being presented—that is:

• Program or Project.

• Gate 0,1,2 or non‐CLC proposal.

• Must develop Business Case/s based on Five Cases:

– Strategic.

– Economic.

– Commercial.

– Financial.

– Management.

1090



©2020 ‐ 546 ‐

BBC Approach for the CLC

Same underlying approach no matter what the Business Case being presented—that is:

• Program or Project.

• Gate 0,1,2 or non‐CLC proposal.

• Must develop Business Case/s based on Five Cases:

– Strategic

– Economic

– Commercial

– Financial

– Management

1091

24 steps or ‘actions’

Project Business Case Features

• 24 steps or ‘Actions’.• Basically same actions no matter the business case or stage

of CLC.

• Business Case evolves over CLC.

• Is based on rigorous underlying analysis and techniques:

– Demonstrates conformance with organisational goals.

– Explicit definition of requirements.

– Structured down‐selection of options.

1092



©2020 ‐ 547 ‐

Summary of Five ‘Cases’

• Strategic Case: Proposal aligns with strategic intent and priorities.

• Economic Case: Value proposition and options for proposed investment are sound.

• Financial Case: Resourcing provisions are addressed.

• Commercial Case: Requirements, execution strategy including acquisition and sustainment strategy, risk.

• Management Case: Management arrangements are appropriate.

1093

Case Study: Business Cases

• Strategic Case:

– Proposal aligns with strategic intent and priorities.

– Contained in JCNS.

• Economic Case:

– Options and value proposition for the proposed investment are sound.

– Spend $10m to protect $1bn.

– Need to be able to use the asset in the necessary environments ie can’t be constrained.

– Standardised ES system across fleet so economies of scale for acquisitions, training, support.

1094



©2020 ‐ 548 ‐


• Financial Case:

– Resourcing provisions are addressed including:

– costings defined:

• estimates for risk reduction;

• outcomes of risk reduction effort enabled better quotes (uncertainty increases costs);

• estimates for acquisition and support; and

• phasings and currencies defined.

– workforce requirements and timings defined;

– savings achieved by reducing support costs eg training, maintenance.

1095


• Commercial Case:

– can leverage off other competitions (RFTs) and contracts to reduce cost of tendering; and

– installation through ANZAC Alliance using existing contracts with BAE (installation) and SAAB (combat system integration).

• Management Case:

– Prime System Integrator – overarching manager.

– MEWSPO has expertise in EW so case for system SPO management argued.

– Defined engagement between AWD Project, ASMD Project and SEA 1448 Phase 4A through formal documented ‘Project Agreements’.

1096



©2020 ‐ 549 ‐

Submission Pathways

Business Argument via Submissions1098




Disposal

Gate 0 Gate 2Gate 1

ApprovalsIC

Approval

IC, Government

Approval




Contestability

Activities

Smart Buyer

CM Needs




Smart Buyer


PFPS*

POCD*

PES 1JCNSJCN

FPS*

OCD*PES 2

IPMP

PES 3Reduced Risk

Sub

mis

sion

App

rova

l &

Dire

ctio

n

Sub

mis

sion

Project Activities

IMS

Sub

mis

sion

Product Activities

Contract Docs

IPMP

PDA/MAA

Contract Docs

IPdMP




Project Management


App

rova

l &

Dire

ctio

n

App

rova

l &

Dire

ctio

n

Contract Management

Off

er

Acc

epta

nce

App

rova

l




©2020 ‐ 550 ‐

Approval Submission Pathways1099

Cabinet Liaison Services

Cost Workforce

PES

JCNS

Covering Brief

NSIC

NSC

Contestability

GATE 0 GATE 2GATE 1


Approval

Go

vern

me

nt

Ap

pro

val


Approval


Approval

FIRST PASS SECOND PASS

Def

ence

A

pp

rova

l

CMGR CMGR CMGR

Cabinet

Business Case*

DoF

PM&C

1,2,3 Minister

NSIC

NSC

Cabinet 1,2,3

Minister

MINSUB

CABSUB

MINSUB CABSUB

* Only if no CABSUB

MINSUB must cover a CABSUB

Business Case

Tier 2 docs must be at mature draft

Group Head Brief

& Script

Contesta-bility Brief


ICSynopsis

Sponsors Paper Central

Agency Slide Pack

Cost Model

PWC

DTPSMC

Significant facilities, ICT

Sub

mis

sion

Sub

mis

sion

Sub

mis

sion


Risk Mitigation and Requirements Setting In-Service and Disposal

Approval Submissions: Gates/Passes

Note:

• Following IC Gate 1 approval, the subsequent approval by Government is First Pass approval,

• Following IC Gate 2 approval the subsequent approval by Government is Second Pass approval.

1100

Source: IPMB and Army HQ Business Model



©2020 ‐ 551 ‐

CMGR submissions

Approval Submission Pathways1102


Cost Workforce

PES

JCNS

Covering Brief

NSIC

NSC

Contestability



GATE 0 GATE 2GATE 1


Approval

Go

vern

me

nt

Ap

pro

val


Approval


Approval


Def

ence

A

pp

rova

l

CMGR CMGR CMGR

Cabinet

Business Case*

DoF

PM&C

1,2,3 Minister

NSIC

NSC

Cabinet 1,2,3

Minister

MINSUB

CABSUB

MINSUB CABSUB

* Only if no CABSUB


Business Case

Group Head Brief

& Script



ICSynopsis


Agency Slide Pack

Cost Model

PWC

DTPSMC


Sub

mis

sion

Sub

mis

sion

Sub

mis

sion



©2020 ‐ 552 ‐

Lead Times to Gate 0 (IPMB Website)1103


Capability Manager Gate Review (CMGR)

• 2‐Star / SES Band‐2 CM‐led governance forum.

• Not compulsory (choice of CM).

• Quality control point for Projects/Programs prior to IC.

• Opportunity for:

– high level consultation; and

– identify and resolve key concerns.

• Contestability advice either:

– stand‐alone Contestability Brief, or

– Sponsor’s Paper/Business Case with embedded Contestability advice.

1104



©2020 ‐ 553 ‐

CMGR Submission ‘Rules’

• Documents must be submitted to VCDF IPM Coord on DSN.

• Date is ‘supporting event’ in CDMRT/Capability 1.

• Once submitted modifications to documents only permitted with Program Sponsor’s approval.

• Contestability advice :

– at discretion of relevant Contestability Executive; and

– standalone Contestability Brief or embedded in Sponsor’s Paper/Business Case.

• Contestability Division drafts key decisions, actions and minutes from CMGR meeting in consultation with the relevant Program Sponsor.

1105

Source: IPMB website

CMGR Process

• Project Sponsors to engage with key stakeholders during development of document suite.

• 25‐15 days prior to meeting: Project Sponsor to finaliseCMGR document and any SCARs in CDMRT.

• NLT 15 working days prior: Program Sponsor lodge cleared doc suite including CMGR synopsis “Section A” to VCDF IPM Coord.

• NLT 3 working days prior: submit CMGR Synopsis “Section B”.

• NLT 5 days prior: Contestability Brief:

– due to VCDF IPM Coord; and

– made available to CMGRMembers and Support Staff.

1106




©2020 ‐ 554 ‐

CMGR Submissions: CMGR Synopsis

• Program Sponsors should review the Synopsis form located in CDMRT to determine: input, consultation and assurance to be sought from CMGR Members.

• CMGR Synopsis provides Committee with:

– snap‐shot of proposal

– checklist for CMs to make sure:

• key issues thought through;

• key internal stakeholders engaged;

– can include draft Government approval submission.

1107





©2020 ‐ 555 ‐

Approval Submission Pathways 1109


Cost Workforce

PES

JCNS

Covering Brief

NSIC

NSC

Contestability

GATE 0 GATE 2GATE 1


Approval

Go

vern

me

nt

Ap

pro

val


Approval


Approval

Sub

mis

sion

Sub

mis

sion

Sub

mis

sion


Def

ence

A

pp

rova

l

CMGR CMGR CMGR

Cabinet

Business Case*

DoF

PM&C

1,2,3 Minister

NSIC

NSC

Cabinet 1,2,3

Minister

MINSUB

CABSUB

MINSUB CABSUB

* Only if no CABSUB


Business Case


Group Head Brief

& Script



ICSynopsis


Agency Slide Pack

Cost Model

PWC

DTPSMC





• Managed through Investment Committee (IC) and Defence Committee (DC).

• Spans all capability investment (over whole CLC):

– Major Capital Equipment.

– Enterprise ICT.

– Estate initiatives.

1110

http://www.defence.gov.au/CIOG/Careers.asphttps://images.defence.gov.au/assets/archives (M113 Armoured Personnel Carrier & C17-A RAAF Base Amberley)



©2020 ‐ 556 ‐


• Subsidiary of Defence Committee.

• Ensures resourcing consistent with Defence’s strategic priorities.

• Makes Gate 0 decisions for majority of proposals.

• Oversees implementation and integrity of IIP.

• VCDF (Chair):

– Assoc Sec

– CJC

– DEPSEC SP&I

– CFO

– CN, CA, CAF

1111

Government

Defence Committee


Capability Manager

Program Sponsor


– DEPSEC CAS, CDS

– FAS Contestability

– Central Agencies (Finance, PM&C)


What?

How?

Why?

Project Execution Strategy (PES)How will investment (Project) be undertaken

Sponsor Paper

+

+





©2020 ‐ 557 ‐

Gate 1&2 Proposals: Components May Include1113

What?

How?

Requirements Statement

Updated PES

Integrated Project Management Plan (IPMP) to Gate 2

Why? Sponsor Paper

+

+

+

Draft Submission to Government Why?

+

Summary of What to Take to the IC1114

Use Gate 0 Gate 1 Gate 2Government CabSub or MinSub CabSub or MinSub


• IC Synopsis • Sponsor Paper:

- Business Case argument

- Contestability Statement

- Total Cost of Ownership (TCO)

- Industry considerations

• JCNS

• PES

• IC Synopsis • Sponsor Paper- no

longer than 3 pages • Draft Approval

Submission to Government either Ministerial submission or Cabinet Submission

• Draft Approval Submission to Government either Ministerial submission or Cabinet Submission

Key Considerations

Business Case, RiskAssessment and mitigation actions, Acquisition and Sustainment Strategies, IPMP, Cost Estimates, Workforce Estimates, Whole FIC

Business Case, Risk Assessment and mitigation actions, costs and schedule estimates, IPMP, Requirements (OCD, FPS, TEMP)

Business Case, Risk Assessment and mitigation actions, costs and schedule estimates,IPMP, Requirements (OCD, FPS, TEMP), Source Evaluation



©2020 ‐ 558 ‐

Beyond IC:Gaining Government Approval for Proposals



Cost Workforce

PES

JCNS

Covering Brief

NSIC

NSC

Contestability

GATE 0 GATE 2GATE 1


Approval

Go

vern

me

nt

Ap

pro

val


Approval


Approval

Sub

mis

sion

Sub

mis

sion

Sub

mis

sion


Def

ence

A

pp

rova

l

CMGR CMGR CMGR

Cabinet

Business Case*

DoF

PM&C

1,2,3 Minister

NSIC

NSC

Cabinet 1,2,3

Minister

MINSUB

CABSUB

MINSUB CABSUB

* Only if no CABSUB


Business Case


Group Head Brief

& Script



ICSynopsis


Agency Slide Pack

Cost Model

PWC

DTPSMC






©2020 ‐ 559 ‐

What is Cabinet? 1117

What is Cabinet?

• “The Cabinet is the focal point of the decision‐making process of government.”

Source: https://www.aph.gov.au/

• Council of senior ministers empowered by Government to:

– take binding decisions on behalf of the Government.

– direct Government policy and

– make decisions on important national issues.

• The Cabinet is a product of convention and practice.

• Meets on a weekly basis throughout the year.

• Minister for Defence has responsibility for all Defencematters in Cabinet.

1118



©2020 ‐ 560 ‐

Cabinet and Committees consider…

• new policy proposals or changes;

• proposals which significantly affect employment;

• expenditure proposals;

• proposals requiring legislation;

• proposals which impact relations between Australian Government and foreign, state, territory or local governments;

• proposed responses to parliamentary committee etc;

• negotiation or agreement of international treaties; and

• requests from parliamentary committees for references.

1119

Source: https://www.directory.gov.au/commonwealth‐parliament/cabinet/cabinet‐committees

Cabinet Committees

• Subject area, such as national security.

• General function, such as expenditure.

• Can be temporary or ad‐hoc:

– Expenditure Review Committee.

– Governance Committee.

– National Security Committee (NSC).

– National Security Investment Committee (NSIC).

– Parliamentary Business Committee.

– Service Delivery and Coordination Committee.

1120




©2020 ‐ 561 ‐

National Security Committee (NSC)

• Chair: PM

• Focus on:

– major foreign policy and national security issues of strategic importance to Australia;

– border protection policy;

– national responses to developing situations (either domestic or international); and

– classified matters relating to aspects of operation and activities of the Australian Intelligence Community.

• Decisions of NSC do not require endorsement of Cabinet.

1121


Defence Projects and NSC

Projects will automatically be referred to NSC if assessed as HIGH risk against four criteria:

• Financial: unaffordable from within existing IIP; potential cost increases (IIP re‐profiling).

• Requirements: new and/or potentially contentious military capability; requirements ill‐defined; wide range of options.

• Technical and Integration: developmental, extensive technical design, development work, especially integration and interoperability.

• Industrial and Strategic: strategically significant industrial capability or contractor selection; significant innovation and economic opportunities for Australian industry, Political and security factors.

1122

Source: ASIP presentation Feb 2017



©2020 ‐ 562 ‐

National Security Investment Committee(NSIC)

• Under the auspices of NSC considers in detail major National Security investments and procurements to ensure:

– investments remain aligned with Australia’s strategic priorities,

– achieve best value, and

– implemented on schedule.

• Decisions of the NSIC must be endorsed by the NSC.

1123


When does a Proposal go to Cabinet?

A Proposal goes to Cabinet when it:

• addresses a top priority of the Government;

• has significant budget implications;

• makes major or complex changes;

• involves significant cross‐agency or cross‐jurisdictional issues;

• is particularly sensitive—for example, has a large number of conflicting stakeholders, is particularly risky or impacts a significant number of people or a vulnerable cohort;

• requires urgent implementation; or

• involves new or complex delivery systems.

1124

Source: https://www.pmc.gov.au/government/policy‐implementation



©2020 ‐ 563 ‐

Who Decides if a Proposal Goes to Cabinet?

• Joint decision between the agency responsible for drafting the submission and PM&C.

1125


Resource: Better Business Practice Guide

• Cabinet Handbook (13th Edition).

• Better Business Practice Guide to Successful Implementation of Policy Initiatives.

1126

Source: https://www.pmc.gov.au/



©2020 ‐ 564 ‐

Advice

• Cabinet Liaison Services (CLS): Can provide advice on…

• PM&C can provide advice on:

– the Cabinet Submission process,

– the level of detail in the submission, and

– which of the principles of implementation the Cabinet requires information on.

1127


Other Committees



©2020 ‐ 565 ‐



Cost Workforce

PES

JCNS

Covering Brief

NSIC

NSC

Contestability

GATE 0 GATE 2GATE 1


Approval

Go

vern

me

nt

Ap

pro

val


Approval


Approval

Sub

mis

sion

Sub

mis

sion

Sub

mis

sion


Def

ence

A

pp

rova

l

CMGR CMGR CMGR

Cabinet

Business Case*

DoF

PM&C

1,2,3 Minister

NSIC

NSC

Cabinet 1,2,3

Minister

MINSUB

CABSUB

MINSUB CABSUB

* Only if no CABSUB


Business Case


Group Head Brief

& Script



ICSynopsis


Agency Slide Pack

Cost Model

PWC

DTPSMC




Public Works Committee (PWC)

1130



©2020 ‐ 566 ‐

Facilities: Two ‘Pathways’

Facilities proposals progressed in two ways:

1. Approval for funding

2. Scrutiny

1131

$

Capability Submission Pathway1132


Cost Workforce

JCNS

Covering Brief

NSIC

NSC

Contestability

GATE 0 GATE 2GATE 1


Approval

Go

vern

me

nt

Ap

pro

val


Approval


Approval

Sub

mis

sion

Sub

mis

sion

Sub

mis

sion


Def

ence

A

pp

rova

l

CMGR CMGR CMGR

Cabinet

Business Case*

DoF

PM&C

1,2,3 Minister

NSIC

NSC

Cabinet 1,2,3

Minister

MINSUB

CABSUB

MINSUB CABSUB

* Only if no CABSUB


Business Case


Group Head Brief

& Script



ICSynopsis


Agency Slide Pack

Cost Model

PWC

DTPSMC


PES

Facilities





©2020 ‐ 567 ‐

Facilities BC: ‘spins off’ from Capability Submission 1133

Parliamentary Approval


Cost Workforce

JCNS

Covering Brief

NSIC

NSC

Contestability


Risk Mitigation and Requirements Setting In-Service & Disposal

GATE 0 GATE 2GATE 1


Approval

Go

vern

me

nt

Ap

pro

val


Approval


Approval

Sub

mis

sion

Sub

mis

sion

Sub

mis

sion


Def

ence

A

pp

rova

l

CMGR

Cabinet DoF

PM&C

1,2,3 Minister

NSIC

NSC

Cabinet 1,2,3

Minister

MINSUB

CABSUB


Business Case



Cost Model

PWC


PES

Facilities

Facilities Initial

Business Case

Facilities DetailedBusiness

Case

Value dependent

Public Works Committee (PWC): Scrutiny

• Investigative committees of the Parliament.

• Established under Public Works Committee Act 1969.

• All public works for the Commonwealth estimated to cost more than $15 million must be referred to the Committee.

• Includes Commonwealth departments and major statutory authorities.

1134

Source: https://www.aph.gov.au/Parliamentary_Business/Committees/Joint/Public_Works/Role_of_the_Committee



©2020 ‐ 568 ‐

Public Works Committee (PWC)

• Report on:

– purpose and suitability of the proposed work,

– need for the work,

– cost‐effectiveness of the proposal,

– revenue it will produce if the work is revenue producing, and

– current and prospective value of the work.

1135

Source: https://www.aph.gov.au/Parliamentary_Business/Committees/Joint/Public_Works/Role_of_the_Committee

ICT Investment Approval Process

1136



©2020 ‐ 569 ‐


“If your entity is bringing forward an ICT‐enabled proposal for Cabinet consideration you may be subject to the ICT Investment Approval process.”

1137

Source: https://www.finance.gov.au/policy‐guides‐procurement/ict‐investment‐framework/ict‐two‐pass‐review/


ICT Investment Approval Process applies* if:

• Proposal is ICT‐enabled (policy or service highly dependent on an underpinning ICT system);

AND

• total whole‐of‐life cost >$30 million incl. ICT >$10 more;

AND

• Proposal is high risk** (complexity, schedule or available workforce capacity)

1138

* Defence should consult with Investment, Capability and Assurance Branch in the Department of Finance (Finance)** Risk rating for proposals is determined by Finance.




©2020 ‐ 570 ‐


If it applies* the minimum stages are:

• First Pass Cabinet Approval

• Second Pass Cabinet Approval

A business case required at both stages to ensure Cabinet has sufficient information about the proposal to make an informed decision.

1139

* Defence should consult with Investment, Capability and Assurance Branch in the Department of Finance (Finance)


Digital Transformation and Public Sector Modernisation Committee of Cabinet

(DTPSMC)

1140



©2020 ‐ 571 ‐

Digital Transformation Agency (DTA)

• The Digital Transformation Agency (DTA) is an Executive Agency within the Prime Minister and Cabinet portfolio.

• Strategic leadership on:

– whole‐of‐government and shared ICT and digital services,

– sourcing and capability development.

• Policies, standards and platforms for whole‐of‐government and shared ICT and digital service delivery.

• Advice to agencies and the Government on ICT and digital investment proposals.

• Oversee significant ICT and digital investments

1141

Source: https://www.dta.gov.au/about‐us

Digital Transformation and Public Sector Modernisation Committee (DTPSMC)

• Oversees the Digital Transformation Agenda to:

– improve the experience of people dealing with Government;

– drive service delivery reform;

– transform, simplify and drive value in Commonwealth ICT; and

– modernise the Australian Public Service.

• Decisions of the DTPSMC must be endorsed by the Cabinet.

• This committee was formally known as the Digital Transformation Committee (DTC).

1142




©2020 ‐ 572 ‐

DTPSMC

• Digital Transformation and Public Sector ModernisationCommittee of Cabinet.

• Government’s Digital Transformation Strategy, Nov 2018:

– Roadmap with 2 year horizon.

– Digital Service Standard to assess government digital services.

• Objectives: modernise the Australian Public Service (APS) so that it is best structured to meet the challenges of digital delivery of government services.

1143

Defence Requirements of ICT Projects

1144



©2020 ‐ 573 ‐

ICT and Digital‐enabled Submissions

• Need to satisfy/align with:

– Defence Enterprise Information Management Strategy 2015‐2025.

• Defence vision for EIM:

“trusted and accurate information and information services are delivered to the point of need to enhance military and business operations”.

1145

ICT and Digital‐enabled Submissions

• Defence Architecture Vision Statement identified the strategic importance of an Enterprise approach to EIM for Defence. It provides a high level vision and mission for EIM within Defence.

• This document will assist the reader in understanding the high level architectural goals and strategy of EIM.

• Informs: Current State Architecture, Target State Architecture, Data Architecture, Information Exchanges, Domain Roadmaps

1146



©2020 ‐ 574 ‐

Department of Finance

Provision of Cost Models



Cost Workforce

PES

JCNS

Covering Brief

NSIC

NSC

Contestability



GATE 0 GATE 2GATE 1


Approval

Go

vern

me

nt

Ap

pro

val


Approval


Approval

Sub

mis

sion

Sub

mis

sion

Sub

mis

sion


Def

ence

A

pp

rova

l

CMGR CMGR CMGR

Cabinet

Business Case*

DoF

PM&C

1,2,3 Minister

NSIC

NSC

Cabinet 1,2,3

Minister

MINSUB

CABSUB

MINSUB CABSUB

* Only if no CABSUB


Business Case


Group Head Brief

& Script



ICSynopsis


Agency Slide Pack

Cost Model

PWC

DTPSMC




©2020 ‐ 575 ‐

Dept of Finance Guidance/Requirements

• Estimates Memorandum: Defence‐specific.

• Total Cost of Ownership (TCO), Whole of Lifecycle.

• Defence Capability, ICT, Facilities.

• Must provide Cost Model:

– all assumptions, data and formulae, other evidence.

• Cost Quality Standards:

– First to Second Pass (strategic Gate 1).

– Second Pass and Combined Pass (acquisition Gate 2).

• Parametric or analogous costing methodology where no tender quality information.

1149

Gaining Government Approval for Proposals

1150



©2020 ‐ 576 ‐



Cost Workforce

PES

JCNS

Covering Brief

NSIC

NSC

Contestability



GATE 0 GATE 2GATE 1


Approval

Go

vern

me

nt

Ap

pro

val


Approval


Approval

Sub

mis

sion

Sub

mis

sion

Sub

mis

sion


Def

ence

A

pp

rova

l

CMGR CMGR CMGR

Cabinet

Business Case*

DoF

PM&C

1,2,3 Minister

NSIC

NSC

Cabinet 1,2,3

Minister

MINSUB

CABSUB

MINSUB CABSUB

* Only if no CABSUB


Business Case


Group Head Brief

& Script



ICSynopsis


Agency Slide Pack

Cost Model

PWC

DTPSMC


CABSUBs and MINSUBs

1152



©2020 ‐ 577 ‐

MINSUB vs CABSUB

• A ministerial submission (MINSUB) is used when approaching one or two ministers.

• A cabinet submission (CABSUB) is used when approaching Cabinet or a Cabinet sub‐committee.

1153


What is a Cabinet Submission (CABSUB)

• A Cabinet Submission is a document that a minister or ministers present to Cabinet to obtain its agreement to a course of action.

• Cabinet generally makes a decision on the proposals within the submission, and the decisions are published as:

– Cabinet Minute, or

– Cabinet Memorandum.

1154

https://www.finance.gov.au/resource‐management/pgpa‐glossary/cabinet‐submission‐minute‐memorandum/



©2020 ‐ 578 ‐

What is a Cabinet Submission (CABSUB)

• Submissions must be sponsored by the Cabinet minister with portfolio responsibility.

• Proposals may be sponsored jointly by more than one minister.

• Proposals that are complex and challenging should have implementation plans developed to ensure all the risks are identified and mitigation strategies are in place.

1155

Source: https://www.pmc.gov.au/sites/default/files/publications/cabinet‐handbook‐13th‐edition_0.pdf

Handling of CABSUBs

• Must not be copied, transcribed or copying into departmental IT systems.

• If copies required, a request must be submitted to Cabinet Division including the ‘need‐to‐know’.

• Hard‐copy Cabinet documents must be kept in Cabinet‐specific files in suitably classified storage containers.

1156




©2020 ‐ 579 ‐

CABSUB Development for Defence

• Use a CABSUB when approaching Cabinet or a Cabinet sub‐committee (e.g. NSC) .

• Defence is usually the business of NSC.

• A Covering Ministerial Submission (MINSUB) is also required to support the CABSUB.

• Business Case no longer required as attachment to Govt Submission however must be available upon request (Ensure Contestability have access to the Business Cases).

1157


CABSUB Development for Defence

• Initiating CABSUB:

– CLS advisor will meet with you to provide key information and discuss mandatory requirements for your item to be considered by NSC.

• Lodge CABSUB: Pre‐Exposure Draft with CLS.

1158




©2020 ‐ 580 ‐

Lead‐times for CABSUB submission

Days ahead of Cabinet Meeting:

• Exposure Draft: 16 working days (check)

• Co‐ord Final Version released: 6 working days (check)

• Final Released: 3 working days (check)

• CABSUB Exposure Draft for DTPSMC for ICT‐related proposal with CLS: DTPSMC date minus 28 working days.

1159


MINSUB purpose

• Prepared by Department to provide information to the Minister.

• Ask Minister to note issues, approve requests or make a decision on a subject.

• The Business Case is an attachment to the MINSUB.

• Neither JCNS nor PES are provided to IC or Government for Gate 1 or Gate 2.

1160




©2020 ‐ 581 ‐

MINSUB Rules

• All Ministerial submission (MINSUB) should be accompanied by:

– covering brief, outlining reason(s) for the MINSUB; and

– actions to be taken by CDF/SEC, timelines.

• MINSUB for CDF and SEC signature must be submitted with all attachments in soft copy.

• MINSUBs and all attachments are placed in a dedicated system (PDMS).

• If a MINSUB is extremely sensitive, a hard and electronic copy is to be provided.

1161


MINSUB Timings

• Lodge MINSUB with the Executive Support Unit: target month minus 10 working days.

• SEC / CDF clearance: 5 working days.

• 1MIN clearance / approval: 5 working days (facilitated by Directorate of Ministerial Services).

• 2MIN / 3MIN clearance / approval: no set timeframe (facilitated by Directorate of Ministerial Services).

1162




©2020 ‐ 582 ‐

Approval Submissions: Templates

• Must use correct Cabinet and Ministerial submission templates:

– specific formatting and style rules for CABSUBS;

– location of templates depends on whether a Cabinet or Ministerial submission:

• CabSub at Cabinet Liaison Services (CLS) webpage (DPN and DSN); and

• MINSUB templates located on Parliamentary Document Management System (PDMS) on the DSN.

• To access templates, you must first create a parliamentary document record.

1163


Approval Submission Content

• Submission must cater to the correct audience:

– Likely a broad, strategic knowledge of capability proposal.

– Very little time to read and make sense of submission.

– Present complex information in a simple style that is easy for all stakeholders to understand.

1164




©2020 ‐ 583 ‐

Approval Submissions: Final points

Shape the Pathway

There are two key forms of tailoring:

• Approval Authority – “Who is approving?”

– NSC, Two Minister, One Minister, internal Defence (or a combination of all of these at different time points).

• Approval Pathway – “How many approvals?”

– Two Pass, Combined Pass, multiple approaches, and ‘rolling wave’ tranches.

1166



©2020 ‐ 584 ‐

Government Pathway Options

1. Number of required Government decision points (one, two, or multiple).

2. Nature of the decision point(s) and approval sought:

– strategic (First Pass);

– acquisition (Second Pass); or

– combined pass.

3. Required approval authority:

– Cabinet approval;

– Two Minister (Finance and Defence) approval; or

– One Minister (Defence) approval;

– including ERC, DTPSMC.

1167


Shape the Pathway

• Majority of individual IIP projects are still likely to be 2 Pass /

NSC approvals.

• The Investment Committee will validate the pathway.

1168




©2020 ‐ 585 ‐

Criteria for Fast Track / Gates 0 to 2

Criteria for Fast Track / Gates 0 to 2:

• only one feasible supplier;

• acquiring additional quantities of an existing capability;

• mandatory interoperability requirements that dictate a certain platform choice;

• operational urgency; and

• proposal is simple and low risk and within existing operational policies.

1169


Gates 0 to 2

• If a Gate 0‐2 path is agreed may need to seek:

– early access to IIP funding ahead of Gate 2, and

– permission to engage with Industry ahead of Government approval.

• This is achieved through the omnibus Biannual IIP Update to Government.

• Two forms of Biannual Updates:

– Portfolio Budgets Statements (PBS).

– Mid‐Year Economic and Fiscal Outlook (MYEFO).

1170




©2020 ‐ 586 ‐

NSC

Projects will automatically be referred to NSC if assessed as HIGH risk against four criteria:

• Financial

• Requirements

• Technical and Integration

• Industrial and Strategic

1171


First Pass

• First Pass approval only required for:

– complex and high‐risk projects / programs, or

– when a Government decision is required in order to narrow the field of options.

• Main concerns are whether:

– options comply with strategic guidance and capability priorities;

– options are feasible, affordable and sufficiently differentiated; and

– the plan to achieve Second Pass approval is sound and accurately costed.

1172




©2020 ‐ 587 ‐

Approval Submissions

• Start 6 months prior to scheduled approval date:

– Scheduled National Security Committee of Cabinet (NSC) meeting for Cabinet Approvals.

– Target month for Ministerial Approvals.

– Commence drafting before CMGR.

1173


Approval Submissions: Checklists 1st, 2nd Pass

• Help CM reps determine if Government is being provided with enough information to make informed decision.

1174




©2020 ‐ 588 ‐

Examples of Pathways

• Continuing an existing Prime Systems Integrator (PSI) relationship (i.e. ‘single supplier’) on a large scale ICT project, with sub‐elements to be competed by Industry:

– Approach approved by Government at First Pass due to arguments presented on cost and schedule savings, reduced risk and retention of competition in sub‐elements.

– Significant follow‐on acquisition approvals directly to Second Pass.

1175



Cost Workforce

PES

JCNS

Covering Brief

NSIC

NSC

Contestability



GATE 0 GATE 2GATE 1


Approval

Go

vern

me

nt

Ap

pro

val


Approval


Approval

Sub

mis

sion

Sub

mis

sion

Sub

mis

sion


Def

ence

A

pp

rova

l

CMGR CMGR CMGR

Cabinet

Business Case*

DoF

PM&C

1,2,3 Minister

NSIC

NSC

Cabinet 1,2,3

Minister

MINSUB

CABSUB

MINSUB CABSUB

* Only if no CABSUB


Business Case


Group Head Brief

& Script



ICSynopsis


Agency Slide Pack

Cost Model

PWC

DTPSMC


Strategic approach approval

Subsequent Acquisition approvals



©2020 ‐ 589 ‐

Examples of Pathways

• A ‘rolling wave’ or tranched approach to respond to rapidly changing threats and technologies:

– Flexible funding arrangements with corresponding reporting and forecasting updates to Government based on arguments of greater responsiveness to changing environments.

– early IIP funding requests based on flexible funding ‘offset’ arrangements that allow time critical work to continue.

1177



Cost Workforce

PES

JCNS

Covering Brief

NSIC

NSC

Contestability



GATE 0 GATE 2GATE 1


Approval

Go

vern

me

nt

Ap

pro

val


Approval


Approval

Sub

mis

sion

Sub

mis

sion

Sub

mis

sion


Def

ence

A

pp

rova

l

CMGR CMGR CMGR

Cabinet

Business Case*

DoF

PM&C

1,2,3 Minister

NSIC

NSC

Cabinet 1,2,3

Minister

MINSUB

CABSUB

MINSUB CABSUB

* Only if no CABSUB


Business Case


Group Head Brief

& Script



ICSynopsis


Agency Slide Pack

Cost Model

PWC

DTPSMC


Combined Pass: Strategic and Acquisition approval

Regular reporting and updates through

Biannual Updates (PBS and MYEFO)



©2020 ‐ 590 ‐

Approval Submission: 1st Pass Checklist 1179

Is proposal IAW extant Government and Defence decisions and/or guidance?

‐What has Government previously agreed or stated in public about the project?

‐What has previously been agreed by Defence?

Are the outcomes clear and justifiable?

‐ Is decision sought from Government clear?

‐ Is the capability outcome sought clear, affordable and aligned with capability priorities?

What will the project deliver?

‐What is the strategic justification for the capability?

‐What is the capability aspiration?

‐ How does proposal address the capability aspiration?

Is the option set defensible?

‐ Are the options clearly described?

‐ Does the option set offer a range of cost‐capability drivers?

‐ Are there any alternatives to the option set?

‐ Are there any off‐the‐shelf options?

…

‐ Are all of the options viable and affordable?

‐ Have the right options been recommended for developmentto Gate 2?

Is there enough information to make a decision?

‐ Do the documents provide ‘Gate 1’ quality information?

‐ Are the costs affordable, suitably benchmarked, and in linewith the scope of the project?

‐ Can the implementation strategies be carried out?

‐ Is the schedule viable and agreed by all stakeholders?

‐ Are the workforce requirements agreed and within theallocation? If not, have offsets been identified?

‐ Are there industry issues associated with this proposal? If so,are they well understood and articulated?

‐ Have the main risks been identified? How will they bemanaged?

‐ Has all data been signed off by the relevant stakeholders?

Can the approval submission be written?

‐ Is the proposal complete?


Approval Submission: 2nd Pass Checklist 1180

Is the proposal in accordance with extant Government and Defence decisions and/or guidance?

‐What has Government previously agreed at Gate 1 approval or stated in public about the project?

‐What has previously been agreed by Defence?

Are the outcomes clear and justifiable?

‐ Is the decision sought from the Government clear?

‐ Is the capability outcome sought clear, affordable and aligned with capability priorities and Gate 1 decisions?

Is the recommended option appropriate and justifiable?

‐ Is the recommended option clearly described? Is it demonstrably better than the other options?

‐ Has there been any change in the options set since Gate 1 approval? If so, is the change justifiable?

‐ Does the recommended option fall within the provision, or are offsets provided?

‐ Is the recommended option off‐the‐shelf? If not, why not?

‐ Has sufficient account been taken of constraints and overarching imperatives?

‐ Are there any industry or probity issues associated with the outcomes?

…

Is there enough information to support a decision?

‐ Do the documents provide ‘Gate 2’ quality information?

‐ Is the project scope clear?

‐ Are the implementation strategies viable?

‐ Is the schedule viable?

‐ Are the costs affordable, suitably benchmarked, and aligned tothe scope of the project?

‐ Have the main risks been identified? How will they bemanaged?

‐ Do the results of the Gate 1 to Gate 2 activities support theconclusions?

‐ Has all data been signed off by the relevant stakeholders?

Can the approval submission be written?

‐ Is the proposal complete?




©2020 ‐ 591 ‐



Cost Workforce

PES

JCNS

Covering Brief

NSIC

NSC

Contestability



GATE 0 GATE 2GATE 1


Approval

Go

vern

me

nt

Ap

pro

val


Approval


Approval

Sub

mis

sion

Sub

mis

sion

Sub

mis

sion


Def

ence

A

pp

rova

l

CMGR CMGR CMGR

Cabinet

Business Case*

DoF

PM&C

1,2,3 Minister

NSIC

NSC

Cabinet 1,2,3

Minister

MINSUB

CABSUB

MINSUB CABSUB

* Only if no CABSUB


Business Case

Group Head Brief

& Script



ICSynopsis


Agency Slide Pack

Cost Model

PWC

DTPSMC


Capability Life Cycle (CLC)Management

Professor Mike Ryan

Dr Shari Soutberg