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.  ....read more

Johansson, F., The Medici Effect: Breakthrough insights at the Intersection of Ideas, Concepts and Cultures, Harvard Business School Press, Boston, 2004

Johansson has produced an interesting story here. It's interesting because it is provides a thesis (perhaps the wrong word) on how and perhaps why, innovation occurs or why some people are able to gain breakthrough insights and others not. It's not an academic text, but it does have a "folksy" type of appeal with its stories and approach, which kind of makes me feel that it doesn't have that "robustness" to make it a real solid contribution, although I also suspect many will find it useful. It is all a bit lightweight and has a "guru" type feel to it that always makes me a bit suspicious of the validity of some of the insights.

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.  ....read more

The strategic level is a bit of an enigma in the Defence environment. The strategic terminologies are used frequently and there is much discussion around strategic subjects and many presentations made. But .....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. I capture some of these issues below.

The horizontal dimension is about understanding the basics of how an effort to change an organisation needs to progress (see Organisational Program Framework (01)). Just to remind you I have repeated the "3 Spaces" below.

In this series of blogs, I wish to continue my discussion around the Project Knowledge Model (PKM) big picture, into what I have called the Organisational Program Framework or Organisational Portfolio Framework. But this time in a context - the Australian Defence context. Hopefully, it is then relatively easy to place this into any other government or corporate context. If you wish to see the generic view of this approach please go to Organisational Program Framework (01), Organisational Program Framework (02) and Organisational Program Framework (03).

To continue with the Project Knowledge Sectors discussion from Project Knowledge Sectors (01). From these Knowledge Sectors we can now derive an understanding of the overall Project Knowledge Model (PKM) and how it "flows" together no matter whether it is the Vehicle or the System.

In my blog The Project Knowledge "Elephant" (02) I said:

If we accept that "knowledge" of the system and vehicle, and so the project, is essential to a successful project, then we can start to get a better understanding of a project by looking at what "knowledge" is required.

For this I use what I call the Project Knowledge Model or PKM and I am going to explore some of its broader concepts in this next series of blogs.

I wish to start that explanation of the Project Knowledge Model (PKM) here in this blog.

Camrass, R. and Farncombe, M., Atomic: Reforming the Business Landscape into the New Structures of Tomorrow, Capstone Publishing Limited, UK, 2004

Atomic attempts to identify the future business construct based upon trends identified today. Camrass and Farncombe take the analogy of an "atom" that can become part of larger molecules to form value adding business structures. These are more agile and focused organisations than the monolithic businesses today.

When it comes to "seeing the elephant", it is best to see the elephant early rather than late such as in the "big bang" approach to requirements definition and system development. If you don't see the elephant early then you need to have mechanisms that permit you to quickly respond to the elephant as you see it. This is epitomised by the agile software development processes.