A Defence Capability Framework (04) - Operational

The operational level is much more defined than the strategic level. But ...there is limited use of the concept of FIC (Fundamentals Inputs to Capability) in the capability context (I will explain FIC later). FIC is used mainly in the "preparedness" context. Which is a shame really, because the data actually exists, it just isn't used, yet it could be so useful in the capability development context.

Program Framework - Defence

REQUIREMENT

The requirement at the operational level is encapsulated in what is called an Operational Concept Document (OCD). It articulates the war fighting processes for multiple scenarios and consolidates those into a requirements set. I think there is a way to go to get it right, but nonetheless, it is what has to be used.

It should use already developed doctrine such as the Army Tactical Task List or its Joint equivalent (can't think of its name right at this moment) as a start point. Unfortunately, because the production of the Operational Concept Document (OCD) is often done by consultants external to Defence the content is often made up of what a good military friend of mine (thanks Bob) calls MSUs (where MSU stands for "Make Shit Up"). Flippant though this is, Defence spends a small fortune to either have doctrinal stuff reinvented or for consultants to quote Defence's doctrinal stuff back at them.

I discuss the Operational Concept Document (OCD) and other elements in the process in much more detail in a later set of blogs.

SOLUTIONS

The solutions within the operational level are the FIC (Fundamental Inputs to Capability), or at least they should be! Now FIC is a categorisation of Solutions .......generally. I say generally, because it isn't really the case in a pure sense. A solution in my Project Knowledge Model (PKM) should be a real world object or an artefact - a man made object. FIC though contains a number of fairly self-explanatory categories including:

  • command and management,
  • organisations,
  • major systems,
  • personnel,
  • supplies,
  • support,
  • facilities, and
  • collective training.

Other countries have similar categorisations and approaches.

The problem is that FIC are a mix of things and functions and combinations of the same things. For example I have struck in the past the "double accounting" effect, where a number of FIC elements are actually included in more than one FIC category. Another issue is that an item such a "collective training" is not a thing - it is more of a function than a thing. Accordingly, there is an inconsistency in the categorisation.

You may recall that in A Defence Capability Framework (03) - Strategic, I said:

.....there is rarely a sort of "rubber on the road" approach where the end result of all those discussions and papers and presentations is placed into a database to evolve as the Defence Force evolves.

Well, if you have data elements that are entered twice (the double accounting effect) or can be confused in their categorisation, then maintaining them in a database is problematic. There is likely a need for a fair bit of "data cleansing" in the first instance! Not that this is an excuse for NOT doing it.....and it isn't done ....maintained in a database that is.

VEHICLES OR PROCESSES

The data here is pretty complete. It is in fact the list of all projects in the Defence Capability Plan. But ......the Defence Capability Plan is actually just those projects over AUD$20m in value. There remain many projects under that value that don't necessarily appear. These are managed under the various "Minor Project" programs.

But these minor programs can certainly impact FIC and ultimately Capabilities. So why leave them out in the overall consideration? I don't know why but have wondered about that for a long time and questioned it on many occasions.

Having said that though, indirectly the minor programs are taken into account but at a single service (Navy, Army Air Force, CIO, etc) level rather than at a whole of Defence Capability level. This means there is a chance of duplication, of mis-accounting issues of capabilities/FIC and of simply not recognising the whole capability in decision making process.

THE OPERATIONAL FLOW

So... the operational level flow goes broadly like this:

  • Going from the left to the right we get "these operational requirements or concepts are going to be satisfied by these Fundamental Inputs to Capability (FIC) which are being changed or created by these major and minor projects".
  • From right to left we have "these major and minor projects will transform or create these Fundamental Inputs to Capability (FIC) to satisfy or meet these operational requirements or concepts".

It isn't a perfect system ....but it works more or less. Next we need to look at the system level.

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