I spend my time flitting from organisation to organisation, across many different sectors, and looking at often quite different challenges. Technology is usually the linking thread, although not always.
A question that I’m not hearing being asked in a structured way in organisations today is “Which approach should we be taking?”. What instead seems to happen is that organisations have either tied themselves to the agile mast and claim that everything is agile, even though if you lift the cover you’ll find things that look remarkably like waterfall projects, or alternatively you’ll find companies that haven’t moved to agile but have got pockets of agile stuff going on where the motivation is there to do so (not necessarily where it is most appropriate).
No matter which case exists, financial approval processes will invariably expect descriptions of known outcomes and benefits and exact budgets from day one, which in turn is about as agile as a marble statue concreted into the support pillar of a motorway intersection.
So what approaches should be being taken? Agile is not the answer to every problem. Nor is waterfall. And there are other approaches available too. So, just because I’m a sucker for a 2×2, here’s a way of looking at it…
It’s a kind of Rumsfeld analysis of scenarios on the basis of level of understanding of both problems and solutions.
The top right, Known Problem, Known Solution is the type of scenario that it seems to me most financial control processes expect The World to work to. If you are building a house or opening a new shop or installing a network, you can be fairly sure that you can know what you want (although to what degree of granularity is open to question), and also be fairly sure that it’s a path well enough trodden, that a plan can be drawn up in advance which will be accurate enough to be useful.
Where you know what your problem is, but you don’t know what the answer is, agile will give you the best options. Agile processes (or service design approaches) might well make you realise that you didn’t know the problem as well as you first thought. That’s not a bad thing. If you don’t know what the solution is, the best you can do is to understand what the problem is worth and then cut your investment costs accordingly.
Unknown problems and unknown solutions are where organisations (in my opinion) need to up their capability. This quadrant is where you explore the possibilities of new technologies. You should invest here on the basis that the main outcome will be increasing the organisational capability to deal with emerging innovation and ambiguity. Something else useful might emerge, but that shouldn’t be the main objective. Things like accelerator programs fall into this category.
Finally, known solutions to unknown problems are a terrible way to frame things. I’m hearing a lot of these at the moment in the context of “Blockchain” or “AI”. These are types of technology, not answers or solutions per se. Reframe the scenarios in one of the other quadrants (probably one where the solution is actually unknown).
6 thoughts on “Which path to take?”
Unfortunately, quite a lot of the projects in the Business Unit I’m currently in are phrased and discussed in terms of Know Solutions to Unknown Problems (WTF?).
They know (think) they need to Do A Thing and they know how they want to do it but they’re not clear (to me and, as far as I can tell, many of my colleagues) what it is they want to achieve or how achieving something in that space is directly and tangibly linked to delivering on their mission as a whole. (i.e. what problem they’re solving and for who and why.)
The overall mission is quite open: a target by a time. I feel that not much analysis has been done (or communicated) about how they expect to get there or why they expect to get there with these proposed solutions. Especially difficult are how the timelines for the solutions (long) fit into the timelines for the KPI target (short-ish). They know they need to be there so they just want to try things in ways they’ve already decided in the hope that it will somehow solve their problem.
I’m not sure how (or with what likelihood) they expect these bets to pay off but as a Synthesist and a Technical Architect I find it very frustrating. As an Architect I’m frustrated that I’m being asked to critique adhoc solutions from non-technical people rather than offering appropriate solutions to meet a set of needs. As a Synthesist I’m frustrated because without knowledge of the bigger picture, or the ability to contribute to a story about the bigger picture, it’s difficult to know how all the pieces are intended to link together so that they work together to meet a set of needs.
Anyway, I think that’s enough therapy for me; thanks Matt! 🙂
Glad to be of help!