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):
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