‘Speed to Capability’ – what’s that about?
It’s about sensible speed and effective capability
Gregor Ferguson, Ph.D
The phrase ‘speed to capability’ is being thrown around a lot, partly as a reaction to perceptions that Defence is far too slow to get anything into frontline service.
There’s some truth in that: Defence has created a capability development and acquisition system that is notoriously risk-averse and therefore very slow to make decisions – indeed, to do anything at all.
‘Speed to Capability’ represents the antithesis of this: a quick search for a good answer to whatever the question might be, and then a rapid entry into service. Risky, yes, and probably asking for some additional work down the track to refine the capability concerned. But in Australia’s deteriorating strategic environment having ‘good enough’ tomorrow may be more important than waiting for ‘perfect’ next week.
The term speaks to one purpose of innovation: to help an operator respond quickly and possibly asymmetrically to emerging threats or to seize opportunities as they appear.
Before going further I should add that Ms Lesley Seebeck, in Strategic Analysis Australia, described the language of innovation and speed to capability here – I’d suggest that everybody read what she says. And the reasons why Defence is risk-averse are discussed at the very end of this article.
‘Speed to Capability’ was one of the most important factors in one of the papers I read while studying for my Ph.D in defence industry innovation at the University of Adelaide. The paper, titled ‘Identifying Critical Success Factors in Defense Developmental Projects: A Multi-Variate Analysis’, was written back in 1996 by a group of Israeli researchers led by Asher Tishler.
By definition, developmental projects are inherently risky and involve either the integration of existing and new products in a new way for a new application, or the development of all-new products – and sometimes a combination of both, the authors say.
Based on their analysis of 110 Israeli defence projects, they identified eight factors bearing heavily on the success of a developmental defence project. In descending order of importance these are:
1. A sense of urgency - the more urgent the need, the greater the chance of success
2. The professional qualifications, sense of responsibility for project outcome and continuity of personnel appointments within the customer ‘team’
3. Pre-project preparation, including proving technological feasibility and establishing the correct project structure
4. Quality of the project development team, and of its leader
5. Organisation culture within the project team, encouraging professional growth
6. Design policy of the developing organisation - a clear policy on decision-making procedures and communications
7. Design considerations in the early phases of the project – design to cost, reliability, ‘produceability’
8. Systematic use of schedule, budget and performance management tools.
It’s interesting that the most important factor is speed and urgency and that the second factor was all about the customer’s competence. Indeed, factors two, three and four validated my own research findings about managing risk.
A sense of urgency is vital – everything irrelevant to the project’s outcome gets pushed aside: process takes second place. But that’s still no reason to rush at a problem like a bull at a gate.
Communication remains important: regardless of the acquisition process adopted, the operator (or end user) needs to be able to speak plainly with the innovator so that the operator gets a sense of what is realistically possible, and when, and so that the innovator understands the operator’s problem correctly.
The analogy I use dates from Word War 2 because there’s nobody still alive to be offended. In about 1943 an officer in Combined Operations HQ in London approached the scientific adviser, Professor JD Bernal, and asked quietly if he could help develop a hand-held echo sounder.
The professor said it could probably be done, but he wanted to know why Combined Operations needed such a thing? After a lot of humming and hawing and guilty looks over his shoulder the officer swore Professor Bernal to secrecy.
Combined Operations was the body charged with mounting raids on enemy-held coastlines and with developing the techniques for a successful amphibious assault in Europe – essentially for ensuring that D-Day actually succeeded. As part of its preparation for this assault it was surveying beaches along every stretch of Europe’s enemy held coastline, from Denmark to the Pyrenees. The hand-held echo-sounder was needed, the officer said, to help determine how steeply a beach shelved.
Professor JD Bernal practically invented the science of beach deduction. His response to the officer was two-fold: firstly, Combined Operations were going about measuring beach gradients the wrong way; and, secondly, if you can pierce the veil of secrecy (or secretiveness) and ask a subject matter expert the right question you get a much better answer – determining the right question is part of the process of communicating.
One solution to the measurement problem was to simply ‘jettison’ a bomb over the beach at high tide and deduce the beach gradient from photos of the resulting crater - there were allied bombers flying over the coast every day en route to and from targets inland so a ‘damaged’ aircraft jettisoning a bomb wouldn’t arouse enemy suspicions. A variation of this technique was used to identify solid paths through which mine-clearing vehicles could clear safe routes off the beach for tanks and heavy vehicles.
This technique was much safer and quicker than Combined Operations’ then-standard practice of sending small boats across to an enemy coast on a dark, moonless night, then risking the life of a volunteer diver who had to go ashore with an augur, collect a sample of sand and whom, if he was captured, might compromise the entire invasion and certainly compromise that particular beach.
Communication between the customer and innovator is therefore vital: when speed to capability matters there’s no time for an arm’s length relationship brokered by well-meaning people whose focus is merely process. As I said earlier, it’s important that the operator gets a sense of what’s realistically possible and in what time frame; it’s also important that the innovator understands the operator’s real problem, not somebody’s (possibly flawed) interpretation of it.
And it’s important that the innovator takes the end user’s possible ignorance into account.
Henry Ford is reported famously to have said, “If I asked people what they wanted, they’d have said a faster horse.”
Ford gave people the horseless carriage instead, but he didn’t actually say that. What he said was, “If there is any one secret of success, it lies in the ability to get the other person’s point of view and see things from that person’s angle as well as from your own.”
Canadian researcher Robert Cooper put some numbers on this: he determined that new product strategies fall into five types and one of the worst-performing was the strategy that merely listened obsessively to the customer and then tried to do what the customer said: people who try to engineer a faster horse, essentially.
The lesson of his research was: listen to the customer but take what he says with a pinch of salt because he may not know what he doesn’t know. Come to that, nor do you. So, communication is a vital part of achieving the necessary speed to capability, as is scepticism.
Elsewhere, in Project NewProd, Cooper examined no less than 195 new product programs and identified three major determinants of new product success: product uniqueness and superiority; market knowledge and marketing proficiency; and technical and production proficiency – in that order. Projects which scored highest on those three had a 90 per cent success rate; of the projects that scored lowest on this scale, only 7 per cent were successful.
Cooper also made an important discovery: even projects that lacked both marketing and technical prowess still achieved a 62 per cent success rate when they were based on what was classified as a unique, superior product.
So the lesson is clear: product is the critical variable. A new, superior product, delivered quickly – genuine speed to capability – will deliver at the very least some of the advantage you’re looking for. Your customer will probably help you define it, and even develop some of it, so listen to what he says. But he may also hinder you - so test what he says as well!
This is one big challenge for Defence’s Advanced Strategic Capabilities Accelerator (ASCA) and Capability Acquisition and Sustainment Group (CASG), which will be charged with delivering speed to capability.
Another will be cutting through generations of cultural resistance. In particular, CASG will need to deal with a culture of parliamentary blame which sees Ministers and senior officers and officials afflicted with ‘Gotcha’ calls that interrupt the genuinely good work carried out by the Senate’s Foreign Affairs, Defence and Trade Committee.
That culture has resulted in successive overlays of regulation on defence acquisition and the expenditure of public funds, incredible risk-aversion and a deep reluctance to make decisions.
And of course, not every threat is a short-term one. While we need more capability quickly right across the ADF, the medium and long-term threats will still confront us in the medium and long term. So, we will still need new warships, nuclear-powered submarines and 6th generation air dominance systems, all of them selected and acquired in a more considered way.
But elements of these new systems will also need incremental upgrades, often at short notice, so any mechanism that enables us today to deliver speed to capability – that is, sensible speed to effective capability – needs to be nurtured, refined and exercised constantly, and for ever.
That’s going to be the challenge for ASCA, CASG 2.0 and the people who will work for them.
Cyber Communicator I Co-Founder Murfin Group I AI Product Creator/Trainer
8moThere is an amazing Australian company Chaos1 delivering this right now David Pembroke.