Articles by peg

You are currently browsing peg’s articles.

Planning should not require a Gantt chart

2010/09/03 in Business-Technology, IT Strategy by peg | View Comments

There’s a standard slide in my bag of tricks which finds it’s way into a surprising number of presentations. It’s a simple slide, one allowing me to explore the idea of planning as a spectrum of possible methodologies rather than treating planning as an either-or choice: either be bottom-up reactive, or requiring us to engage is a major top-down planning processes. By combining elements of both top-down and bottom-up approaches we can modulate how reactive, or how proactive and predetermined, our execution is. The idea is to set the slider where we want it, at the position that best suits what we are trying to achieve, instead of being forced to one end of the spectrum or the other in a purely reactive or purely deliberative mode.

A slide for our times

A slide for our times

Planning has a bad name. How many projects get stuck in that endless spiral of planning (and re-planning) as they try to find their way to the middle of the project hedge maze? It doesn’t seem to matter if we’re planning the expansion of our business into a new geography or a major IT transformation, the process drives us all nuts; wasted days and nights spent constructing (and then deconstructing and reconstructing) elaborate Gantt charts which we’re all sure will never be used.

All of this runs counter to what could be called the first rule of management:

Make a timely decision, and then make it work.

Most organisations’ first thought is to focus on being reactive and deal with the problems of here and now. Unfortunately this too has its own challenges. The Agile software movement can be seen as one well documented reactive methodology which has seen mixed success. Where time, scope and cost are negotiable, taking a reactive approach is the same as choosing to put scope up for grabs. The result of the project will be whatever the project manages to deliver, unsurprisingly. This might be enough to realise the original business case, or it might not.

A top-down, deliberative, approach is planning as a chess game (the untimed[1] rather than the timed variety). We assume that we have complete information and can take as long as we want to formulate our next few moves. The more we know about our opponent — the more tacit knowledge we have about what might go wrong (and right) on a project — the better and more accurate our plans will be and the further into the future we can plan. We can measure and evaluate our current situation, use tools like scenario planning[2] to anticipate the future, or even hire an innovation consultancy to identify our next, disruptive move. In a perfect world the only limitation to our planning ability is our own ability to comprehend the problem at hand (or the number of tasks we can cram into a Gantt chart, whichever comes first).

The problem is the unexpected — the unpredicted (and possibly unpredictable) event — which makes our plans unravel. It’s the event that we didn’t manage to anticipate, invalidating our assumptions and converting a carefully crafted plan into wasted effort. The faster the environment changes the more likely it is that something unexpected will happen between the plan’s conception and the delivery of its final outcome. Even worse, we might not even finish planning before something unexpected pops up which invalidates our work to date, causing us to restart the planning process.

Take your average major IT transformation: a multiyear project involving a massive investment in both time and money. To kick-start the project we need to predict what the business will need when the transformation is finally delivered (and as I’ve said elsewhere, this is a challenge in itself[3]). If we’re lucky, then assumptions we’ve made about the business’s requirements will still hold true all the way through to the end. However, what’s more likely to happen is that the change orders will start arriving well before we’ve finished, possibly even we’ve completed requirements gathering. The team then struggles to divide their time between scheduled work and change orders before re-planning (and often re-planning again and again) to try and regain control of the project. Try as we may though, the end result is often more like coughing up a fur ball than the slick solution we originally imagined.

A reactive approach, on the other hand, doesn’t worry having about complete information. The focus is on reacting to events as they are encountered, with little thought to long term goals or strategy. A shotgun approach, as it were. We craft our strategy by creating a set of rules covering what we should do in all the circumstances we care about. See a stop sign? Stop. And so on. The challenge is to craft a set of rules which cover most eventualities, and this is a major focus of the “agile” methodologies. They try and craft their manifestos and playbooks to document the tactics — the rules — which they think will drive their projects in the right direction.

playbook [ˈpleɪˌbʊk]
n

  1. (Team Sports / American Football) a book containing a range of possible set plays
  2. a notional range of possible tactics in any sphere of activity

The American Heritage Dictionary of the English Language, Fourth Edition.

The unexpected is not a problem for a reactive approach: you simply deal with problems as they arrive. If you’re not expecting anything in particular, then whatever turns up must have been what your were expecting. (There is logic in there.) However, this puts you at the mercy of what does turn up; as you’re focused on reacting to events, the events which arrive (and the order they arrive in) determine where you end up. While cost and time (i.e. effort) might be fixed, scope (and therefor the final result) is up for grabs, making it hard to drive a reactive approach to planning to deliver a well defined outcome.

With it’s focus on incremental delivery and improvement, a reactive approach is not an obvious bedfellow for your major IT transformation. It’s modus operandi is to focus on shot term demands, understand what the business needs next, build that, and then iterate. The IT estate evolves (somewhat) organically as we add things here, patch things there, and generally muddle our way through. Yes, we are reacting to short term business needs, but at what cost? Its a bit like taking our hands off the tiller to leave ourselves to the mercy of the wind; our boat will probably stay afloat, as long as the weather isn’t too bad, but we have little control over where we end up. Without the ability to drive toward a clear, long term goal, we soon find that all the well meaning tactical decisions we’ve made have resulted in a giant fur ball, just like those occasions where we tried to drive the project forward with a giant Gantt chart.

Neither of these two approaches to planning are necessarily wrong; they’re just not suited to solve the sort of problems we’re dealing with in the new normal[5]. They represent two extremes — proactive and reactive planning — but we need to balance proactive and reactive, and find a middle path.

First we need to admit that we’re resource constrained. This might be in terms of time, the funds we have available, or even simply the number of people we can usefully bring to bear on a problem. (As Frederick Brooks[6] pointed, it might take one woman nine months to produce a baby, but we can’t expect nine woman to deliver a baby in one month.) And this is in an environment where meaningful business change is measured in months, if not weeks. The effort required to develop our plan needs to fit into the time available, and our approach needs to provide opportunities to regularly revisit our assumptions and allow us to react to changes within and without the project. We need need to be reactive, but not too reactive, as we need to work within an overarching framework so that we can have some confidence that we are working toward our long term goals.

People — that’s you and I — take a more pragmatic approach to planning. If we didn’t, then I couldn’t imagine that we would manage to make it through the day with everything we need to get done and the disruptions that we all deal with. Think about how you went to work this morning. (Or how you went to the local café for a coffee, if it’s the weekend.) You weren’t purely reactive. If you were then I expect you would still be lying in bed trying to sort out you manifesto and playbook, hoping for something to happen which will prod you in the right direction. Nor do you take an exclusively top-down, deliberative approach, popping open the laptop on your knee whilst in bed and firing up your favourite planning tool. You’d probably still be stuck in bed, working at the never-ending ending task of plotting exceptions and eventualities. (What should I do if the case of divine intervention?).

People take a middle road. We establish a clear goal, usually something quite prosaic, like:

Get to work (on time)

We have a clear understanding — a set of beliefs, things we expect to be true — of the context we need to do this in.

  • I’m lying in bed
  • it’s a weekday
  • the alarm has just gone off
  • the weather forecast was for a clear sky and sun
  • I’m feeling a bit pudgy today

We also have a library of plans — short patterns of behaviour — which we know that, either from experience or by design, will drive us toward our goal. For example, to get to work we might usually follow the pattern:

  1. get up
  2. shower
  3. get dressed
  4. eat
  5. commute to the office

where each of the steps in this pattern can also be goals themselves.

We might, for example, have a few different plans for commuting: one each for by car, by bike, via public transport, and so on. When it comes time to commute, we consider our beliefs (it’s sunny and I need the exercise) and choose what we think is the most suitable option (I’ll ride). If the option turns out to be a bad choice (one tyre on my bike is unexpectedly flat) or unsuitable due to some change in the environment (it starts raining when I’m less than a block from home), then you discard the plan and pick another (heading back to the garage to take the car). After all, we hadn’t invested much in developing or executing the plan so we’re not losing a lot by throwing it away.

The twisty path between us and our goal

The twisty path between us and our goal

The gap after each step provides us with time to pause and reflect, consider our goal, and respond to the environment by selecting how best to execute the next step. This ability to revisit our decisions frequently — at each step on the journey between the office and home — allows us to be reactive, but not too reactive, while the knowledge that each step is part of a large plan provides us with the confidence that we’re working toward our longer term goals. The more granular we make our plans the more opportunities we provide to react to changes in our environment, but at the cost of being less deliberative and proactive, and potentially less efficient. The more coarse grained we make our plans, the fewer opportunities we create for being reactive, by it allows us to be more deliberative and efficient in delivery.

By modulating the size of our plans — the size of the effort we commit to — we can set the slider where we want it on that planning scale, with reactive on one end, and top down deliberative. This lets us align our planning with the degree of uncertainty and change we’re seeing in the environment around us.

I’ve been using this approach to plan and manage business and IT strategies for some time, with a great deal of success. Most of the tooling required already exists in the business business world, tools such as strategy maps[8], mission statements[9], and project portfolio management tools. Using these tools we can clearly identify our goals, articulate the tactics we want to use to drive ourselves toward them, and then create a portfolio of work which realises the tactics.

For example, the mission of being a low cost service provider might result in a goal of having efficient operations (which we can measure via a benchmark), and the tactics we can use to deliver more efficient operations might include consolidation (reducing the number of offices, data centres, or event tools). We can realise this need for consolidation by identifying a set of small projects (such as shutting down a small data centre, and consolidating its servers into a major one), each of which delivers one step on the journey. These projects then become part of a larger portfolio of work, with the resources available and business priorities determining which projects are executed next.

Just like the example above of each one of us finding our way to work in the morning, this approach enables us to balance how reactive or proactive we are at any time. We can easily re-proritise in response to business change by updating the mix of projects to be executed, rather than through a major re-planning effort. At the same time, we can be sure that the portfolio of work is driving us toward our long term goals, as each project aligns with an organisational goal. Planning without a major Gantt chart.

References
1. Types of chess games defined at Chess.netMartin Börjesson has put together some nice resources on Scenario planningI’ve already told you 125% of what I know @ PEGThe new normal @ McKinsey QuarterlyFrederick Brooks on the Mythical Man MonthStrategy map defined @ Value Based Mangement by Kaplan & NortonMission statement defined @ The Centre for Business Planning↑

Tags: , , , , , , , , , ,

Innovation [25-08-2010]

2010/08/25 in Innovation, Mailing List by peg | View Comments

Another week and another collection of interesting ideas from around the internet.

As always, thoughts and/or comments are greatly appreciated.

Tags: , , , , ,

Basketball as an innovation metaphore

2010/08/19 in Innovation by peg | View Comments

I just realised that the approach to basket ball described by The no-stars all star, from the NY Times, is a nice model for innovation (whatever that is).

I’ve been struggling for a while to understand how to define innovation other than retrospectively (isn’t hindsight a wonderful thing). We can pin down invention, customer need, product development, marketing etc. — all the elements to make an innovation successful — but picking an innovation seems the impossible task.

Efforts to define and codify innovation are like capturing lightening in a bottle. You can’t systematise a process which has a large degree of luck to it. What you can do, though, is to be prepared. This is where tools like design thinking fit in.

The interesting thing about the basketball article is that the coach admitted that basketball is a numbers game. Given the game’s high scoring rate, it’s not enough to have killer skills; there’s a large element of luck involved: being in the right place at the right time.

The coach’s approach is to try and increase his chances of being lucky, which he uses two tactics to achieve:

  • Try and be as efficient as possible.
  • Try to make your opposition as inefficient as possible.

The coach grinds the numbers to understand what are the odds of sinking or blocking a shot in each and every position on the court, and for each and every player. He then focuses on positioning his players to improve his odds, while reducing the odds of the opposing team. This makes his team more efficient, and more likely to capitalise on an opportunity, and the opposition less efficient, and less likely to capitalise on an opportunity. Think: forcing an opponent to shoot from the right when he prefers (and is more successful with) the left.

A common mistake is to assume that innovation is a creative processes: it’s not (you can always steal the idea rather than think of it yourself). Many of the tools we use to help companies to manage innovation are focused on making them more efficient in managing the innovation journey: focusing their energies where they are needed the most. Now with basketball as an inspiration, it might be possible to bring these tools together in a more scientific framework.

Tags: ,

Think “in the market,” not “go to market”

2010/08/18 in Business-Technology by peg | View Comments

A friend of mine[1] made an astute comment the other day.

We need to think about “in the market” models, rather than “go to market” models.

I think this nicely captures the shift we’re seeing in the market; businesses are moving away from offering products which (hopefully) will sell, and adopting models founded on successful long term relationships. This is true for both business-to-consumer and business-to-business relationships, as our success is increasingly dependent on the success of the community we are a part of and the problems that we solve for (our role in) this community.

For a long time we’ve sought that new widget we might offer to the market: the new candy bar everyone wants. It’s the old journey of:

  • find a need,
  • fulfil the need.

Our business models have been built around giving someone something they what, and making a margin on the way through. Sometimes our customers didn’t know that they had the need until we, or their peer group, pointed it out to them, but we were nevertheless, fulfilling a need.

Recent history has seen the more sophisticated version of this emerge in the last few decades:

Give them the razor and sell the razor blades[2].

which has the added advantage of fulfilling a reoccurring need. Companies such as HP have made good use of this, more-or-less giving away the printers while pricing printer ink so that it is one of the most expensive substances on the planet (per gram).

Since then, companies (both B2C and B2B) have been working hard to reach customers earlier and earlier in the buying process. Rather than simply responding, after a customer has identified a need, along with the rest of the pack, they want to engage the customer and help the customer shape their need in a way that provides the company with an advantage. A great example of this are the airlines who enable you to buy a short holiday somewhere warm rather than a return trip to some specified destination. The customer gets some help shaping their need (a holiday), while the company has the opportunity to shape the need is a way that prefers their products and services (a holiday somewhere that the airline flies to).

The most recent shift has been to flip this approach on its head. Rather than aligning themselves with the needs they fulfil, some companies are starting to align themselves with the problems they solve. Needs are, after all, just represent potential solutions to a problem.

Nike is an interesting case study. Back in the day Nike was a (marketing driven) sports shoe company. If you needed shoes, then they had shoes. Around 2006—2008 Nike started developing a range of complementary products – web sites, sensors integrated into clothing, etc. – and began positioning the company as providing excellence in running, rather than simply fulfilling a need. The company grew 27% in two years as a result.

Rolls Royce (who I’ve written about before[3]) are another good example, but business-to-business. They shifted from the need (jet engines) to the problem (moving the plane) with huge success.

While these companies still have product and service catalogues, what’s interesting is the diversity of their catalogues. Rather than structuring their catalogue around an internal capability (their ability to design and manufacture a shoe or jet engine), the focus is on their role in the market and the capabilities required to support this role.

As Andy said, they have an “in the market” model, rather than a “go to market” model.

References
1. Andy Mulholland @ CapgeminiGiving away the razor, selling the blades @ Interesting thing of the dayWhat I like about jet engines @ PEG↑

Tags: , , , , , ,

I’ve already told you more than 125% of what I know

2010/08/06 in Business-Technology by peg | View Comments

Bob Sutton has an interesting post on the limits of expertise: I have already told you more than 125% of what I know. As he points out:

I think that those of us who are alleged to have expertise in certain topics can easily fall into this trap as we try to be helpful to others, and rather than stopping and realizing that we are beyond our expertise, we just keep saying more and more about things we know less and less about.

Bob is talking about journalism, but there’s a similar problem with the business-IT relationship.  IT often forgets that subject matter experts don’t always have the answers needed; at least, not yet. Sometimes the subject matter experts need time to convert tacit knowledge —knowledge they know but which they can’t write down, or which they even struggle to explain — into a form which we can consume. Or they might even need time among themselves to create the knowledge together.

I’ve seen more than a few projects come unstuck because they didn’t understand that capturing knowledge is a journey you need to take with the business. The team continually returned to the business for more detail — asking for bullet pointed requirements or stories in a format that IT can easily consume — an approach which often fails, even if you have an embedded SME (à la Agile). (How many agile products have burnt out this customer representative with an overwhelming volume of detailed questions which the representative struggles to answer? Or transformation programmes which try to get the business to predict what they’ll need in a couple of years time, only to find out that they couldn’t predict that far into the future.) Sometimes the business just doesn’t know the answer, or can’t communicate it via our IT artefacts. They’ve already told us 125% of what they know.

We need to provide the business with a little help. This might involve iteration — showing them an early version to see “is what you meant”. It might mean deploying initial functionality into production quickly, and then building on the deployed solution. Or it might involve talking about the the things the business cares about — tasks, decisions, and points of variation, in the case of capturing a workflow — so that they can focus on the outcome they are driving too, leaving IT to worrying about how it might be implemented.

Today, we’re focused on leveraging the synergies between business and technology, rather than simply automating existing business processes. New technologies enable new business models which were not possible before. The business can see the opportunities but doesn’t know what’s possible. IT knows what’s possible, but can’t see the opportunities. Companies that understand this blur the line between business and IT, getting the two groups to work together, on the same side of the table, to identify and exploit these synergies. These companies — such as Zappos, P&G and Vanguard — identify and exploit new revenue streams which are unavailable to their peers.

What’s interesting about these companies is that they seem to have realised that building out their IT estate is a journey that IT and business need to take together, rather than a simple matter of IT asking business what they want.

Tags: , , , , ,

Peter Drucker’s seven sources of innovation

2010/08/04 in Innovation by peg | View Comments

It seems that every time I find a web reference for Peter Drucker’s seven sources of innovation, the web site dies. So after yet-another site going the way of the dodo, I’ve decided to record them here, in this blog, so I at least have a stable thumbnail definition to point folk at.

Peter Drucker’s seven sources of innovation:

  1. The unexpected. The unexpected success, failure or outside event.
  2. The incongruity. The difference between reality as it actually is and reality as it is assumed to be or as it “ought to be.”
  3. Innovation based on process need.
  4. Changes in industry structure or market structure that catch everyone unawares.
  5. Demographics. Population changes
  6. Changes in perception, mood and meaning
  7. New knowledge, both scientific and nonscientific.

If you want more detail, then get the book Innovation and Entrepreneurship.

Tags:

Innovation [2010-08-02]

2010/08/02 in Innovation, Mailing List by peg | View Comments

Another week and another collection of interesting ideas from around the internet.

As always, thoughts and/or comments are greatly appreciated.

Tags: , , , , , ,

Michelangelo’s approach to workflow discovery

2010/07/29 in Business Process Management by peg | View Comments

Take any existing workflow — any people driven business process — and I expect that most of the tasks within it could best be described as cruft.

cruft: /kruhft/
[very common; back-formation from crufty]

  1. n. An unpleasant substance. The dust that gathers under your bed is cruft; the TMRC Dictionary correctly noted that attacking it with a broom only produces more.
  2. n. The results of shoddy construction.
  3. vt. [from hand cruft, pun on ‘hand craft’] To write assembler code for something normally (and better) done by a compiler (see hand-hacking).
  4. n. Excess; superfluous junk; used esp. of redundant or superseded code.
  5. [University of Wisconsin] n. Cruft is to hackers as gaggle is to geese; that is, at UW one properly says “a cruft of hackers”.

The Jargon File, v4.4.7

Capturing and improving a workflow (optimising it even) is a processes of removing cruft to identify what really needs to be there. This is remarkably like Michalangelo[1]‘s approach to carving David[2]. When asked how he created such a beautiful sculpture, everything just as it should be, Michalangeo responded (and I’m paraphrasing):

Michelangelo's David

Michelangelo's David

David was always there in the limestone; I just carved away the bits that weren’t David.

Cruft is the result of the people — the knowledge workers engaged in the process — dealing with the limitations of last decade’s technology. Cruft is the work-arounds and compensating actions for a fragmented and conflicting IT environment, an environment which gets in the road more often than it supports the knowledge workers. Or cruft might be the detritus of quality control and risk management measures put in place some time ago (decades in many instances) to prevented an expensive mistake that is no longer possible.

Most approaches to workflow automation are based on some sort of process improvement methodology, such as LEAN or Six Sigma. These methods work: I’ve often heard is stated that pointing Six Sigma at a process results in a 30% saving, each and every time. They do this by aggressively removing variation in the process — slicing away unnecessary decisions, as each decisions is an opportunity for a mistake. These decisions might represent duplicated decisions, redundant process steps, or unnecessarily complicated handoffs.

There’s a couple of problems with this though, when dealing with workflow. Looking for what’s redundant doesn’t create an explicit link between business objectives and the steps in the workflow, explicitly justifying each step’s existence, making it hard to ensure that we caught all the cruft. And the aggressive removal of variation can strip a process’s value along with its cost.

Much of the cruft in a workflow process is there for historical reasons. These reasons can range from something bad happened a long time in the past through to we don’t know why, but if we don’t do that then the whole thing falls over. A good facilitator will challenge seemingly obsolete steps, identifying those steps who have served their purpose and should be removed. However, it’s not possible to justify every step without quickly wearing down subject matter experts. Some obsolete steps will always leak through, no matter how many top-down and bottom-up iterations we do.

We can also find that we reach the end of the processes improvement journey only to find that much of the process’s value — the exceptions and variation that make the process valuable — has been cut out to make the process more efficient or easier to implement. If the quest for more since in our processes, we’ve eliminated the art that we relied on, leaving too much science behind.

If business process management isn’t a programming challenge[3], then this holds even truer for human driven workflow.

What we need is a way to chip away the cruft and establish a clear line of traceability between the goals of each stakeholder involved in the process, and each step and decision in the workflow. And we need to do this in a way that allows us to balance art and science.

I’m pretty sure that Michalangeo had a good idea of what he wanted to create when he started belting on the chisel. He was looking for something in the rock, the natural seems and faults, that would let him find David. He kept the things that supported his grand plan, while chipping away those that didn’t.

For a workflow processes, these are the rules, tasks and points of variation which knowledge workers use to navigate their way through the day. Business rules and tasks are the basic stuff of workflow: decisions, data transformation and hand-offs between stakeholders. Points of variation let us identify those places in a workflow where we want to allow variation — alternate ways of achieving the one goal — as a way of balancing art and science.

Rather than focus on programming the steps of the process, worrying if we should send an email or a fax, we need to make this (often) tacit knowledge explicit. Working top-down, from the goals of the business owners, and bottom-up, from the hand-offs and touch-points with other stakeholders, we can chip away at the rock. Each rule, task or point of variation we find is measured against the our goals to see if we should chip it away, or leave it to become part of the sculpture.

That which we need stays, that which is unnecessary is chipped away.

References
1. Michelangelo BuonarrotiMichelangelo’s DavidA business process is not a programming challenge @ PEG↑

Tags: , , , , ,

The sun-shaped individual

2010/07/27 in Innovation, Posterous by peg | View Comments

(Yep, this is a cross post from Stuff I find interesting, but the missive grew to the point that I thought it worthwhile putting it on this blog as well.)

I stumbled across a rather interesting, and rather old (in internet terms), blog post today: T-Shaped + Sun-Shaped People by David Armano. I suppose you could say that it’s a build on the old idea of t-shaped people, folk with deep experience in one domain (their core discipline). As the post quotes, from Tim Brown at IDEO:

We look for people who are so inquisitive about the world that they’re willing to try to do what you do. We call them “T-shaped people.” They have a principal skill that describes the vertical leg of the T — they’re mechanical engineers or industrial designers. But they are so empathetic that they can branch out into other skills, such as anthropology, and do them as well. They are able to explore insights from many different perspectives and recognize patterns of behavior that point to a universal human need. That’s what you’re after at this point — patterns that yield ideas.

I’ve always found the concept of t-shaped people interesting and troubling at the same time. One the one hand their broader view provides them with some sensitivity for the problems and experience to be found in other domains. On the other, it reeks of dilettantism, as there is no rational behind their interest other than curiosity (what’s it like on the other side of the fence?). This leaves you a victim of the dogma of your core discipline, with the cross discipline stuff just window dressing.

For a while I’ve thought (and spoken) of then need to have some sort of coherent focus to our interests, something beyond the doctrine we learnt in our early twenties and which largely defines us. I think we need this focus for a few different reasons.

Firstly, it provides helps us identify the sort of problems we want to solve beyond the constraints of a well defined discipline. I’m interested in how people solve problems, which leads me to working in everything from (business) strategy down to workflow design.

Secondly, it provides you with a framework to identify and integrate new ideas and domains into your toolkit. It’s a bit like Bruce Lee’s ideas of “adopt what you can use” from Jeet Kyne Do. For years I’ve been finding, collecting, evaluating and then either integrating ideas from areas as diverse as logic and science, (bio-medical) engineering, history, philosophy (including the likes of Cicero), human factors, business theory (Michael Porter an the like) and even computer science (particularly AI). You don’t collect random ideas (a la TED), you find useful tools which integrate with and add value to your toolkit.

Thirdly, it provides you with a mechanism to cope with the deluge of information we live in today. There’s a lot of talk of the need for smart filters, which I’ve always had a problem with. Perhaps it’s my little internal John Boyd, but we shouldn’t be just throwing away valuable information. A more intelligent approach is to have a framework — a focus — which makes it easier to integrate the information into our world view. (There’s probably a whole post in this point alone.)

David’s post posited the concept of sun-shaped person, which sounds a lot like this idea of having a consistent focus.

Does this make us "sun-shaped people"?

Does this make us "sun-shaped people"?

Quoting David:

Most of us have some kind of passion in a specific area. For some—it’s a hobby or interest. For others, it’s directly related to our work. I fall into the latter category. If you were to ask me what my “passion is”—I would probably say that at the core, it’s creative problem solving. This is pretty broad and incorporates a lot of disciplines that can relate to it. But that’s the point. What if we start with our passions regardless of discipline, and look at the skills which radiate out from it the same way we think about how rays from the sun radiate warmth?

I think this makes a lot of sense, and fits in a lot more neatly with the direction the world is headed, than the concept of a t-shaped individual. Who doesn’t wear multiple hats these days? How much of your job is actually related to your job title? And don’t we all steal ideas from other disciplines?

Tying yourself to a single domain — I’m a supply chain person, I’m a techo, I do human factors — is committing yourself to doing the same thing that you did yesterday. Your marking yourself as a domain specialist. The challenge is that we seem to be entering an age where we need more generalists. Last year you worked in finance, this year your building robots, next year you might be in durable goods. Your focus, your passions, won’t have changed, but what you do day-to-day will have. That sounds a lot like the sun shaped individual to me.

What is innovation?

2010/07/26 in Innovation by peg | View Comments

What is innovation? I don’t know, but then I’m not even sure that it’s an interesting question. The yearning so many companies have to be innovative often seems to prevent them from actually doing anything innovative. They get so caught up in trying to come up with the next innovation — the next big product — that they often fail to do anything innovative at all. It’s more productive to define innovation by understanding what it’s not: doing the same thing as the rest of the crowd, while accepting that there are no silver bullets and that you don’t control all the variables.

So, what is innovation? This seems to be a common question thats comes up whenever a company wants to innovate. After all, the first step in solving a problem is usually to define our terms.

Innovation is a bit like quantum theory’s spooky action at a distance[1], where stuff we know and understand behaves in a way we don’t expect. It can be easy to spot an innovative outcome (hindsight is a wonderful thing), but it’s hard to predict what will be innovative in the future. Just spend some time browsing Paleo-Future[2] (one of my favourite blogs) to see just how far off the mark we’ve been in the past.

The problem is that as it’s all relative; what’s innovative in one context may (or may not) be innovative in another. You need an environment that brings together a confluence of factors — ideas, skills, the right business and market drivers, the time and space to try something new — before there’s a chance that something innovative might happen.

Unfortunately innovation has been claimed as the engine behind the success of more than a few leading companies, so we all wanted to know what it is (and how to get some). Many books have been written promising to tell you exactly what to do to create innovation, providing you with a twelve step program[3] to a happier and more innovative future. If you just do this, then you too can invent the next iPhone[4].

Initially we were told that we just needed to find the big idea, a concept which will form the basis of our industry shattering innovation. We hired consultants to run ideation[5] workshops for us, or even outsourced ideation to an innovation consultancy asking them to hunt down the big idea for us. A whole industry has sprung up around the quest for the big idea, with TED[6] (which I have mixed feelings about) being the most obvious example.

As I’ve said before, the quest for the new-new thing is pointless[7].

The challenge when managing innovation is not in capturing ideas before they develop into market shaping innovations. If we see an innovative idea outside our organization, then we must assume that we’re not the first to see it, and ideas are easily copied. If innovation is a transferable good, then we’d all have the latest version.

Ideas are a dime a dozen, so real challenge is to execute on an idea (i.e. pick one and do something meaningful with it). If you get involved in that ideas arms race, then you will come last as someone will always have the idea before you. As Scott McNealy at Sun likes to say:

Statistically, most of the smart people work for somebody else.

More recently our focus has shifted from ideas to method. Realising that a good idea is not enough, we’ve tried to find a repeatable method with which we can manufacture innovation. This is what business does after all; formalise and systematise a skill, and then deploy it at huge scale to generate a profit. Think Henry Ford and the creation of that first production line.

Design Thinking[8] is the most popular candidate for method of innovation, due largely to the role of Jonathan Ive[9] and design in Apple’s rise from also-ran to market leader. There’s a lot of good stuff in Design Thinking — concepts and practices anyone with an engineering background[10] would recognise. Understand the context that your product or solution must work in. Build up the ideas used in your solution in an incremental and iterative fashion, testing and prototyping as you go. Teamwork and collaboration. And so on…

The fairly obvious problem with this is that Design Thinking does not guarantee an innovative outcome. For every Apple with their iPhone there’s an Apple with a Newton[12]. Or Microsoft with a Kin[11]. Or a host of other carefully designed and crafted products which failed to have any impact in the market. I’ll let the blog-sphere debate the precise reason for each failure, but we can’t escape the fact the best people with a perfect method cannot guarantee us success.

People make bad decisions. You might have followed the method correctly, but perhaps you didn’t quite identify the right target audience. Or the technology might not quite be where you need it to be. Or something a competitor did might render all your blood sweet and tears irrelevant.

Design Thinking (and innovation) is not chess: a game where all variables are known and we have complete information, allowing us to make perfect decisions. We can’t expect a method like Design Thinking to provide an innovative outcome.

Why then do we try and define innovation in terms of the big idea or perfect methodology? I put this down to the quest for a silver bullet: most people hope that there’s a magic cure for their problems which requires little effort to implement, and they dislike the notion that hard work is key.

This is true in many of life’s facets. We prefer diet pills and magic foods over exercise and eating less. If I pay for this, then it will all come good. If we just can just find that innovative idea in our next facilitated ideation workshop. Or hire more designers and implement Design Thinking across our organisation.

Success with innovation, as with so many things, is more a question of hard work than anything else. We forget that the person behind P&G’s Design Thinking efforts[13], Cindy Tripp, came out of marketing and finance, not design. She chose Design Thinking as the right tool for the problems she needed to solve — Design Thinking didn’t choose her. And she worked hard, pulling in ideas from left, right and centre, to find, test and implement the tools she needed.

So innovation is not the big idea. Nor is it a process like Design Thinking.

For me, innovation is simply:

  • working toward a meaningful goal, and
  • being empower to use whichever tools will be most beneficial.

If I was to try and define innovation more formally, then I would say that innovation is a combination of two key concepts: obliquity[14] and Jeet Kune Do[15]‘s concept of absorbing what is useful.

Obliquity is the simple idea that the best way to achieve a goal in a complex environment is to take an indirect approach. The fastest and most productive path to the top of the mountain might be to take the path that winds its way around the mountain, rather than to try and walk directly up the steepest face.

Apple is a good example of obliquity in action. Both Steve Jobs and Jonathan Ives are on record as wanting to make “great products that we want to own ourselves,” rather than plotting to build the biggest and most innovative company on the planet. Rather than try and game the financial metrics, they are focusing on making great products.

Bruce Lee[16] came up with the idea of “absorbing what is useful”[17] when he created Jeet Kune Do. He promoted the idea that students should learn a range of methods and doctrines, experiment to learn what works (and what doesn’t work) for them, “absorb what is useful” while discarding the remainder. The critical point of this principle is that the choice of what to keep is based on personal experimentation. It is not based on how a technique may look or feel, or how precisely the artist can mimic tradition. In the final analysis, if the technique is not beneficial, it is discarded. Lee believed that only the individual could come to understand what worked; based on critical self analysis, and by, “honestly expressing oneself, without lying to oneself.”

Cindy Tripp at P&G is a good example of someone absorbing what is useful. Her career has her investigating different topics and domains, more a sun shaped individual than a t-shaped one[18]. Starting from a core passion, she accreted a collection of disciplines, tools and techniques which are beneficial. Design Thinking is one of these techniques (which she uses as a reframing tool).

I suppose you could say that I’ve defined innovation by identifying what it’s not: innovation is the courage to find a different way up the hill, while accepting that there are no silver bullets and that you don’t control all the variables.

Updated: Tweeked the wording in the (lucky) 13th paragraph in line with Bill Buxton’s comment.

For every Apple with their iPhone there’s an Apple with a Newton. Or Microsoft with a Kin.

References
1. Spooky action at a distance? @ Fact and FictionPaleo-FutureTwelve step programs @ WikipediaiPhone — the Apple innovation everyone expected @ Fast CompanyIdeation defined at WikipediaTEDInnovation should not be the quest for the new-new thing @ PEGDesign Thinking … what is that? @ Fast CompanyJonathan Ive @ Design Museum↑
10. Sorry,
software engineering doesn’t count.The story behind the Apple Newton @ GizmodoMicrosoft Said to Blame Low Sales, High Price for Kin’s Failure @ Business WeekP&G changes it’s game @ Business WeekObliquity defined at SearchCRMJeet Kune Do, a martial art discipline developed by Bruce Lee @ WikipediaBruce Lee: the devine windAbsorbing what is useful @ WikipediaT-Shaped + Sun-Shaped People @ Logic + Emotion↑

Tags: , , , , , , , , , , , , , , , , , , , , , , ,

« Older entries