A Defence Capability Framework (05) - System

It has been a while since I blogged. I have been a bit busy with a few things, among them a proposal for one of our other business interests - Mantra Training and Development - a Registered Training Organisation (RTO). So, just to provide a little context, this blog is a continuation of the "Defence Capability Framework" series. The last two were on the Operational level and the Strategic level. This one has a focus on the System level within the Australian Defence context.

Program Framework - Defence

REQUIREMENT

The requirement at the system level is called a "Functional Performance Specification (FPS)" in the Australian Defence context. I am not convinced it is a specification as such ... more a system level requirement. It also contains "non-functional requirements", so it isn't solely "functional" in nature anyway.

The system requirement - the Functional Performance Specification (FPS) - at least the functional requirements ....should be derived from the operational requirements in the Operational Concept Document (OCD) at the operational level. This isn't always the case ... or perhaps it is rarely the case! What should happen is that each and every operational requirement (or warfighting function) should be reviewed and system requirements developed from them. Accordingly, you end up with traceability from operational level need to system level need. But what happens more often than not I believe, is that the consultant reads the Operational Concept Document (OCD) and then writes up a Functional Performance Specification (FPS). Traceability is an afterthought! I haven't tried to analyse what the impact of this might be, but I suspect it has quite an impact in terms of trying to determine whether the delivered system actually achieves what the sailor, soldier or airman requires in the system level solution.

SOLUTIONS

Plainly, the solutions at this level are "systems". But in terms of how this knowledge sector is developed and articulated, I have called this a System Breakdown Structure or SBS. The SBS could be represented by the "specification tree", one of the deliverables for a Defence materiel procurement contract actually. Going from the functional view of the system requirement (or Functional Performance Specification (FPS)) to the physical view in the System Breakdown Structure is called the design process or "synthesis" or "synthesising". It isn't easy and it isn't fast, but it has to be done.

If we looked at this from a tenderer's perspective, then the SBS is what is offered to Defence against its Functional Performance Specification (FPS) contained within the Request for Tender (RFT). It is the tenderer's design of a system that is being offered. Without a design, you can't cost a response ..... because you can't cost a requirement - only a thing ... and a thing performing functions over time. That brings me to the next part of the system level "flow" - the processes.

VEHICLES OR PROCESSES

To actually cost a design, you need to understand what work it takes to actually develop, build and test it. The only way you can do that is to develop a Work Breakdown Structure (WBS). The WBS contains all the work and the resources required to do that work. If you have all the work required and all the resources (including materials) required to develop, build and test a design, then you can cost a System Breakdown Structure (SBS).

Conceptually, it is relatively simple. In reality it is not so easy. There is lots of effort to develop the work required and the resources needed for system. The bigger and more complex the system, the more difficult it is of course.

THE SYSTEM FLOW

The system level flow therefore looks like this:

  • Going from the left to the right we get "these system requirements are going to be satisfied by these systems identified in this System Breakdown Structure (SBS) which are being changed or created by the work in this Work Breakdown Structure (WBS)".
  • From right to left we have "this Work Breakdown Structure (WBS) will transform or create these systems identified in this System Breakdown Structure (SBS) to satisfy or meet these system requirements".

I wish to take a look at the "vertical dimension" next .....through these various levels in this framework.

Comments

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <ul> <ol> <li> <dl> <dt> <dd> <h1> <h2> <h3> <img>
  • Lines and paragraphs break automatically.

More information about formatting options

CAPTCHA
This question is used to make sure you are a human visitor and to prevent spam submissions.
Image CAPTCHA
Copy the characters (respecting upper/lower case) from the image.

Welcome to Knowing Projects

A Place to Explore Project Management Concepts