Sep/090
Making continuous-improvement visible
Continuous-improvement is the cornerstone of many recent innovations in the business world – Shewhart/Deming quality-management, Six-Sigma, Agile software-development, kaizen process-improvement and lean-manufacturing, to name just a few. The mantra of “release early, release often” has been a factor in the success of many Open Source software projects. And there many other important advantages to continuous change: improvements take effect much quicker, feedback-cycles are faster, there’s better engagement on the shop-floor, and so on. When applied well, such improvements echo all the way down to a much-improved bottom-line – whatever the ‘bottom-line’ may take for that enterprise.
Yet though we may need to think side-wise somewhat to spot it, there’s also one important catch to continuous-change. Continuous improvement depends on large numbers of small incremental changes; the smaller the change, the faster that all-important feedback/improvement cycle can run. But in perceptual psychology, small changes are invisible – a change has to be of significant size or occur at a significant before it becomes noticeable In a well-designed continuous-improvement process, often the whole point is that each change should be almost invisible, because it can reduce the stress of change, and allows potentially-challenging changes to be introduced by respectful ‘stealth’ rather than in a single overwhelming ‘big-bang’. But the more that the improvement-process succeeds in that task, the less anyone will notice each change – which means that the change-team may appear to be doing no work at all. Which is not a good career-move…
Worse, if no-one notices the change, and no-one seems to notice it, then perceptions of product or service may be stuck at first-impressions – which may be long out of date. As ITWorld columnist Esther Schindler put it, in her perceptive article “Why Users Dumped Your Open Source App for Proprietary Software“:
One thing that became apparent is that the lack of features is a perception that may have dated from a previous version. That is, “I tried it a few years ago, and it didn’t do what I needed then, so I chose something else… and haven’t thought about adopting the [software program] since.” If someone tried your app three years ago, back when it was all raw edges and bare metal, how will she know that it might be time to re-evaluate the options? … [She] may not realize that the version she can download today is far improved. Unless she goes out of her way to look, how likely is she to find out?
Sometimes the classic ‘big-bang’ Waterfall-style projects seem successful because their long release-cycles mean that the step-change introduced with each new release is large to be noticed. To quote Esther Schindler again:
One attribute of commercial releases is that major feature upgrades are announced with a lot of fanfare. That happens with open source applications that are household names (assuming an appropriately-geek household), but it’s rare.
…which means that some proprietary projects look better because they use a less-effective change-process. Not exactly a desirable outcome…
Part of this is marketing, of course: a big step-change gives a good excuse for an ‘event’ that’s much more noticeable than a quiet, continuous, stolid, ‘steady as she goes’. Yet that is a tactic that’s worth adopting in continuous-improvement processes: invent an ‘event’ of your own, to celebrate change and advertise the improvements that have been implemented since the last ‘event’. That way you’ll make the work more noticeable – and more valued.
There’s a subtle trade-off here. You’ll want every change to be noticed, but if you set the spacing of ‘events’ too close together, not only will the events blur together too much to be noticeable, but you actually run the risk of increasing people’s ‘change-fatigue’. A common practice in open-source software-development is set formal ‘release-events’ at six-monthly or yearly intervals, even though there’ll often be many ‘point-releases’ in the intervening period. Another useful tactic there is to use names rather than numbers to designate each major change.
Some typical themes in a ‘release-event’ might include:
- Summary of key groups of changes – keep this list short, no more than 5-7 items
- Acknowledgement of key people involved in inventing or implementing significant changes
- Linking process-enhancements to key performance indicators at the whole-of-enterprise level
- Celebration of the value of change itself
Keep each change and each change-cycle small enough to enhance improve effectiveness every day; yet also ensure that overall change is large enough to be visible and valued. That’s the balance we aim to achieve here.
Why Users Dumped Your Open Source App for Proprietary Software
Aug/090
Ten ways to fail – and how to avoid them
Success often arises just from avoiding failure. For example, consider the ‘ten commandments for business failure‘ listed by former Coca-Cola CEO Don Keough:
“You will fail if you quit taking risks, are inflexible, isolated, assume infallibility, play the game close to the line, don’t take time to think, put all your faith in outside experts, love your bureaucracy, send mixed messages, and fear the future.”
This list has been used, for example, to summarise current operational and strategic problems in Britain’s National Health Service (though that specific example does perhaps prioritise political point-scoring over practical review). But if we think side-wise, we can also re-use these known ‘anti-patterns’ for failure as pointers to strategies for business success:
Failure #1: Stop taking risks – How do you make it safe for people to take risks? How do your people know when risks are appropriate, and when not? What ‘safe-fail’ fallback mechanisms could you use to enable people to take safer risks?
Failure #2: Be inflexible – All those rules and regulations may seem to give little room for manoeuvre, but there are always some options for choice, for chance, for innovation: what are they? How can you use those chances to enhance your organisation’s ability to adapt to changing business contexts and conditions?
Failure #3: Isolate yourself – Management hidden away in a bunker, no-one talking to anyone else: many corporations have killed themselves that way. What do you do to ensure you know what’s going on, both inside and outside the organisation?
Failure #4: Assume infallibility – Often a problem of arrogance, this one: Enron’s high-flyers famously described themselves as “the smartest guys in the room“. Instead, what can you do to ensure that you follow Cromwell’s Rule, the exhortation of the English Civil War leader and general Oliver Cromwell to “think it possible you may be mistaken”?
Failure #5: Play the game close to the foul line – Enron again provides all too many examples of this, such as its ‘Death Star’, ‘Ricochet’, ‘Fat Boy’ and other scams through which they stole over $11bn by ‘gaming’ the US West Coast electricity market. The short-term gains are invariably outweighed by the long-term losses – or long jail-sentences… So corporate social responsibility isn’t a ‘feel-good’ fad: as Deming, Shell and others have demonstrated, it’s an essential survival strategy, especially in the longer term. We need to be clear about our own business-principles – and stick to them.
Failure #6: Don’t take time to think – In present-day business, the pressure’s always on, always pushing us to do more with less. One of the first things to get sacrificed when it all gets too much is time to think, time to reflect. But if we don’t take the time to think about what we’re doing, and why, we’re likely to find ourselves running full-tilt into a dead-end, powering over the proverbial cliff. Simple techniques such as the After-Action Review can make a huge difference: so by what means can you help shift the mindset from “We don’t have time to do this stuff!” to “We don’t have time to not do this stuff!”?
Failure #7: Put too much faith in outside experts – Often a corollary of Failures #3, #4 and #6: hiding in a corner and using blameable ‘outsiders’ to do our thinking for us… Consultants and contractors do have their roles, especially in helping us avoid falling into ‘groupthink‘, but as Deming also demonstrated, the most important sources of information are usually within the business itself, especially those close to the everyday action. What can you do to to build the right balance between ‘outside’ and ‘inside’? What you do to create an innovation culture within the business?
Failure #8: Love your bureaucracy – Bureaucracies do have a real business function, providing ‘normal’ paths for business communication, to guide, monitor and manage. But whenever we try to use them as a means of control in business, they grow and grow like an out-of-control cancer that kills communication and creativity, and eventually the organisation itself. Direction is real, but control is a myth: it doesn’t exist. So monitor the monitors, cut away all those meaningless measures, kill off pointless reports that no-one reads: rein in that bureaucracy, and never let it grow without a clear, explicit, ‘on-purpose’ business reason.
Failure #9: Send mixed messages – Social networks and increased scrutiny mean that mixed-messages will not only be spotted, but may well be interpreted as ‘playing the game close to the foul line’ – see Failure #5 – with serious impacts on risk and reputation. One of the best ways to keep consistent on message is to be clear about the linkage between vision, role, mission and goal – and to have a clear and meaningful business-vision in the first place!
Failure #10: Fear the future – This one is often the real driver behind other ‘commandments’ to failure, especially Failures #1 and #8. Formal futures techniques such as business scenarios, environmental scanning and causal layered analysis will help to ease those fears – and guide your organisation with what will always be an inherently uncertain future.
How much are you at risk of setting up your business for failure? Turn it round: use this list above to set it up for success.