I've been asked can I simplify the getting stuff done example further. If you want to keep it very simple then think in these terms.
Observe
Step 1 - User Needs!
Step 2 - Value Chain!
Step 3 - Map it!
The first part of mapping is to improve situational awareness i.e. it's useful to have some in the first place. No, when you've written a map that's not the end because maps are dynamic and will change over time.
Orientate
Step 4 - Challenge!
Step 5 - Adjust!
The second part of mapping is to challenge what we think the situation is, remove duplication and bias. This involves sharing maps with others, refinement (including metrics where needed) and adding in aggregate perspectives (our own historical repository of how we treat things).
Decide
Step 6 - Think!
Step 7 - Methods!
Step 8 - Simple!
Step 9 - Evaluate!
The third part of mapping is to decide to do something, the strategic play, how we're going to do it, how we're going to organise it. The last bit - evaluate - is usually to create those evaluation artefacts (SWOTs, BMC) that others seem to sometimes require in order to bring them along. It can be useful but often I find that last step unnecessary, time consuming and often omit it.
Act
Step 10 - JDFI
The last bit of mapping is to get on with it, get started. This is not the end of the story though, you have to continuously iterate all the above.
Yes, this is John Boyd's OODA loop but then it's probably the only truly universal technique that I've found useful. To get started, plan to spend a couple of days at most to get to the ACT part. Yes, you'll need to iterate (update maps with new user needs, changes in the environment etc) and alter your strategic play but then this should be much faster than the first loop.
Oh, and your repository of knowledge, your store of what worked and what didn't is your maps - so don't lose them. They become essential as part of orientating around any change.
