Defence & Intelligence

Avoiding “Ready – Fire – Aim” with Design Thinking

Too many projects fail because the problem is not thoroughly understood, and the objectives made clear before the solution is finalised. Often referred to by my friends in the military as “Ready – Fire – Aim”!

I almost succumbed to this earlier in my career. I was the new leader of a recently acquired German subsidiary to a UK company. After a visit by the UK Director of Quality, I was instructed I should lift the mature, well-documented UK QA systems and implement them in the German subsidiary.

Being acutely aware of the cultural challenges that this solution would cause, I “reverse engineered” the objective as “Build a local German QA system that is as good as or better than the UK system in the next 30 days”.

We convened a task force of German engineers, used the UK systems as an exemplar, and built a local QA system under the watchful eye of the UK Director of Quality as our “Customer”. This solution met the objective, and more importantly was fully owned by the local engineering team and UK Director of Quality.

OK so what’s this got to do with Design Thinking? IBM is not alone in the Industry in looking to Design Thinking to improve the usability of our products and solutions at all stages of their lifecycle. There are many excellent texts that describe this approach better that I can (see the References section at the end) but one of the tenants of our approach is to only move to candidate solutions once the objectives are clear.

DT Overview

Figure 1 – IBM Design Thinking Overview 

We do this by looking at the problem from the viewpoints of key users – analysing their perspectives, wants and needs and how they interact with their current work tasks. We then map out how the users are doing their job now, and through identifying inefficiencies, redundancies, missing steps and disconnects we can start to surface ideas for new solutions.

After prioritising these ideas using the grid shown in Figure 2, we take the top three and start expanding these into Hills. A Hill is Design Thinking term for (military) Commander’s Intent. Hills WHAT needs to be done, by WHEN but not HOW.

Best Bets

Figure 2 – Choosing the Best Bets 

The Hill sets out what will “wow” the user, focusing on his or her business task. Examples of good & bad Hill descriptions are shown in Figure 3.  A few well-formulated Hills will ensure that we can now focus on candidate solutions after thoroughly understanding the problem from the user’s viewpoint.

Good Hill - Bad Hill

Figure 3 – Bad Hill / Good Hill (from IBM Internal Project)

As Hills are progressed, the user centric approach continues. The solutions will be thoroughly tested and refined with our customer and through peer review before moving on to a first prototype followed by incremental agile development.

Agree, disagree, disinterested?  I’d much appreciate an active debate on this topic!  Contact me through leaving a comment, twitter or LinkedIn!

References & useful material:

  1. IBM Design Explained
  2. Kelley; Creative Confidence ISBN 978-0-00-751797-8
  3. Why IBM Design Thinking? Short Video

Director - Blockchain | National Security - CTO Team Europe

More stories

Does Taking the Long View Help?

Traditionally, U.S. federal agency plans last the length of a four-year presidential election cycle. But many challenges facing government are on a much longer cycle – such as building Defense weapon systems, adapting to climate change, and creating energy independence. In 1996, Congress mandated the Defense Department to conduct a “quadrennial defense review” (QDR) of […]

Continue reading

Defense Offsets – Obligation or Opportunity?

The Global Offsets and Countertrade Association (GOCA) conference just concluded in Montreal.  You may ask, “What is an offset and why is it important?”   Defense offset agreements are arrangements in which the seller of a product or service agrees to provide benefits such as buying local products or services from a country as an inducement […]

Continue reading

Predictive Maintenance – or, “Spend less, do more”

As a former submarine commanding officer and later as the US Navy admiral responsible for all submarine engineering, maintenance and certifications, I can assure you that I was a firm believer in making sure equipment worked correctly.  There was no margin for error, and the goal was always to make sure that the number of […]

Continue reading