NOW AVAILABLE The draft of my book on Organizational Intelligence is now available on LeanPub Please support this development by subscribing and commenting. Thanks.

Friday, August 14, 2009

Next Practice

Why do we need next practice? Because the old thinking (received wisdom) and the old practices (best practices) are still struggling with the old problems, let alone the new challenges.

old thinking, received wisdom

Large organizations have often looked to industry analysis firms for generic advice on technology strategy and related matters. But these firms sometimes seem little more than an extension to the marketing function of the large technology vendors, helping to invent and promote an array of new jargon, and producing a series of pseudoscientific classification. One senior IT manager told me recently that he looked to industry analysis to help him “spend wisely on IT”. That’s an excellent objective, but you might need a little more than curves and quadrants.

old practice, best practice

Traditional consultancy can sometimes suffer from the following risk. A significant amount of consultancy work is involved in delivering tried-and-tested solutions to known problems. For example the client may have a process problem: this is quickly diagnosed as a “six sigma” problem, so you put together a team of six sigma experts and software experts and process management experts and a strong project manager to deliver a “six sigma” solution. Although there may be an exploratory phase at the start of an engagement, allowing for a more open-ended investigation of the nature of the problem, this is typically carried out by a small elite of the most experienced consultants using adhoc methods; consultancy firms generally experience commercial pressure to conclude the open-ended exploration and start the delivery phase as quickly as possible. But such delivery projects are vulnerable to a number of risks, for example
  • that the solution may interact in unforeseen ways with other aspects of the business organization, or with other solutions being developed elsewhere
  • that the solution may require clever and complicated mechanisms to work effectively, which add to the overall complexity of the business and its processes
  • that the chosen solution may actually not be the most appropriate way of addressing this problem at this time
  • that the solution fails to deliver the promised benefits

The paradox of “demanding solutions” is that the delivery of a given solution (such as six sigma) never gets any easier. Although the delivery team may get more experienced with a given approach and may accumulate reusable patterns and components, and although the tools and platforms may get more sophisticated, this is counterbalanced by the fact that the easy opportunities (the so-called “low-hanging fruit”) have probably already gone. In such an environment, the solution itself generates further demands.

next thinking, next practice

So what does it take to become
  • creatively rigorous and rigorously creative?
  • analytic and synthetic, evidence-based, results-based?
  • reflective and self-critical?

1 comment:

  1. The first bullet, "...the solution may interact..." is absolutely key. When we have interdependent contexts (I hesitate to say shared), then we have complex interactions. Each contributor ends up having responsibility for every one else's context. This is particularly nasty coupling and is absolutely doomed. Just as it is hard to change someone's mind about the meaning of a word or some dearly helpd belief, it is just as hard to change the viewpoint of a system including all the humans. We can try to change the taxonomy and we see ideas like the mnusician Prince. He changed the name, but almost immediately became "Formerly known as Prince."

    So we decide to unify the vocabulary. There are 12 different meenings for customerid, so we create the new "CustomerIdentifier." Immediately the in place teams will start to use it and then say things like, "CustomerIdentifier - you the thing we used to call customerid."

    The point here is that we expect the various entities that have to share context to agree on as little as possible, and then figure out how to map from one context to another.

    Why do this? because the various parties and their contexts are all evolving independently. Because commonizing abstractions really don't succeed. Because we actually want to get stuff done. Because there are entirely different control mechanisms in place on either side of the context.

    Now imagine scaling this up to many different contexts and the problem increases rapidly and dramatically.

    So, maintain your own context, share as little context as possible and only attempt to map between contexts when absolutely necessary.