Saturday, December 4, 2010

Two change management analogies I like

Over the past few years, managing change in organisations has fascinated me both academically and professionally. And often the humanistic universality of the subject has meant much reflection beyond work. Let's face it, influence and behavioural change is not too far from the daily romantic, platonic and even transactional exchanges.

Has my understanding 'changed'?

Many textbooks and consulting frameworks have covered change. From the draconian and controlled to the most chaos-assumed and humanistic. A Google search on the string "Change Management" yields over five million results. I won't stand to repeat any of these. However, in using these models, I find that it can be very easy to apply these in a superficial way. I find what is often missing here is the fundamental mindset required for anyone involved in planning and executing change.

Lately, the solution for this missing piece seems to have come to me in the form of behavioural economics. The idea of designing a choice environment where individual users have perceived autonomy, whilst contributing still to the intended change outcome is indeed very appealing. While it may be Machiavellian, this thinking immediately alters the way initiatives are developed and sequenced as change interventions.

Why analogies?

Working with operational managers has taught me that change is often a very intellectual concept. We know current and future states, we know the project plan. However to get change right, it needs to be an emotive and behavioral concept. With pressure of doing the day job, clutter of project plans, structure diagrams and various other organisational artifacts to distract, thinking and strategising based on behavioural and emotional responses is often non-existent. In these cases, analogies of change can help refocus the initiatives planned and implemented to be more humanistic. Designed with more consideration for this "freedom of choice".

Here are my two favourite analogies:

The potty training analogy - it's all about incentives
Earlier on in my career, I often wonder why change programs based on technology implementations are often resented. By the same token, I have always been baffled by the non-attractiveness of well-designed tools. I now realise that the execution of these are often not ordered correctly.


Let's say that mum has to potty-train Billy. There are a number of options mum can take 1) Process - develop a set of instructions for using the toilet, 2) System and tools - put in place a stool in front of the toilet to allow Billy to reach the bowl, 3) Performance incentives - provide reward and punishment in the form of candy for example. In the technology implementation example, the order is often 2, 1 and 3. So mum puts the stool in front of the toilet, tells Billy to use it and then punishes Billy for not doing the right thing. In this case, it is highly likely the change will occur begrudgingly and Billy will resent the stool as impediment to his reward.

A more effective strategy would be for mum to implement the right incentives to reward or punish toilet using behaviour and put Billy through a process of self problem solving. After a few moments of trying, Billy will more than likely seek instructions on how to use to toilet then try again. He may then find that he can't reach the bowl and request a stool be made available to him. In this case, the process and tool seems to be provided because it was Billy's idea. He will more than likely see these things as enablers rather than barriers to his reward. A very different dynamic to the former.

I am by no means suggesting that the order of incentive, process and tool is the best solution in organisational change scenarios. Nor am I recommending the above way of bring up children. But I think what is necessary is this level of critical and complete thinking to make sure planned initiatives achieve the best change results from a humanistic perspective. Organisation are different, certain cultures may lean towards systems and tools as the change leader. However, arriving at this decision based on ignorant following of framework rather than a consciously evaluated decision can be highly dangerous.

The amoeba analogy - plan for multi-variance
A second analogy is probably a result of my background in risk management. I find managers often get too caught up in the processual change management, and as a consequence lose sight of the "what if" scenario based thinking.




The amoeba analogy derives from the AtKisson innovation diffusion game. The game makes analogy to the process of cell mitosis when an innovation idea is propagated through an organisation. This analogy presents a very real reminder that organisational change is a very organic process with resistance, feedback, conflict and individual differences. Messaging and delegated selling is everything, and nothing should really be taken for granted. Whilst it might be difficult to plan exactly for various feedback and reshaping required along the change process, managers do need to be prepared for responding. This analogy, and in particular running the game as an exercise often reinforces that mindset.

Playing God?

The fundamental error managers make in change management planning is that success is only indicated by the right outcome. Usually, narrowly defined to be some financial achievement. While that might be true ultimately, the quality of change decisions should more accurately be judged by the quality of the process with which these decisions are arrived at. By simply applying a framework in a superficial way to string together a range of initiatives without delving into the emotional and behavioural aspects of the organisation, the decision making process is far from quality.

Playing God in organisations is near impossible, managers cannot guarantee the outcome of change processes. However, by paying attention to the inputs through thinking reflectively with the help of analogies, planned outcomes may be more likely on budget and on time.

Sunday, August 1, 2010

Tradable broadband allocation

Short post today...

In Australia (where I live), ISPs generally have limits on the monthly subscription of brandband Internet (cap). Which is a huge pain in the arse because you have to essentially ration what you use. The problem arises when there are multiple self-serving individuals on your network, each wanting to maximise their individual net usage.

Exceeding the limit is meaningful because the "punishments" are just annoying enough to care. There is generally one of two consequences:
  1. the connection slows down to 256k (traffic shaping) or
  2. there is a ridiculous charge per MB used etc.
The main sufferers for this problem is probably the following two segments:
  1. families with multiple teenagers and 
  2. housesharing uni students.

My idea is essentially based on using "tradable rights to use" to fix this tragedy-of-the-commons resource problem (see management of fisheries). Essentially I propose the following:
  • Now that households are increasingly having 1 computer each person, within the management console of the router / modem, there can be a module to set the monthly overall limit and then allocate monthly limits by MAC address.
  • There should be a function to set sizes of tradable "bundles", for example 10mbs per bundle, and each bundle is then assigned to a set currency determined and agreed by the household (ie 1 carwash = 2 bundles).
  • Each computer then has a client module where individual users can engage in exchange with some oversight from the administrator (parent).

The benefits would be tremendous I think!
  • Parents and fellow housemates win because there's less argument in the household.
  • Kids learn about how resource problems work and learn a little about economic solutions (have you tried to ask a teenager what carbon trading is?)
  • Modem makers can successfully differentiate their product as a family friendly (we help you do parenting! or allocate tasks between housemates).
  • Chores get done argument free.

Basically its a total win! and knowing something about programming, it should be easy to put together. It's a basic third year assignment, not even an honours thesis.

What do you think?

PS. Uploading this on a 256k connection as I write...