Business-Technology

You are currently browsing the archive for the Business-Technology category.

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: , , , , , , , , , ,

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: , , , , ,

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: , , , , ,

Taxonomies 1, Semantic Web (and Linked Data) 0

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

I’m not a big fan of Semantic Web[1]. For something that has been around for just over ten years — and which has been aggressively promoted by the likes of Tim Berners-Lee[2] — very little real has come of it.

Taxonomies, on the other hand, are going gangbusters, with solutions like GovDirect[3] showing that there is a real need for this sort of data-relationship driven approach[4]. Given this need, if the flexibility provided by Semantic Web (and more recently, Linked Data[5]) was really needed, then we would have expected someone to have invested in building significant solutions which use the technology.

While the technology behind Semantic Web and Linked Data is interesting, it seems that most people don’t think it’s worth the effort.

All this makes me think: the future of data management and standardisation is ad hoc, with communities or vendors scratching specific itches, rather than formal, top-down, theory driven approaches such as Semantic Web and Linked Data, or even other formal standardisation efforts of old.

The technologies behind the likes of Semantic Web and Linked Data have a long heritage. You can trace them back to at least the seventies when ontology and logic driven approaches to data management faced off against relational methodologies. Relational methods won that round — just ask Oracle or the nearest DBA.

That said, there has been a small number of interesting solutions built in the intervening years. I was involved in a few in one of my past lives[6], and I’ve heard of more than a few built by colleagues and friends. The majority of these solutions used ontology management as a way to streamline service configuration, and therefor ease the pain of business change. Rather than being forced to rebuild a bunch of services, you could change some definitions, and off you go.

What we haven’t seen is a well placed Semantic Web SPARQL[7] query which makes all the difference. I’m still waiting for that travel website where I can ask for a holiday, somewhere warm, within my budget, and without too many tourists who use beach towels to reserve lounge chairs at six in the morning; and get a sensible result.

The flexibility which we could justify in the service delivery solutions just doesn’t appear to be justifiable in the data-driven solution. A colleague showed my a Semantic Web solution that consumed a million or so pounds worth of tax payer money to build a semantic-driven database for a small art collection. All this sophisticated technology would allow the user to ask all sorts of sophisticated questions, if they could navigate the (necessarily) complicated user interface, or if they could construct an even more daunting SPARQL query. A more pragmatic approach would have built a conventional web application — one which would easily satisfy 95% of users — for a fraction of the cost.

When you come down to it, the sort of power and flexibility provided by Semantic Web and Linked Data could only be used by a tiny fraction of the user population. For most people, something which gets them most of the way (with a little bit of trial and error) is good enough. Fire and forget. While the snazzy solution with the sophisticated technology might demo well (making it good TED[8] fodder), it’s not going to improve the day-to-day travail for most of the population.

Then we get solutions like GovDirect. As the website puts it:

GovDirect® facilitates reporting to government agencies such as the Australian Tax Office via a single, secure online channel enabling you to reduce the complexity and cost of meeting your reporting obligations to government.

which make it, essentially, a Semantic Web solution. Except its not, as GovDirect is built on XBRL[9] with a cobbled together taxonomy.

Taxonomy driven solutions, such as GovDirect might not offer the power and sophistication of a Semantic Web driven solution, but they do get the job done. These taxonomies are also more likely to be ad hoc — codifying a vendor’s solution, or accreted whilst on the job — than the result of some formal, top down ontology[10] development methodology (such as those buried in the Semantic Web and Linked Data).

Take Salesforce.com[11] as an example. If we were to develop a taxonomy to exchange CRM data, then the most likely source will be other venders reverse engineering[12] whatever Salesforce.com is doing. The driver, after all, is to enable clients to get their data out of Salesforce.com. Or the source might be whatever a government working group publishes, given a government’s dominant role in its geography. By extension we can also see the end of the formal standardisation efforts of old, as they devolve into the sort of information frameworks represented by XBRL, which accrete attributes as needed.

The general trend we’re seeing is a move away from top-down, tightly defined and structured definitions of data interchange formats, as they’re replaced by bottom-up, looser definitions.

References
1. SemanticWeb.orgTim Berners-Lee on TwitterGovDirectPeter Williams on the The Power of Taxonomies @ the Australian Government’s Standard Business Reporting InitiativeLinkedData.orgAAIISPARQL @ w3.orgTEDeXtensible Business Reporting LanguageOntology defined in WikipediaSalesForce.comReverse engineering defined in Wikipedia↑

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

Our brand is worth everthing

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

I don’t know how many times I’ve heard that statement. Too many, I expect. Unfortunately it usually means that engaging with the root cause of the problem we’re trying to solve is too awkward or uncomfortable, so it’s time to reach for the magical (technological) pixie dust. The glib, absolute statement thrown onto the table is a flag that the root cause of the problem is cultural, or even a leadership issue. Solving the problem is going to require a bit more than a little technology delivered by smiling consultants.

Every couple of years I seem to come across another glib “Our brand is everything”. (Though, at the moment the rise of cloud computing is providing more “but its not secure” glibness than anything else.) I’ll be sitting around a table with some senior IT and business folk talking about a broken manual process. More often than not it will involve a workflow based on emailing spreadsheets around the team.

The risks are fairly obvious. Aside from the double entry problems and the risk of lost orders, there’s always the chance of litigation over an implied contract in some casually sent email (or tweet). There’s also the risk for a disenchanted insider sending something they shouldn’t to someone they should not.

After wandering around the issue for a little while, we start discussing possible solutions. My first question is usually something like “What resources are you willing to commit to solving the problem?” It’s at this point that the comment is thrown onto the table; usually in earnest. “Our brand is worth everything.”

Rather than go to the effort actually trying to engage with the problem we’re dealing with, the statement indicates the desire for a magical cure-all. If we sprinkle magical technology pixie dust over the problem then it will just go away.

Technology can only ever go so far to solving a problem. We can use technology to speed something up (swapping paper shuffling for bit shuffling). Or we can use technology to stop specific things from happening (i.e. enforcing governance policies). We can’t use it to prevent something we never imagined.

Most interesting problems — like the manual workflow example — are rooted in peoples’ behaviour, and only have a small technology element. While the action, the bad event might change in each instance, the intent behind the action is probably the same. Even if we were given a blank cheque (which is probably the next thing I should ask for), we can’t hope to make more than a small dent in the problem. It’s like squeezing a ballon in your fist. Each time we push in one bulge, another one (or two) pops up in a different gap.

If we want to have a significant impact, then we really need a mandate to change the way the organisation works. Are the organisations own policies actually incenting employees (or partners, or customers) to work against the best interests of the organisation? (Like the point guard mentioned in the No-stars, all-star[1] article.) Do the existing IT solutions cause more problems than they solve? Just why did the problem happen in the first place?

Even a mandate has its limits though. Ultimately the behaviour of an organisation is determined by the behaviour of its leaders. The behaviour that caused the problem was a result of the culture created within the organisation.

The most useful tool to solve this sort of problem is the time and attention of the leadership team, along with a willingness to admit that no one is perfect, that mistakes will happen, and a sincere desire to improve the organisation.

When someone drops “Our brand is worth everything” on the table these days, I like to point out that bad things can happen, and will always happen. We can use technology to trap a few things, but the only long term solution is to create an environment when everyone involved — all the way from employees through partners, channels and customers — is naturally inclined to do the right thing.

Yelp seem to be learning this the hard way[2]. Accidents will always happen, and speedy and considerate response is acknowledged as the best we can do. However, creating a culture where “doing the wrong thing for the wrong reason” is accepted will eventually get you in trouble that you might not be able to get out of.

And hence we arrive at the real problem. A brand’s worth, after all, is a measure of what people think of an organisation; both customers buying your products or services, or the investors who want to know where you”re going. When bad things happen, and sometimes they happen quite regularly, the only real long term solution is to change the way we manage the organisation so that the root cause is no longer present. This means the people at the top need to change what they are doing. And give that the rules of IT have changed[3], and we need to change with them.

References
1. The no-stars all-star @ The New York TimesInside Yelp’s “Blackmail” Lawsuit: CEO Stoppelman Seems to Hate His AdvertisersSome new rules for IT↑

Tags:

Vacuum flasks: fulfilling a need

2010/06/18 in Case Study, Innovation, Posterous by peg | View Comments

As seen on a plaque at Scienceworks in the House Secrets exhibit.

James Dewar invented the vacuum flask in 1892 to keep laboratory gases cold. Twelve years later, Reinhold Burger manufactured the Thermos to keep our picnic drinks hot.

A nice demonstration of the third of Peter Drucker’s seven sources of innovation.

Innovation based on process need.

Or, put another way, James Dewar scratched an itch; though he did play Edison to Reinhold Burger’s Sameul Insull.

Posted via web from PEG @ Posterous

Tags: , , , , , , , , ,

What I like about jet engines

2010/06/18 in Business-Technology, Case Study by peg | View Comments

Rolls-Royce[1] (the engineering company, not the car manufacturer) is an interesting firm. From near disaster in the 70s, when the company was on the brink of failure, Rolls-Royce has spent the last 40 years reinventing itself. Where it used to sell jet engines, now the company sells hot air out the back of the engines, with clients paying only for the hours an engine is in service. Rolls-Royce is probably the one of the cleanest examples of business-technology[2] that I’ve come across; with the company picking out the synergies between business and technology to solve customer problems, rather than focusing on trying to align technology delivery with a previously imagined production process to push products at unsuspecting consumers. I like this for a few reasons. Firstly, because it wasn’t a green fields development (like Craig’s List[3] et al), and so provides hope for all companies with more than a few years under their belt. And secondly, as the transformation seems to have be the result of many incremental steps as the company felt its way into the future, rather than as the result of some grand, strategic plan.

A Rolls-Royce jet engine

I’ve been digging around for a while (years, not months), looking for good business-technology case studies. Examples of organisations which leverage the synergies between business and technology to create new business models which weren’t possible before, rather than simply deploying applications to accelerate some pre-imagined human process. What I’m after is a story that I can use in presentations and the like, and which shows not just what business-technology is, but also contrasts business-technology with the old business and technology alignment game while providing some practical insight into how the new model was created.

For a while I’ve been mulling over the obvious companies in this space, such as Craig’s List or Zappos[4]. While interesting, their stories don’t have the impact that they could as they were green fields developments. What I wanted was a company with some heritage, a history, to provide the longitudinal view this needs.

The company I keep coming back to is Rolls-Royce. (The engineering firm, not the car manufacturer). I bumped into a story in The Economist[5], Britain’s lone high-flier[6], which talks about the challenge of manufacturing in Britain. (Which is, unfortunately, behind the pay wall now.) As The Economist pointed out:

A resurgent Rolls-Royce has become the most powerful symbol of British manufacturing. Its success may be hard to replicate, especially in difficult times.

With its high costs and (relatively) inflexible workforce, running an manufacturing business out of Britain can be something of a challenge, especially with China breathing down your neck. Rolls-Royce’s solution was not to sell engines, but to sell engine hours.

This simple thought (which is strikingly similar to the tail of the story in Mesh Collaboration[7]) has huge ramifications, pushing the company into new areas of the aviation business. It also created a company heavily dependent on technology, from running realtime telemetry around the globe through to knowledge management. The business model — selling hot air out the back of an engine — doesn’t just use technology to achieve scale, but has technology woven into its very fabric. And, most interestingly, it is the result of tinkering, small incremental changes rather than being driven by some brilliant transformative idea.

As with all these long term case studies, the Rolls-Royce story does suffer from applying new ideas to something that occurred yesterday. I’m sure that no one in Rolls-Royce was thinking “business-technology” when the company started the journey. Nor would they have even thought of the term until recently. However, the story still works for me as, for all it’s faults, I think there’s still a lot we can learn from it.

The burning platform was in the late 60s, early 70s. Rolls-Royce was in trouble. The company had 10% market share, rising labour costs, and was facing fierce competition from companies in the U.S. Even worse, these competitors did not have to worry about patents (a hangover from the second world war), they also had a large domestic market and a pipeline of military contracts which put them in a much stronger financial position. Rolls-Royce had to do something radical, or facing being worn down by aggressive competitors who had more resources behind them.

Interestingly, Roll-Royce chose to try and be smarter than the competition. Rather than focus on incremental development, the company decided to designed a completely new engine. Using carbon composite blades and a radical new engine architecture (three shafts rather than two, for those aeronautical engineers out there) their engine was going to be a lot more complex to design, build and maintain. It would also be a lot more fuel efficient and suffer less wear and tear. And it would be more scalable to different aircraft sizes. This approach allows Rolls-Royce to step out of the race for incremental improvements in existing designs (designing a slightly better fan blade) and create a significant advantage, one which would take the company’s competitors more than the usual development cycle or two to erase.

Most of the margin for jet engines, however, is in maintenance. Some pundits even estimate that engines are sold at a loss (though the manufactures claim to make modest margins on all the engines they sell), while maintenance can enjoy a healthy 35%. It’s another case of give them the razor but sell them the razor blades. But if you give away the razors, there’s always the danger that someone else may make blades to fit your razor. Fat margins and commoditized technology resulted in a thriving service market, with the major engine makers chasing each other’s business, along with a horde of independent servicing firms.

Rolls-Royce’s interesting solution was to integrate the expertise from the two businesses: engine development and servicing. Rather than run them as separate businesses, the company convinced customers to pay a fee for every hour an engine was operational. Rather than selling engines, the company sells hot air out the back of an engine. This provides a better deal for the customers (pay for what you use, rather than face a major capital expense), while providing Rolls-Royce with a stronger hold on its customer base.

Integrating the two business also enabled Rolls-Royce to become better at both. Maintenance data helps the company identify and fix design flaws, driving incremental improvements in fuel efficiency while extending the operating life (and time between major services) tenfold over the last thirty years. It also helps the company predict engine failures, allowing maintenance to be scheduled at the most opportune time for Rolls-Royce, and their customers.

Rolls-Royce leveraged this advantage to become the only one of the three main engine-makers with designs to fit the three newest airliners in the market: the Boeing 787 Dreamliner, the Airbus A380 and the new wide-bodied version of the Airbus A350. Of the world’s 50 leading airlines, 45 use its engines.

Today, an operations centre in Derby assess, in real time, the performance of 3,500 jet engines enabling to Rolls-Royce to spot issues before they become problems and schedule just-in-time maintenance. This means less maintenance and more operating hours, fewer breakdowns (and, I expect, happier customers), and the operational data generated is fed back into the design process to help optimise the next generation of engines.

This photograph is reproduced with the permission of Rolls-Royce plc, copyright © Rolls-Royce plc 2010

Rolls-Royce civil aviation operations in Derby

This service-based model creates a significant barrier to competitors for anyone who wants to steal Rolls-Royce’s business. Even if you could clone Rolls-Royce’s technology infrastructure (hard, but not impossible), you would still need to recreate all the tacit operational knowledge the company has captured over the years. The only real option is to recreate the knowledge yourself, which will take you a similar amount of time as it did Rolls-Royce, while Rolls-Royce continues to forge ahead. Even poaching key personnel from Rolls-Royce would only provide a modest boost to your efforts. As I’ve mentioned before[8], this approach has the potential to create a sustainable competitive advantage.

While other companies have adopted some aspects of Rolls-Royce’s model (including the Joint Strike Fighter[9], which is being procured under a similar model), Rolls-Royce continues to lead the pack. More than half of its existing engines in service are covered by such contracts, as are roughly 80% of those it is now selling.

I think that this makes Rolls-Royce a brilliant example of business-technology in action. Rolls-Royce found, by trial and error, a new model that wove technology and business together in a way that created an “outside in” business model, focused on what customers what to buy, rather than on a more traditional “inside out” model based on pushing products out into the market that the company wants to sell. You could even say that it’s an “in the market” model rather than a “go to market” model. And they did this with a significant legacy, rather than as a green fields effort.

In some industries and companies this type of “outside in” approach was possible before advent of the latest generation of web technology, particularly if it was high value and the company already had a network in place (such as Rolls-Royce success). For most companies it is only now becoming possible with business-technology along with some of the current trends, such as cloud computing, which erase many of the technology barriers.

The challenge is to figure out the “in the market” model you need, and then shift management attitude. Given constant change in the market, this means an evolutionary approach, rather than a revolutionary (transformative) one.

References
1. Rolls RoyceBusiness-Technology defined @ ForresterCraig’s listZapposThe EconomistBritain’s lone high-flier @ The EconomistMash-Up CorporationsOne of the only two sources of sustainable competitive advantage available to us today @ PEGThe Joint Strike Fighter↑

Tags: , , , , , , , ,

Some new rules for IT

2010/06/15 in IT Strategy, Mailing List by peg | View Comments

The other week I had a go at capturing the rules of enterprise IT[1]. The starting point was a few of those beery discussions we all have after work, where we came to wonder how the game of enterprise IT was changing. It’s the common refrain of big-to-small, the Sieble to Saleforce.com transition which sees the need for IT services (internal or external) change dramatically. The rules of IT are definitely changing. Now that I’ve had a go at old rules, I thought I’d have a go at seeing what the new rules might be.

As I mentioned before, enterprise IT has historically been seen as an asset management function, a production line for delivering large IT assets into the IT estate and then maintaining them. The rules are the therefore rules of business operations. My attempt at capturing 4 ± 2 rules (with friends) produced the following (in no particular order):

  • Keep the lights on. Much like being a trucker, the trick is to keep the truck rolling (and avoid spending money on tyres). Otherwise known as smooth running applications are the ticket to the strategy table.
  • Save money. Business IT was born as a cost saving exercise (out with the rooms full of people, in with the punch card machines), and most IT business cases are little different.
  • Build what you need. I wouldn’t be surprised if the team building LEO[2] blew their own valve tubes. You couldn’t buy parts of the shelf so you had to make everything. This is still with us in some organisations’ strong desire to build – or at least heavily customise – solutions.
  • Keep the outside outside. We trust whatever’s inside our four walls, while deploying security measures to keep the evil outside. This creates an us (employees) and them (customers, partners, and everyone else) mentality.

Things have changed since these rules were first laid down. From another post of mine on a similar topic[3] (somewhat trimmed and edited):

The recent global financial criss has fundamentally changed the business landscape, with many are even talking about the emergence of a new normal[4]. We’ve also seen the emergence of outsource, offshore, cloud computing, SaaS, Enterprise 2.0 and so much more.

Companies are becoming more focused, while leaning more heavily on partners and services companies (BPO, out-sourcers, consultants, and so on) to cover those areas of the business they don’t want to focus on. We can see this from the global companies who have effectively moved to a franchise model, though to the small end of town where startups are using on-line services such as Amazon S3, rather than building their own internal capabilities.

We’re also seeing more rapid business change: what used to take years now takes months, or even weeks. The constant value-chain optimisation we’ve been working on since the 70s has finally cumulated in product and regulatory life-cycles that change faster than we can keep up.

Money is also becoming (or has become) more expensive, causing companies and deals to operate with less leverage. This means that there is less capital available for major projects, pushing companies to favour renting over buying, as well as creating a preference for smaller, incremental change over the major business transformation of the past.

And finally, companies are starting to take a truly global outlook and operate as one cohesive business across the globe, rather than as a family of cloned business who operate more-or-less independently in each region.

So what are the new 4 ± 2 rules? They’re not the old rules of asset management. We could argue that they’re the rules of modern manoeuvre warfare[5] (which would allow me to sneak in one of my regular John Boyd references[6]), but that would be have the tail wagging the dog as it’s business, and not IT that has that responsibility.

I think that the new rules cast IT as something like that of a pit crew. IT doesn’t make the parts (though we might lash together something when in a pinch), nor do we steer the car. Our job is to swap the tyres, pump the fuel, and straighten the fender, all in that sliver of time available to us, so that the driver can focus on their race strategy and get back out on track as quickly as possible.

With that in mind, the following seems to be a fair (4 ± 2) minimum set to start with.

  • Timeliness. A late solution is often worse than no solution at all, as you’ve spent the money without realising any benefit. Or, as a wise sage once told me, management is the art of making a timely decision, and then making it work. Where before we could take the time to get it right (after all, the solution will be in the field for a long time and needs to support a lot of people, so better to discover problems early rather than later), now we just need to make sure the solution is good enough in the time available, and has the potential to grow to meet future demand. The large “productionisation” efforts of the past need to be broken into a series of incremental improvements (à la Gmail and the land of perpeputal beta), aligning investment with both opportunity and realised value.
  • Availability. Not just up time, but ensuring that all stakeholders (both in and outside the company, including partners and clients) can get access to the solutions and data they need. There’s little value in a sophisticated knowledge base solution if the sales team can’t use it in the field to answer customer questions in real time. Once they’ve had to fire up the laptop, and the 3G card, and the VPN, the moment has passed and the sale lost. Or worse, forcing them to head back to the bricks and mortar office. As I pointed out the other week, decisions are more important than data[7], and success in this environment means empowering stakeholders to make the best possible decisions by ensuring that the have the data and functions they need, where they need, when they need it, and in a format that make it easy to consume.
  • Agility. Agility means creating an IT estate that meet the challenges we can see coming down the road. It doesn’t mean creating an infinitely flexible IT estate. Every bit of flexibility we create, every flex point we add, comes at a cost. Too much flexibility is a bad thing[8], as it weighs us down. Think of formula one cars: they’re fast and they’re agile (which is why driving them tends to be a young mans game), and they’re very stiff. Agility comes from keeping the weight down and being prepared to act quickly. This means keeping things simple, ensuring that we have minimum set of moving parts required. The F1 crowd might have an eye for detail, such as putting nitrogen[9] in the tyres, but unnecessary moving parts that might reduce reliability or performance are eliminated. Agility is the cross product of weight, speed, reliability and flexibility, and we need to work to get them all into balance.
  • Sustainability. Business is not a sprint (ideally), and this means that cost and reliability remain important factors, but not the only factors. While timeliness, availability and agility might be what drive us forward, we need still need to ensure that IT is still a smooth running operation. The old rules saw cost and reliability as absolutes, and we strived to keep costs as low, and reliability as high, as possible. The new rules see us balancing sustainability with need, accepting (slightly) higher costs or lower reliability to provide a more timely, available or agile solution while still meeting business requirements. (I wonder if I should have called this one “balance”.)

While by no mean complete or definitive, I think that’s a fair set of rules to start the discussion.

References
1. The rules of Enterprise IT @ PEGLEO: Lyons Electronic Office. The first business computer. @ WikipediaThe IT department we have today is not the IT department we’ll need tomorrow @ PEGThe new normal @ McKinsey QuarterlyManeuver warfare @ WikipediaJohn Boyd @ WikipediaDecisions are more important than data @ PEGHaving too much SOA is a bad thing (and what we might do about it) @ PEGUnderstanding the sport: Tyres @ formula1.com↑

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

The rules of enterprise IT

2010/06/08 in IT Strategy by peg | View Comments

As I’ve pointed out before (possibly as I’m quite fond of games[1]) the game of enterprise IT has a long an proud history. I’ve also pointed out that the rules of this game need to change if enterprise IT — as we know it — is to remain relevant in the future[2]. This is triggered a few interesting conversations at the pub on just what are the old rules of IT.

Enterprise IT, as we know it today, is an asset management business, the bastard son of Henry Ford’s moving production line. Enterprise IT takes the raw material of business processes and technology and turns them into automated solutions. From those first card tabulators through to today’s enterprise applications, the focus has been on delivering large IT solutions into the business.

The rules of enterprise IT are the therefore rules of business operations. After a fair amount of coffee and beer with friends, the following 4 ± 2 rules seems to be a fair minimum set (in no particular order).

Keep the lights on. Or, put more gently, the ticket to the strategy table is a smooth running business. Business has become totally reliant on IT, while at the same time IT is still seen as something of a black art run by a collection of unapproachable high priests. The board might complain about the cost and pain of an ERP upgrade, but they know they have to find the money if they want to successfully close the books at the end of the financial year. While this means that the money will usually be found, it also means that the number one rule of being a CIO is to keep the transactions flowing. Orders must be taken, products shipped (or services provided), invoices sent and cash collected. IT is an operational essential, and any CIO who can’t be trusted to keep the lights on won’t even have time to warm up their seat.

Save money. IT started as a cost saving exercise: automatic tabulation machines to replace rooms full of people shuffling papers, networks to eliminate the need to truck paper from one place to another. From those first few systems through to today’s modern enterprise solutions, applications have been seen as a tool to save time and money. Understand what the business processes or problem is, and then support the heavy information lifting with technology to drive cost savings and reduce cycle time. Business cases are driven by ideas like ROI, capturing these savings over time. Keep pushing the bottom line down. These incremental savings can add up to significant changes, such as Dell’s make-to-order solution[3] which enabled the company to operate with negative working capital (ie. they took your cash before they needed to pay their suppliers), but the overall approach is still based on using IT to drive cost savings through the automation of predefined business processes.

Build what you need. When applications are rare, then building them is an engineering challenge. You can’t just go to the store and by the parts you need, you need to create a lot of the parts yourself in your own machine shop. I remember the large teams (compared to today) from the start of my career. A CORBA project didn’t just need a team to implement the business logic, it needed a large infrastructure team (security guy, transaction guy …) as well. Many organisations (and their strong desire to build – or at least heavily customise – solutions) still work under this assumption. IT was the department to marshal large engineering teams who deliver the industrial grade solutions which can form the backbone of a business.

Ferrero Rocher

Crunch on the outside, soft and chewy in the middle.

Keep the outside outside. It’s common to have what is called a Ferrero Rocher[4] approach to IT: crunchy on the outside while soft and chewy in the middle. This applies to both security and data management. We visualise a strong distinction between inside and outside the enterprise. Inside we have our data, processes and people. Outside is everyone else (including our customers and partners). We harvest data from our operations and inject it into business intelligence solutions to create insight (and drive operational savings). We trust whatever’s inside our four walls, while deploying significant security measures to keep the evil outside.

It’s a separate question of whether or not these rules are still relevant in an age when business cycles are measured in weeks rather than years, and SaaS and cloud computing are emerging as the dominate modes of software delivery.

References
1. Capitalise: A game for the whole company to play!People don’t like change. (Or do they?)Dell’s make to order solution leaves competitors in the dust.Ferrero↑

Tags: , , , , ,

« Older entries