Peeling the problem onion - caution, there will be tears

Matt introduces a new concept he's been reflecting on - the problem onion​.

It's been a couple of months since I attended the 2016 Australasian Evaluation Society (AES) Conference with my colleague, Dan Healy (no relation!). We presented three sessions between us and, overall, I think they went pretty well.

I find that it can always be valuable to reflect on these types of experiences to see what you can learn and, hopefully, improve on. This post is not about the sessions we presented, but rather a reflection across the whole conference on something I have affectionately titled the 'problem onion'.

The problem onion is a conceptual image that I have settled on as a good way of thinking about designing programs and projects. Particularly nowadays many of the 'easy wins' have been won - so we now have this blurry amorphous soup known as 'complexity' (or wicked problems) to deal with.

The problem onion is a simple three stage process that I have seen emerge from several projects (and heard about from several others at the AES Conference):

1. A problem is seen/identified at the start, a project or program is designed in response
2. Once delivery starts you see that the problem is actually not the same as what it was at the beginning - maybe it changed, or was just plain wrong
3. By the end, you have identified the real problem. You might have found some good outcomes, but the core issue still exists.

This is not to say this is universal - simply something I have observed over the last few years. Instances where the problem onion (and accompanying tears) are avoided is when its carved up early.

The use of approaches such as human centred design, evaluative thinking and just plain critical thinking (i.e. is this really a problem in the way that I am assuming) are crucial to dicing up the problem onion and getting those tears out of the way early.

Design and evaluation methods are crucial to this - so I encourage you or anyone you know to think early about how you design and what your design is based on. Many of the complex problems we face are ones I think we can all agree need solving.

Matt Healey, Consultant
​E: matt@fpconsulting.com.au