Local Maxima and Technology Adoption

I generally have faith in the innate smarts of my fellow human beings. And so I tend to subscribe to the view that software can make things better – from recording accounting transactions more accurately all the way through to bringing people closer together. And that people are not slow to adopt a new technology if it makes their lives easier, or restores a childlike wonder to their worlds. I don’t believe in “change management”: if you set out on a software project in the full knowledge that you are going to need a lot of change management then you are setting yourself up to fail (*).

But I also like the idea of “local maxima”. which I have seen referenced in Genetic Algorithms. From the Genetic Algorithms page on Wikipedia

[A Genetic Algorithm] may have a tendency to converge towards local optima or even arbitrary points rather than the global optimum of the problem. This means that it does not “know how” to sacrifice short-term fitness to gain longer-term fitness. The likelihood of this occurring depends on the shape of the fitness landscape: certain problems may provide an easy ascent towards a global optimum, others may make it easier for the function to find the local optima. This problem may be alleviated by using a different fitness function, increasing the rate of mutation, or by using selection techniques that maintain a diverse population of solutions, although the No Free Lunch theorem proves that there is no general solution to this problem.


Here is Guns, Germs and Steel on QWERTY keyboards – a great example of a suboptimal technology that only the churlish would seriously challenge these days.

Unbelievable as it may now sound, [the QWERTY keyboard] was designed in 1873 as a feat of anti-engineering. It employs a whole series of perverse tricks designed to force typists to type as slowly as possible, such as scattering the commonest letters over all the keyboard rows and concentrating them on the left side (where right-handed people have to use their weaker hand). The reason behind all of those seemingly counterproductive features is that the typewriters of 1873 jammed if adjacent keys were struck in quick succession, so that manufacturers had to slow down typists. When improvements in typerwriters eliminated the problem of jamming, trials in 1932 with an efficiently laid-out keyboard showed that it would let us double our typing speed and reduce our typing effort by 95 percent. But QWERTY keyboards were solidly entrenched by then.

What a great example of a local maximum in technology adoption.


(*) If this sounds naive my approach is a bit different. You need to do all your change management before you start your project. Not when you are about to implement it.


3 thoughts on “Local Maxima and Technology Adoption

  1. How can you do your Change Management before you start the project? Changes emerge as the project progresses… Or do you mean by Change Management adjusting yourself and/or resources for a new technology prior to the project?

  2. HI PM Hut thanks for dropping by. And you’re right, my comment is a touch on the flippant side. Intentionally so.

    To be clear – I am talking here about change management aka training aka ramming your software down the users’ throats until they submit to a new regime. I am not talking about change control, or managing change requests to scope etc. which is part of the joy of project management.

    One big issue I’ve seen on ERP implementations is that you get the top brass excited about the project and get them to commit people to work on the project. So far so great. Then 2/3rds the way through the project someone starts wondering “how the hell are we going to sell this to the users”. At this point you often end up with a different set of people with “change management” in their titles joining in the project to try something. Do some posters. Run some lunchtime workshops. Do some training. It’s so often an afterthought so little wonder it fails so often.

    An alternative would be to try to engage the end users in the need to develop new processes/systems in the first place. It means you will take longer to get started, but once you do so you have a better chance of implementing successfully. I know it flies in the face of a lot of standard practice when implementing IT projects. But given that so many IT projects fail I think some new ideas should be welcome.

    Of course how you would do this with a user base of several hundreds or thousands is a different question entirely. But if we can crack that question our IT projects will become a hell of a lot more successful than historically.

  3. I’ve seen this a few years ago: “how the hell are we going to sell this to the users”, and you described (in your comment) exactly what follows. Thanks!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s