February 4, 2016 | Written by: John Palfreyman
Categorized: Defence & Intelligence
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.
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.
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.
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:
- IBM Design Explained
- Kelley; Creative Confidence ISBN 978-0-00-751797-8
- Why IBM Design Thinking? Short Video