<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Thinking side-wise &#187; pattern</title>
	<atom:link href="http://sidewise.biz/tag/pattern/feed/" rel="self" type="application/rss+xml" />
	<link>http://sidewise.biz</link>
	<description>A side-wise view of business and the enterprise</description>
	<lastBuildDate>Sun, 18 Sep 2011 08:26:56 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
		<item>
		<title>The other iceberg effect</title>
		<link>http://sidewise.biz/2011/01/the-other-iceberg-effect/</link>
		<comments>http://sidewise.biz/2011/01/the-other-iceberg-effect/#comments</comments>
		<pubDate>Sun, 16 Jan 2011 22:44:57 +0000</pubDate>
		<dc:creator>TomG</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[business]]></category>
		<category><![CDATA[change]]></category>
		<category><![CDATA[complexity]]></category>
		<category><![CDATA[economics]]></category>
		<category><![CDATA[futures]]></category>
		<category><![CDATA[iceberg effect]]></category>
		<category><![CDATA[pattern]]></category>
		<category><![CDATA[sustainability]]></category>

		<guid isPermaLink="false">http://sidewise.biz/?p=174</guid>
		<description><![CDATA[Everyone knows about the Iceberg Effect &#8211; that there&#8217;s usually a lot hidden beneath the surface. But what about its corollary, the Other Iceberg Effect? Because if only one-tenth of something is visible, and the rest of it is floating beneath the surface, the whole thing tends to rise up when some of the top [...]]]></description>
			<content:encoded><![CDATA[<p>Everyone knows about the Iceberg Effect &#8211; that there&#8217;s usually a lot hidden beneath the surface.</p>
<p>But what about its corollary, the Other Iceberg Effect? Because if only one-tenth of something is visible, and the rest of it is floating beneath the surface, the whole thing tends to rise up when some of the top is cut away. Or, equally, the visible part will shrink slightly &#8211; more accurately, sink slightly &#8211; if part of the subsurface portion erodes or melts away.</p>
<p>The first part of the Other Iceberg Effect can give the dangerous delusion that a resource is sustainable, self-renewing. As we cut away some portion of the top, look! &#8211; there&#8217;s still plenty more! The level has risen again &#8211; it&#8217;s almost the same as before!</p>
<p>But it&#8217;s that &#8216;almost&#8217; that should give us the clue that something&#8217;s not right here&#8230; Another clue is that the shape of the periphery &#8211; the visible boundary of the resource &#8211; will often change as the iceberg rises: so if the boundary seems to change as we extract a resource, watch out&#8230;</p>
<p>If we don&#8217;t heed the warning, we&#8217;re likely to keep on going, keep on extracting this &#8216;self-renewing&#8217; resource &#8211; until suddenly, and supposedly without warning, the resource vanishes, and we&#8217;re left floundering in deep water instead. Because what&#8217;s happened is that each time we&#8217;ve removed that top layer, yes, the level has almost returned back to where it was &#8211; but to do that, the whole iceberg has risen in the water. And eventually there&#8217;s no more iceberg left&#8230;</p>
<p>So watch out for those two warning-signs:</p>
<ul>
<li>a resource that <em>almost</em> replenishes itself as we use it</li>
<li>a periphery that changes its shape as we use the resource</li>
</ul>
<p>There are many, many resources that are like this: a company&#8217;s reputation, for example. And in each of those cases, if we don&#8217;t watch out for those warning-signs, don&#8217;t be surprised if we suddenly find ourselves in deep water &#8211; or worse&#8230;</p>
]]></content:encoded>
			<wfw:commentRss>http://sidewise.biz/2011/01/the-other-iceberg-effect/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Making continuous-improvement visible</title>
		<link>http://sidewise.biz/2009/09/make-improvement-visible/</link>
		<comments>http://sidewise.biz/2009/09/make-improvement-visible/#comments</comments>
		<pubDate>Sun, 13 Sep 2009 11:06:06 +0000</pubDate>
		<dc:creator>TomG</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[anti-pattern]]></category>
		<category><![CDATA[business]]></category>
		<category><![CDATA[change]]></category>
		<category><![CDATA[change management]]></category>
		<category><![CDATA[continuous improvement]]></category>
		<category><![CDATA[innovation]]></category>
		<category><![CDATA[pattern]]></category>
		<category><![CDATA[sidewise]]></category>

		<guid isPermaLink="false">http://sidewise.biz/?p=132</guid>
		<description><![CDATA[Continuous-improvement is the cornerstone of many recent innovations in the business world &#8211; Shewhart/Deming quality-management, Six-Sigma, Agile software-development, kaizen process-improvement and lean-manufacturing, to name just a few. The mantra of &#8220;release early, release often&#8221; has been a factor in the success of many Open Source software projects. And there many other important advantages to continuous [...]]]></description>
			<content:encoded><![CDATA[<p>Continuous-improvement is the cornerstone of many recent innovations in the business world &#8211; Shewhart/Deming quality-management, Six-Sigma, Agile software-development, <em>kaizen</em> process-improvement and lean-manufacturing, to name just a few. The mantra of &#8220;release early, release often&#8221; 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&#8217;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 &#8211; whatever the &#8216;bottom-line&#8217; may take for that enterprise.</p>
<p>Yet though we may need to <em><strong>think side-wise</strong></em> somewhat to spot it, there&#8217;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, <em>small changes are invisible</em> &#8211; 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 &#8216;stealth&#8217; rather than in a single overwhelming &#8216;big-bang&#8217;. But the more that the improvement-process succeeds in that task, the less anyone will notice each change &#8211; which means that the change-team may appear to be doing no work at all. Which is not a good career-move&#8230;</p>
<p>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 &#8211; which may be long out of date. As <a title="ITWorld online journal" href="http://www.itworld.com/" target="_blank">ITWorld</a> columnist <a title="Esther Schindler on Twitter" href="http://twitter.com/estherschindler" target="_blank">Esther Schindler</a> put it, in her perceptive article &#8220;<a title="Esther Schindler - Why Users Dumped Your Open Source App for Proprietary Software" href="http://www.itworld.com/open-source/77409/why-users-dumped-your-open-source-app-proprietary-software" target="_blank">Why Users Dumped Your Open Source App for Proprietary Software</a>&#8220;:</p>
<p style="padding-left: 30px;">One thing that became apparent is that the lack of features is a perception that may have dated from a previous version. That is, &#8220;I tried it a few years ago, and it didn&#8217;t do what I needed then, so I chose something else&#8230; and haven&#8217;t thought about adopting the [software program] since.&#8221; 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? &#8230; [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?</p>
<p>Sometimes the classic &#8216;big-bang&#8217; Waterfall-style projects seem successful <em>because</em> their long release-cycles mean that the step-change introduced with each new release is large to be noticed. To quote Esther Schindler again:</p>
<p style="padding-left: 30px;">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&#8217;s rare.</p>
<p>&#8230;which means that some proprietary projects look better <em>because</em> they use a less-effective change-process. Not exactly a desirable outcome&#8230;</p>
<p>Part of this is marketing, of course: a big step-change gives a good excuse for an &#8216;event&#8217; that&#8217;s much more noticeable than a quiet, continuous, stolid, &#8216;steady as she goes&#8217;. Yet that <em>is</em> a tactic that&#8217;s worth adopting in continuous-improvement processes: <em>invent</em> an &#8216;event&#8217; of your own, to celebrate change and advertise the improvements that have been implemented since the last &#8216;event&#8217;. That way you&#8217;ll make the work more noticeable &#8211; and more valued.</p>
<p>There&#8217;s a subtle trade-off here. You&#8217;ll want every change to be noticed, but if you set the spacing of &#8216;events&#8217; too close together, not only will the events blur together too much to be noticeable, but you actually run the risk of increasing people&#8217;s &#8216;change-fatigue&#8217;. A common practice in open-source software-development is set formal &#8216;release-events&#8217; at six-monthly or yearly intervals, even though there&#8217;ll often be many &#8216;point-releases&#8217; in the intervening period. Another useful tactic there is to <em>use names rather than numbers</em> to designate each major change.</p>
<p>Some typical themes in a &#8216;release-event&#8217; might include:</p>
<ul>
<li>Summary of key groups of changes &#8211; keep this list short, no more than 5-7 items</li>
<li>Acknowledgement of key people involved in inventing or implementing significant changes</li>
<li>Linking process-enhancements to key performance indicators at the whole-of-enterprise level</li>
<li>Celebration of the value of change itself</li>
</ul>
<p>Keep each change and each change-cycle small enough to enhance improve effectiveness every day; yet also ensure that <em>overall change</em> is large enough to be visible and valued. That&#8217;s the balance we aim to achieve here.</p>
<div id="_mcePaste" style="overflow: hidden; position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px;">
<h1>Why Users Dumped Your Open Source App for Proprietary Software</h1>
</div>
]]></content:encoded>
			<wfw:commentRss>http://sidewise.biz/2009/09/make-improvement-visible/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Ten ways to fail &#8211; and how to avoid them</title>
		<link>http://sidewise.biz/2009/08/ten-failures-to-avoid/</link>
		<comments>http://sidewise.biz/2009/08/ten-failures-to-avoid/#comments</comments>
		<pubDate>Mon, 24 Aug 2009 08:20:49 +0000</pubDate>
		<dc:creator>TomG</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[anti-pattern]]></category>
		<category><![CDATA[business]]></category>
		<category><![CDATA[insight]]></category>
		<category><![CDATA[pattern]]></category>
		<category><![CDATA[sidewise]]></category>
		<category><![CDATA[wisdom]]></category>

		<guid isPermaLink="false">http://sidewise.biz/?p=121</guid>
		<description><![CDATA[Success often arises just from avoiding failure. For example, consider the &#8216;ten commandments for business failure&#8216; listed by former Coca-Cola CEO Don Keough: &#8220;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, [...]]]></description>
			<content:encoded><![CDATA[<p>Success often arises just from avoiding failure. For example, consider the &#8216;<a title="Amazon - 'Ten Commandments for Business Failure'" href="http://www.amazon.com/Ten-Commandments-Business-Failure/dp/B001LF4AS6/" target="_blank">ten commandments for business failure</a>&#8216; listed by former Coca-Cola CEO Don Keough:</p>
<blockquote><p>&#8220;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.&#8221;</p></blockquote>
<p>This list has been used, for example, to summarise current <a title="Times - 'NHS Business Failure'" href="http://business.timesonline.co.uk/tol/business/industry_sectors/public_sector/article6733624.ece" target="_blank">operational and strategic problems in Britain&#8217;s National Health Service</a> (though that specific example does perhaps prioritise political point-scoring over practical review). But if we <em><strong>think side-wise</strong></em>, we can also re-use these known &#8216;anti-patterns&#8217; for failure as pointers to strategies for business success:</p>
<p><strong><em>Failure #1</em>: Stop taking risks</strong> &#8211; How do you make it safe for people to take risks? How do your people know when risks are appropriate, and when not? What &#8216;safe-fail&#8217; fallback mechanisms could you use to enable people to take safer risks?</p>
<p><strong><em>Failure #2</em>: Be inflexible</strong> &#8211; All those rules and regulations may seem to give little room for manoeuvre, but there are always <em>some</em> options for choice, for chance, for innovation: what are they? How can you use those chances to enhance your organisation&#8217;s ability to adapt to changing business contexts and conditions?</p>
<p><strong><em>Failure #3</em>: Isolate yourself</strong> &#8211; Management hidden away in a bunker, no-one talking to anyone else: many corporations have killed themselves that way. What do <em>you</em> do to ensure you know what&#8217;s going on, both inside and outside the organisation?</p>
<p><strong><em>Failure #4</em>: Assume infallibility</strong> &#8211; Often a problem of arrogance, this one: Enron&#8217;s high-flyers famously described themselves as &#8220;<a title="Wikipedia on 'The smartest guys in the room'" href="http://en.wikipedia.org/wiki/Enron:_The_Smartest_Guys_in_the_Room" target="_blank">the smartest guys in the room</a>&#8220;. Instead, what can <em>you</em> do to ensure that you follow <a title="Cromwell's Rule" href="http://understandinguncertainty.org/node/97" target="_blank">Cromwell&#8217;s Rule</a>, the exhortation of the English Civil War leader and general Oliver Cromwell to &#8220;think it possible you may be mistaken&#8221;?</p>
<p><strong><em>Failure #5</em>: Play the game close to the foul line</strong> &#8211; <a title="Wikipedia on Enron and California energy" href="http://en.wikipedia.org/wiki/California_electricity_crisis" target="_blank">Enron</a> again provides all too many examples of this, such as its &#8216;Death Star&#8217;, &#8216;Ricochet&#8217;, &#8216;Fat Boy&#8217; and other scams through which they stole over $11bn by &#8216;gaming&#8217; the US West Coast electricity market. The short-term gains are invariably outweighed by the long-term losses &#8211; or long jail-sentences&#8230; So <a title="Wikipedia on corporate social responsibility" href="http://en.wikipedia.org/wiki/Corporate_social_responsibility" target="_blank">corporate social responsibility</a> isn&#8217;t a &#8216;feel-good&#8217; fad: as <a title="Wikipedia on Deming '14 points'" href="http://en.wikipedia.org/wiki/W._Edwards_Deming#Dr._W._Edward_Deming.27s_14_points" target="_self">Deming</a>, <a title="Shell General Business Principles" href="http://www.shell.com/home/content/aboutshell/who_we_are/our_values/sgbp/sgbp_30032008.html" target="_blank">Shell</a> and others have demonstrated, it&#8217;s an essential survival strategy, especially in the longer term. We need to be clear about our own business-principles &#8211; and stick to them.</p>
<p><strong><em>Failure #6</em>: Don&#8217;t take time to think</strong> &#8211; In present-day business, the pressure&#8217;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&#8217;t take the time to think about what we&#8217;re doing, and why, we&#8217;re likely to find ourselves running full-tilt into a dead-end, powering over the proverbial cliff. Simple techniques such as the <a title="Wikipedia on After Action Review" href="http://en.wikipedia.org/wiki/After_Action_Review" target="_blank">After-Action Review</a> can make a huge difference: so by what means can <em>you</em> help shift the mindset from &#8220;We don&#8217;t have time to do this stuff!&#8221; to &#8220;We don&#8217;t have time to <em>not</em> do this stuff!&#8221;?</p>
<p><strong><em>Failure #7</em>: Put too much faith in outside experts</strong> &#8211; Often a corollary of Failures #3, #4 and #6: hiding in a corner and using blameable &#8216;outsiders&#8217; to do our thinking for us&#8230; Consultants and contractors do have their roles, especially in helping us avoid falling into &#8216;<a title="Wikipedia on Groupthink" href="http://en.wikipedia.org/wiki/Groupthink" target="_blank">groupthink</a>&#8216;, 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 <em>you</em> do to to build the right balance between &#8216;outside&#8217; and &#8216;inside&#8217;? What <em>you</em> do to <a title="Creating innovation culture at Tata Motors" href="http://frontendofinnovation.blogspot.com/2009/08/creating-innovation-culture.html" target="_blank">create an innovation culture</a> within the business?</p>
<p><strong><em>Failure #8</em>: Love your bureaucracy</strong> &#8211; Bureaucracies do have a real business function, providing &#8216;normal&#8217; paths for business communication, to guide, monitor and manage. But whenever we try to use them as a means of <em>control</em> 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&#8217;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, &#8216;on-purpose&#8217; business reason.</p>
<p><strong><em>Failure #9</em>: Send mixed messages</strong> &#8211; Social networks and increased scrutiny mean that mixed-messages will not only be spotted, but may well be interpreted as &#8216;playing the game close to the foul line&#8217; &#8211; see Failure #5 &#8211; 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 <a title="Slidepack - 'Vision, Role, Mission, Goal'" href="http://www.slideshare.net/tetradian/vision-role-mission-goal-a-framework-for-business-motivation" target="_blank">vision, role, mission and goal</a> &#8211; and to have a clear and meaningful business-vision in the first place!</p>
<p><strong><em>Failure #10</em>: Fear the future</strong> &#8211; This one is often the real driver behind other &#8216;commandments&#8217; to failure, especially Failures #1 and #8. Formal futures techniques such as <a title="Wikipedia on Scenario-analysis" href="http://en.wikipedia.org/wiki/Scenario_planning" target="_blank">business scenarios</a>, <a title="Wikipedia on Environmental scanning" href="http://en.wikipedia.org/wiki/Environmental_scanning" target="_blank">environmental scanning</a> and <a title="Wikipedia on Causal Layered Analysis" href="http://en.wikipedia.org/wiki/Causal_layered_analysis" target="_blank">causal layered analysis</a> will help to ease those fears &#8211; and guide your organisation with what will always be an inherently uncertain future.</p>
<p>How much are <em>you</em> at risk of setting up your business for failure? Turn it round: use this list above to set it up for success.</p>
]]></content:encoded>
			<wfw:commentRss>http://sidewise.biz/2009/08/ten-failures-to-avoid/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

