Search This Blog

26 September 2005

Designing for outcomes

Steven Covey wrote about designing for outcomes in ‘7 Habits of highly successful people’

The idea is that we design for the outcome we want and we end up working towards the outcome. If we design for abstract concepts they are harder to achieve. If we design for a process the process may work, but it might not deliver the results we want to see. Designing for outcomes can also reduce the scope of the problem and can also help remove the problem of specifying solutions when working on the design.

Spending more time on the design early will ultimately save time and cost.

In fact designing for outcomes is also one of the key tenets of the EFQM excellence model, a European quality framework competing against ISO standards. See more about EFQM here

Designing for outcomes seems so self evident that it seems odd to single it out, but many people design their specifications without clearly articulated outcomes in mind. Again, referencing Covey – if designs are oriented towards the outcome, the work will be oriented towards the outcome. This can help a project team keep focussed on what is important, and to prioritise work appropriately.

Many software projects are working on poorly defined problems, so the outcome is not known. Further, many other R&D projects are not trying to solve a specific problem, but just to explore generally. This doesn’t just apply to science, but to any innovation type development. Examples include google-earth and wikipedia –software applications that came before the ability to commercialise the product.

In most projects aligning design with outcomes is appropriate and very useful.

Since beginning this subject I have re-oriented by project (and day to day) planning towards the production of physical deliverables. And I usually start with mocking up a draft of what the document will look like before I get into the details.

(And I just saw a preview of the new Microsoft Office suite where in looks like the design for outcomes principle has become the foundation of the user interface.) Problems that people can encounter when designing for outcomes is designing work for the wrong outcomes. It’s important that the specifications address the (business) problem at hand, rather than addressing perceived or ancillary problems.

I hear a mantra from a manager years ago whenever I think about this topic; “Specifications talk about the need, not the solution.” Sometimes it takes skill to separate the two.