“Planning has rapidly diminishing returns: plan less, do more, learn more, redesign governance to kill early and often.”
Happy new year! – There is always a special responsibility that comes with the first blog post of a new year. Fortunately Tom Cagley of SpamCast fame asked me a fantasy question:
If there is one piece of advice you would give to CxO executives what would it be?
There is plenty of advice I’d like to give them, but one piece of advice?
One piece of advice which is generic and cuts across industry upon industry. One piece of advice for all those companies I know nothing about.
Tough. When I eventually came up with my answer I knew I’d have to explain it.
I had to think long and hard. I knew immediately that it would be something on the continuous digital theme.
Eventually I came up with this:
“Planning has rapidly diminishing returns: plan less, do more, learn more, redesign governance to kill early and often.”
I believe this is universally true. Plan anything for long enough and you will eventually plan your way out of doing anything. When I run my Extended XP Game I regularly see teams plan their way out of good approaches to work.
Some planning adds a lot of value. But the rate of learning slows and continues to slow. At some point you aren’t learning more at all, and sometime after that your learning is counter productive. As economists say: there are diminishing returns on the investment.
A little planning adds a lot of value. But each extra minute of planning adds less value than the previous minute. Plan a little, do a little.
In our modern technology driven world two factors make this especially true.
One: learning by doing is faster with modern technology
Technology has advanced: Moore’s Law means I have over 100 times as much power in my MacBook Air as I did in the 6502 BBC Micro I learned to program on in the 1980s. That in turn had more power than the IBM Mainframes of the late 1960s.
That means our tools are more powerful: the Python I programme in today isn’t the most powerful language but it is a damn site more powerful than 6502 assembler and BBC Basic. Add open source libraries and that Python is immensely more powerful than writing in 1960s COBOL.
As a result things that tool months or years to create take hours and days. A week of planning for a OS/360 COBOL program that will take 6 months to write makes sense. A week of planning for a Python program I’ll have running in the cloud by the end of next week doesn’t.
And when I say planning I mean all aspect of planning: research, requirements, schedules, architecture designs and the rest.
Sure a bit of planning makes complete sense. I would be stupid not to make a coffee and think about what I was about to do. But planning is all about learning, is about experiencing the future a little bit. The power of our tools today means that future is a lot closer, and the most rapid way to learn about it is to create it.
Once I reach that future it makes sense to stop, review and plan again. The quickest way to learn is to alternate thinking (that is “planning”) and action (learning by doing.) Do something, see what works, then take time to reflect and learn.
Doing is learning too. The question at any given point is: what is the fastest way to learn? In the beginning that is planning, very soon doing becomes faster.
Two: cost of delay changes everything
Once you appreciate cost of delay you see the world differently (If you don’t know cost of delay look at my Time-Value profiles.
Now remember: planning time is time, planning delays launch. Keep planning, analysing, talking to potential customers, drawing imaginary project plans or perfecting your architecture (before you start building) all delays the time you will get a product into the market.
That delay is bad because it increases risk: until your product is in the market you are at risk of creating a product nobody wants, or at least nobody will pay for.
That delay means your product will earn less money – thats cost of delay. Potential customers may have found other solutions, competitors may have got there first, or technology advances may render your product obsolete.
Lets be straight: I’m not saying No Planning. A little planning can be really really useful and valuable. So please plan!
What I am saying is: plan a little, do a little. Repeat.
Then stop, reflect, evaluate, and plan a little more before you do a bit. Alternate planning and doing. I’m not original in saying that, the Shewhart cycle (i.e. the Deming cycle or PDCA), says the same and so do half a dozen other approaches.
The problem is: many executives have been taught to plan plan plan. Nobody ever gets in trouble for planning too much and most failures can be traced back to a failure to plan more if you try hard enough. Ultimately, if you plan enough you will never have any failures because you will never do anything.
Which brings me to the last part of that executive advice: “redesign governance to kill early and often.”
Organizational governance is overwhelmingly based on the assumption that we know what we are doing. Only things that are very well understood will be allowed to start. That incentivises people to plan plan plan. And when something does get started there is a bias against closing it down (inertia and commitment escalation).
That needs to change. Since we can’t know in advance we need to be able to react once work is in flight.
Organizations need to be prepared to start work where the outcome is vague. Governance then needs to kill initiatives which aren’t showing promise. Put it another way: the early stage gates need less rigorous and the later ones more rigourous. If governance isn’t killing initiatives often then either governance isn’t working or you aren’t taking enough risk.
Published on Java Code Geeks with permission by Allan Kelly, partner at our JCG program. See the original article here: Plan less, do more Opinions expressed by Java Code Geeks contributors are their own. |
