Category Archives: Mailing List

The north-south divide

Note: This is the third part of a longer series on how social media is affecting management. You can find the earlier posts – The future of (knowledge) work and Knowledge Workers in the British Raj – and subsequent posts – Working in Hollywood, World of Warcraft in the workplace and Problems and the people who solve them – elsewhere on this blog.

Developing and manufacturing a product, and delivering it to the waiting customer, has historically been a significant expedition. We would establish a series of camps – departments, containing the tools and skills needed – along the route from start to finish to support us as we ferried the materials we needed from their source to where they were required. However, the assumptions that drove this behaviour are no longer true. Where previously materials, skills and tools were all in short supply, today we can usually find what we need lying on the ground near where we stand. Developments such Strategic Sourcing{{2}}, Business Process Outsourcing{{3}} (BPO), and Social Media have removed the need for us to carry what we need with us, and has been the trigger for us to start dismantling those departments that we no longer need.

[[2]]Strategic Sourcing defined at Wikipedia[[2]]
[[3]]Business Process Outsourcing defined at Wikipedia[[3]]

The large bureaucracies companies have traditionally required are slowly being collapsed, hollowed out, as we find that we can achieve the same result more efficiently with smaller and more agile organisations. Companies are starting to use a more alpine style{{4}} of operation, leveraging a small carefully, chosen team with more flexible tooling, and relying their own wits to survive in a rapidly changing and uncertain environment. This shift is pushing us to rethink the nature and organisation of our businesses, setting aside many of the specialised departments and resources we relied on in the past to find a new organising principle. The impact will be both subtle and dramatic, with business continuing to do what business does (constrained, as it is, by government and market regulation) while the roles we all play as individuals change dramatically in response.

[[4]]Alpine style climbing defined at Explore Himalaya[[4]]

An interesting thought experiment is to compare the companies we work in to the societies we inhabit. After all, companies are really just small (and some not so small) societies, with all the dynamics and politics of a community of a similar size. The nature of both societies and companies is largely determined by the tools they use{{5}}, as it is these tools that determine how the community functions. Agriculture, for example, requires a society to be stationary and drove the creation of property ownership, while the telegraph enabled the creation of new business models by separating, for the first time, the transmission of information from the carriage of goods, and gave the world Reuters{{6}}. The tools and technologies we use determine the nature of the societies and companies we inhabit.

[[5]]Timothy Taylor (2010), The Artificial Ape: How technology created humans, Palgrave Macmillan[[5]]
[[6]]The history of Thomson Reuters[[6]]

Historically, societies can be broken into two rough technological groups: equatorial and seasonal. Equatorial societies exist somewhere near the equator, living in a climate that varies little throughout the year, other than in the amount of rainfall they receive. Seasonal societies live some distance from the equator in a more temperate climate, a climate that provides them with distinct seasons over the length of the year. The further north or south you go from the equator, the more seasonal the climate becomes.

The climate a society lives in has a strong influence on the type and nature of technologies that it uses. The orthodox strategy in a seasonal climate is to tailor specific toolkits to the challenges faced in each season of the yearly cycle; jackets in winter and shorts in summer. When it becomes extremely cold, it’s wise to bring along the sleds, snowshoes and heavy clothing. However, when it’s warm these the tools in this toolkit are somewhat less useful. Many tools fulfil a specific, and important need at one point in the seasonal cycle, but this also means that we have little use for the tool in the remainder of the year.

Societies in more tropical climates typically adopt a different strategy. Their focus is on creating a single toolkit that has a smaller number of simpler, but more flexible tools. They have little need for specialised tools, as the climate they live in is relatively stable over the year, which means that their success (or failure) depends on their ability to adapt to unanticipated disturbances or unexpected opportunities as they present themselves. While they are not concerned about stockpiling food to survive through a cold winter, they do need to be able to adapt to the sudden appearance of a cyclone. When a cyclone strikes you rarely have time to go and grab a cyclone proof shelter, and you need to be ready to pick up and use the fallen coconuts once the wind had passed. You must to make do with what you have.

In the former, seasonal societies, the emphasis is on the gear. If the gear fails then you do too, often with fatal consequences. This drives you to invest a significant amount of your time and effort into ensuring that the gear can’t fail, striving to add enough nines to the end of that reliability measure to ensure that you’re not left out in the cold. The technologies you develop are complex and highly entailed, addressing specific needs and requiring a long a sophisticated chain of skills, materials and tools to manufacture.

In the latter, equatorial societies, the emphasis is on skill. Your fate is determined by your ability to adapt the resources and tools found in the immediate vicinity to the problem at hand. The tools you need are simple and flexible, either lightweight and compact enough to carry with you or based on technologies which enable you to manufacture them from whatever materials you have at hand. These technologies are only lightly entailed, addressing general needs and requiring a relatively short chain of skills, materials and tools to manufacture.

Companies have traditionally been organised along similar lines to the seasonal societies. The pulse of business beat slowly, and our main concern was to address the specific challenges that existed in each season of this regular cycle. These challenges were also complex and highly entailed, requiring large toolboxes with specialised tools and skills that are highly interdependent. Success depended on the quality of our assets and processes, and our focus was on mobilising enough people and technology to create and staff the processes we needed.

Take, for example, LEO (the Lyons Electronic Office), which may well be the first business computer. Unable to buy a beige box from the local electronics shop, the team at Lyons had to build their computer from scratch, requiring a large team with a number of specific and specialised skills, and three years of effort. I wouldn’t be surprised if they were forced to blow their own vacuum tubes. The result was a machine that, in 1953, could calculate a person’s pay in 1.5 seconds, rather than the eight minutes taken by an experienced clerk. LEO was a long and highly entailed investment.

LEO, the Lyon's Electronic Office, in 1951
LEO, the Lyon's Electronic Office, in 1951

However, since then the pulse of business has increased dramatically. Over the last few decades we’ve gone from worrying about decades to years, and more recently to months and weeks. Soon we might even be worrying about days. The seasons in business are changing so quickly that we are finding it difficult to keep up{{7}}. Our business environment is, in fact, starting to look more like the environment the equatorial societies inhabit rather than the more temperate climes of old: a relatively stable progression over the year, but with a pressing need to adapt to the unexpected disturbances and opportunities as they present themselves.

[[7]]Why we can’t keep up @ PEG[[7]]

At the same time, the nature of the environment our businesses function in has changed dramatically. Many of the skills and tools we fought hard to obtain can now be easily picked up where we stand. From global logistics providers and contract manufactures, through outsourcing, the various consultancies and software as a service, most of what we require can be easily picked off the ground when we need it. LEO doesn’t hold a candle to many of the bureau and SaaS payroll solutions that we can use on demand.

What we need is a more equatorial approach to organising our business, one more in line with reality of the business environment we operate in today. This means stocking our organisation with a small collection of flexible, but potent, people that can rapidly adapt to our changing needs, people who can use a small set of flexible tools to respond to the challenges and opportunities presented to us. It involves pulling down our highly entailed bureaucracies and connecting the C-level with the team at the front line. Overhead functions such as IT and HR will be torn down. (After all, if all our IT exists in the cloud and our company is hollowed out, removing the bulk of our bureaucracy, then we don’t need these departments anymore.) The old value producing functions (manufacturing and so on) will be externalised and bought as a service. More than anything, our success will depend on our ability to mobilise – both as an organisation and as individuals – and adapt the resources and tools in the immediate vicinity to the problem at hand.

This requires a huge shift in how we think about staffing our organisations. Deep specialisation is no longer the benefit it was in the past. While specialisation brings knowledge and insight, it also (typically) reduces flexibility and adaptability. Someone with a decade or more invested in being an IT architect, sales manager, change agent, human capital management expert, process wizard or (even a) social media guru, needs to protect that investment. Their value is in their specialisation; they will defend the status quo and resist being pulled away from what makes them valuable{{8}}. The people we need are sun-shaped{{9}}. They’re highly skilled (though not highly specialised), focused on solving a problem we have, and bring with them a diverse toolkit of simple but flexible tools.

[[8]]From doctrine to dogma @ PEG[[8]]
[[9]]The sun-shaped individual @ PEG[[9]]

Continued in Working in Hollywood.

The future of (knowledge) work

Note: This is the first part of a longer series on how social media is affecting management. I started writing the following to explore a vague idea and see where it might take me, and first stopped writing when it was roughly three thousand words. At that length it was quite a bit weightier than the average blog post – and far too long to read in a lunch break – so I’ve decided to break it into a number of smaller. The first is below, and you can find the other issues – Knowledge workers in the British Raj, The north-south divide, Working in Hollywood, World of Warcraft in the workplace and Problems and the people who solve them – elsewhere on this blog.

What impact will social media have on how you run your business? It’s being touted as everything from a better form of groupware or the next step in the evolution of work management — a new layer on the technology stack that’s starting to be called human interaction management{{1}} (HIM), sitting on top of, and bringing together, BPM, workflow and case management — through to a wholesale transformation of the way your business operates and is organized. Reality (as usual) rests somewhere between the two extremes.

[[1]]Human Interaction Management[[1]]

Are the inmates taking over the asylum?

Social media (Web 2.0, Enterprise 2.0, Social Business Design, and so on) seem to be triggering a change in the command and control structures that we have traditionally used to manage our companies. There is an ongoing discussion within the human resources community concerning what form our future organizations will take{{2}}. The key drivers are streamlined communication from social media, both within and without the organization, and the empowerment of the frontline and delegation of authority due to the increasing need to solve problems promptly within a local context.

[[2]]“Social” is now HR’s baby (sorry Marketing Department) @ Fistful of Talent[[2]]

Old power structures seem – in some cases – to be in the process of being inverted as the people at the front line find that they are now better informed and equipped than their management to solve the majority of the problems confronting the business. If people are your most important asset, then we might just be standing at the start of a revolution as the workers realize that they really do control the means of production.

Wholesale revolution is unlikely though. While employees might be an important asset, and one that has a significant impact on the overall performance of your organization, they are not the asset a business is built to support{{3}}. For many organizations the best result is usually to remove the people, such as with lights-out factories, or some of the new SaaS plays which are replacing people-driven BPO with automated self-service solutions. The dirty secret of Enterprise 2.0 is that it’s being used the same way as every other technology to date: it’s being used to remove people from the equation.

[[3]]Why Enterprise 2.0 and Social Business Design might be of marginal utility for most of us @ PEG[[3]]

On the other hand, it has become obvious that social media is having an effect on our organizations. A key assumption behind most organizational structures is that information is rare and expensive to obtain, pushing us to create organizations that gather information from the front line and aggregate it up to the CEO. This also means that information is the currency of company politics. However, with social media and the Internet information is now – on the whole – cheap and easily obtainable. Controlling the flow of information is no longer possible, leading us to think some amount of disruption of the current order is inevitable as the old power dynamics are destroyed and new ones formed.

One thing is clear though: we need to think about work – and the teams and organizations we construct to support it – differently. The formal, siloed structures we find in many organizations don’t map well to the more dynamic environment that social media is bringing to business. Many businesses now have more in common with the British Civil Service in India – flat structures where the people at the coal face work largely under their own direction, collaborating with others as required – than the vertically integrated titans of industry from recent time.

Computer: an electronic device for storing and processing data

Companies have changed dramatically since the days when the term computer referred to someone who manually computed mathematical functions. Technology has slashed the number of people required to support most, if not all, tasks in the enterprise, making today’s companies dramatically smaller and more agile than their forebears. What used to take rooms full of people now needs – at the most – a small team. This is true across the full depth and breadth of our organizations, from the mailroom and typing pool, finance calculating the payroll through to the production floor in the factory.

Williamina Fleming (standing) with her computers in the late 1800s
Williamina Fleming (May 15, 1857 – May 21, 1911, standing) with her computers in the astronomy department at Harvard in the late 1800s, hired to carry out the mathematical calculations required to classify stars.

Not only has the volume of manual work changed, but the nature of that work has also changed with it. We used to deploy our employees to run the business, focused on the carrying out the plethora of operational tasks required to keep the wheels of commerce turning. Automation through technology has largely taken care of this.

With payroll and the shop floor dealt with, our employees are now more concerned with improving and guiding the business. For many companies the center of gravity of their workforce has shifted away from operations, moving to roles more concerned with the performance of the business: supervisory, design, business improvement and customer engagement.

Supermarkets, for example, have been hollowed out by modern management practices. In the past, store managers were masters of their own domain, held accountable for profit-and-loss and not much else. Today, the only real freedom many store managers have is in hiring the team who staff the checkouts, and keeping them motivated. The vast majority of decisions required to run the store have either been pulled up to head office (such as store layout and pricing moving to a centralized category management team{{4}}) or delegated to suppliers or the staff at the front line{{5}} (determining when to restock, for example).

[[4]]What is Category Management @ Category Management Association[[4]]
[[5]]What we’re doing today is not what we did yesterday @ PEG[[5]]

This makes projects the focus of many modern workplaces: projects to improve systems and processes, projects to bring new products to market, projects to expand into new territories, projects to optimize our product portfolio, and so on. One of the main short-term drivers for adopting social media in the enterprise is supporting work in these projects by providing the workers within them with a better way collaborating and searching for answers to the problems they have.

However, while the demand for work on projects has grown, the size of the teams required to deliver our projects has shrunk. Initiatives which required one hundred people and a billion dollar investments in the fifties, sixties and seventies, can now be delivered by team sizes in the low double digits, if not less than ten people.

The number and variety of careers – the professional community – supported by these projects has shrunk in response. This started with the specialists, but soon moved on to more general disciplines. For example IT platforms and frameworks used in the enterprise today have eliminated much of the need for specific technical specialists (there’s not much requirement for a distributed transaction specialist on most projects now). Some of the new frameworks eliminate the need for even quite common skills, as with databases and Ruby on Rails.

Flat, but not quite flat as it could be

Social media – as with many of the technologies preceding it – streamlines previously manual tasks by capturing knowledge in a form where it is easily reusable, shareable and transferable. What is different this time is that social media is focused on the communication between individuals, rather than the tasks these individuals work on. By simplifying the process of staying in touch and collaborating with a large number of people it enables us to flatten our organizations even further, putting the C-suite directly in contact with the front line.

This is having the obvious effect on companies, eliminating the need for many of the bureaucrats in our organizations; people whose main role is to manage communication (or communication, command and control, C3, in military parlance{{6}}). The big winners from social media will not be, as we first thought, those white-collar knowledge workers who spend their days herding those at the coalface, crafting policies, and worrying about organizational dynamics. The winners will be the team at the frontline and C-suite, as they both bypass the (soon to be removed) mid-level functionaries and engage with each other directly{{7}}.

[[6]]C3 defined @ Wikipedia[[6]]
[[7]]Rise of the task-worker 2.0 @ PEG[[7]]

The net effect of all this is that our organizations and teams are being hollowed out as the middle layers are replaced with software{{8}}. To some extent the chickens have come home to roost; technologies that replaced the people at the operational coalface are now being used to replace the people in the project teams that brought these technologies to the enterprise in the first instance.

[[8]]The IT department we have today is not the IT department we’ll have tomorrow @ PEG[[8]]

Continued in Knowledge workers in the British Raj.

Cloud computing’s long game

For as long as we can remember, technology’s role has been to support business. Identify your target market, product and goals, map out the required business model and then line up technology behind the various activities to drive cost savings and provide scale.

For many people, cloud computing (and it’s evil twin, software as a service) is the ultimate expression of this approach — information technology as a cheap, efficient and flexible utility grade service: utility computing. Just like electricity or gas, we simple turn on the tap (or hit the light switch) when we want some, and the hole in the wall will provide as much as we need.

Many people struggle to look beyond the utility computing analogy, with Jeff Bezos and Eric Schmitt acting as modern day Samuel Insulls{{1}}, striding across the technology landscape as they build their utility computing networks. This is a view that also equates utility computing with fractionally owned (or leased), multi-tenanted applications and infrastructure deployed at a scale never imagined preciously. Computing that is too cheap to meter.

[[1]]Samuel Insull @ Chicago “L” .org[[1]]

Utility computing, however, seems to offer a much grander opportunity. When coupled with globalization, utility computing offers us the ability to change the way we think about constructing and managing a company.

Our existing business models are founded on the assumption of needing to manage scarce resources, focused on building command and control structures around leveraging a centrally owned asset. This asset might be monetary deposits, knowledge (often reified through patents), or something physical like a factory or fleet of trucks. Our biggest challenge is marshaling the resources we need to ensure that enough work was done, and the asset provides us with a lodestone to help attract and manage these resources.

Utility computing and globalization enables us to think about this problem in a different way. By providing us with computing power and labor on demand, our main concern becomes what product to deliver (with a second order challenge of where to deliver it), rather than how the product is created.

Zara, a fashion retailer, provides us with a glimpse of the future. Zara has created a pull model where the organization is built around reducing the time from runway to retail{{2}}. Decisions on what products to produce has been devolved to individual stores who pull in the inventory they think they will sell, rather than head office presenting retail stores with the latest collection. New products rotate through the shelves in matter of weeks, pulled by customer demand, rather than following the seasonal cycle traditional in the industry.

[[2]]Kasra Ferdows, Michael A. Lewis and Jose A.D. Machuca (2005), Zara’s secret for fast fashion, Harvard Business Review[[2]]

Rapid turnover of products has driven new behavior in Zara’s customers. Customers now visit their local store every week or so, rather than once a quarter, as they are interested in seeing what new products have arrived, slashing Zara’s marketing spend in the process. There’s also a stronger imperative for customers to make an impulsive decision, as they know that the same product will not be in the store when they next visit.

Zara’s approach has made them one of the most successful fashion retailers in the world.

Today’s business models are the culmination of generations of incremental improvements, as successive generations of managers have tweaked their business in an attempt to reach the customer just a little faster than the competition. The first challenge we solved was the one of mass: ensuring that we have enough products available to service the customer, if they choose us. More recently we’ve worried about velocity: aiming to get our product to the customer just when they need it, rather than having to hold stock near the customer on the chance that they might want something we product. The next challenge (as exemplified by Zara) is acceleration: being able to redesign our products rapidly enough to follow customer demands as they evolve.

Utility computing and globalization can provide us with the tools to complete the journey that companies like Zara have started. By commoditizing the basic building blocks of a business — materials, labor and communication — they provide us with the opportunity to make our business models fungible. Why stop at rapidly redesigning our products? Why not dynamically reconfigure our supply chain, following our customers as they move around? Or even rapidly reconfigure our entire value chain, if need be?

The centre of gravity within companies – which for centuries have been built around the management of a central asset held by the company – is shifting. The new centre of organizational gravity will be the ability to rapidly plan and mobilize a critical mass of stakeholders, leveraging staff and assets which you many not even own or directly control.

An agile business will be one that can rapidly evolve its product portfolio to follow customer demand. One that can quickly reconfigure how materials are sourced, products are manufactured and customers are served, across the full breadth of the value chain, allowing it to sail through disruptions that leave competitors stranded. One that can dynamically reconfigure the end-to-end supply chain, delivering the right product to the right customer, just when they realize they need it (or even before they come to this realization). One that can rapidly enter and leave markets and geographies, as need be. And one that can do all of this with resources and services that it does not explicitly own or manage. A company that is built around its ability to mobilize its staff, partners and even its customers. This is the opportunity provided to us by utility computing and globalization.

Innovation [2010-11-29]

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

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

The myth of the inevitability of social organisations

In the rush for the new-new thing we’re confusing the means with the end. Business – as currently practiced – has been built around the need to own and manage a central asset. This might be a factory, some IP or even a skilled team. The tools, technologies, and methods we deploy in business are used as they cause the business (the asset) to perform better: bottom line down or top line up, simple stuff. This seems to have been forgotten. Some of the newer tools – such as social business design – can add value in this content, but they are only tools. If they make sense and add value, then they will be adopted. If not, then they will wither and die. For many companies, it looks like they will only provide marginal utility.

Martin Linssen{{1}} seems to have started something of a storm on the Internet by pointing out that the emperor has no clothes{{2}}. He was responding to the noise around “social business design” and “enterprise 2.0”. Dennis Howlett{{3}} then published a nice missive{{4}} that builds on Martin’s observation.

[[1]]Martin Linssen[[1]]
[[2]]the emperor has no clothes[[2]]
[[3]]Dennis Howlett[[3]]
[[4]]Enterprise 2.0 is beyond a crock. It’s dead.[[4]]

The clarity Dennis brought was to highlight that, in the quest for the new-new thing, many marketing machines and practitioners have forgotten that for these tools to be adopted they need to add value, and that it’s hard for them to add value in the command-and-control structures that exist in most companies.

As Dennis astutely said:

When you get down to the nuts and bolts of the problems that prof McAfee correctly identifies but for which no amount of technology will solve it is really simple: the kinds of management and structures you need in order to make these ideas work in a sustainable manner is almost non-existent. Command, control, power and status have a huge part in this. And no amount of putting lipstick on those organisational pigs will change the fundamentals. In one well known case I still see individuals being taken to one side and asked: “Did you really have to say that? It’s not what we expect from people in your position.” Insidious isn’t it?

Today’s business are built around the concept of managing a central asset. This asset might be a factory, it might be a fleet of trucks, the deposits from a community of investors, it might be the methodology and tools a skilled team use, or it might be a brand. Regardless, structures are defined and people hired to support and drive this central asset, and not for any other reason.

Some companies, such as Zappos, have successfully used tools like social media to drive value by improving customer service and reaching customers earlier in the buying process. The problem is that companies Zappos and its ilk only represent a small proportion of the business community.

Think of the contract manufacturers who make the clothing that Zappos sells, or the outsourcers who run the supply chains to and from Zappos’ warehouse. These companies are trying to sweat an asset – the factory or a fleet of trucks and planes – and are usually chasing costs, often by moving to second or third world countries where wages are lower, or by automating first world jobs.

It’s the need to manage a central asset that has driven them to create these vertical command-and-control structures. Sometime the nature of this asset is compatible with the trendy new method – as with Zappos, social business design and enterprise 2.0 – but often it’s not. Yes, these companies could be better run (strangely enough, most companies are average), however, telling these companies to up-end their business models just doesn’t make sense. They’re focused on managing that central asset and there is currently no proof that these new techniques can do that any better than existing practices. As Dennis pointed out, the kinds of management structures to use these new tool in this context don’t currently exist.

Unfortunately the pundits are assuming that a few exceptional companies and individuals represent something the general business community should adopt as is. They are also mistakenly assuming that the claimed benefits – such as “improved communication and customer engagement” – requires us to deploy their favourite technology, tool or methodology.

Quest for the new-new thing
Quest for the new-new thing

Being better at the basics is more important. I know one executive that I had enough trouble convincing to get out of the office to say “Hi!” to his team who were only ten minutes away: he didn’t see the need to communicate with them. There wasn’t any point in even trying to convince him to use any sort of social media tool.

So we need to get a few things out in the open here.

First, social media, enterprise 2.0, and social business design do have the potential to provide value to a business. The case studies are out in the open, so there’s no arguing about this.

However, and second, is that these case studies represent the special case, and not the general case. YMMV{{5}}.

[[5]]Your Mileage May Vary[[5]]

Thirdly, we also know that social media, enterprise 2.0, and social business design require a different approach to command-and-control. Let’s avoid the value judgements as to whether this is good or bad, it just is.

So finally, and fourth, for mass adoption across the entire business community we must acknowledge that the foundation of many companies’ business models needs to change if these new tools are to add value. Zappos makes these tools work, as Zappos’ central asset is their brand, and brand (as an asset) benefits from these tools. Other companies – and this is probably the majority of companies in the business community – are not so lucky. They’ll see more benefit by focusing on the basics.

My view is that there is big shift that is currently building around the need to move away from the idea of a centrally managed asset as the foundation for a company. This is a big deal, as government regulation and accounting rules are built around the idea of a company owning a central asset. All the rules and regulation needs to be rewritten for this to happen. (Note to self: buy shares in accounting firms.)

The most likely new foundation for business is the ability to mobilise stakeholders – from employees, through partners to customers and the market in general. Your value will be defined by your ability to make things happen, rather than the assets you own. This would be world where all costs are operationalized, and our businesses look more like World of Warcraft than the hierarchal command-and-control structures of old. You, as an organisation, will be measured on the strength of your organisation’s social graph. Social business design will be the first port of call when designing your new business, rather than the last.

Until this shift happens it looks like social business design, social media, and enterprise 2.0 will be of marginal utility for many firms. Not useless, just less than revolutionary. However, I do think this (or something like it) will happen in the mid term. Someone will make it work in a private company, and then it will be copied. It will become increasing difficult for old school companies to compete with the new breed, eventually reaching the point where the old school pressures the government into changing the regulations and rules to suit.

Me, until the revolution comes I’m focused on getting out in the field and using all these tools in a new and interesting ways to create as much value as I possibly can, for both employees and the companies they work for.

How to cope with an IT transformation

Once started, an IT transformation is hard to stop. Such huge efforts – often involving investments of hundreds of millions, or even billions of dollars – take on a life of their own. Once the requirements have been scoped and IT has started the hard work of development, business’s thoughts often turn from anticipation to dread. How do we understand what we’re getting? How do we cope with business change between when we signed off the requirements to the solution entering production? Will the solution actually be able support an operating and constantly evolving business?

Transformations take a lot of time and huge amount of resources, giving them a life of their own within the business. It’s not uncommon for the team responsible for the transformation to absorb a significant proportion of the people and capital from the main business, often into the double-digit percentages. It’s also not uncommon for the the time between kicking off the project and delivery of the first components in to the business to be five years or more.

The world can change a lot in five years. Take Apple for example: sixty percent of the products they sell did not exist three years ago{{1}}. It’s not rare for the business to have a little buyers remorse once the requirements have been sign-off and we sit waiting for the solution to arrive. Did we ask for the right thing? Will the platforms and infrastructure perform as expected? Are our requirements good enough for IT to deliver what we need? Will what we asked for be relevant when it’s delivered?

[[1]]60 percent of Apple’s sales are from products that did not exist three years ago @ asumco.com[[1]]

Apple quarterly sales by product
Apple quarterly sales by product

The business has placed a large bet – often putting the entire company’s life on the line – so it’s understandable to be a little worried, and the investment is usually large enough that the business is committed: there’s no backing out now. However, the decision to undertake the transformation has been made, our bets have been placed, and there’s no point regretting carefully considered decisions made in the past with the best evidence and information we could gather at the time. We should be looking forward, focusing on how we can best leverage this investment once it is delivered.

We can break our concerns into a few distinct groups: completeness, suitability, relevance and adaptability.

First, we tend to worry that our requirements were complete. Did we give IT the information they need to do their job? Or were there holes and oversights in the requirements which will require interpretation by IT, interpretation which may or may-not align with how the business conceived the requirement when we wrote down the bullet points.

Next, we are concerned that we asked for the right thing. I don’t know about you, but I find it hard to imagine a finished solution from tables, bullet points and process diagrams. And I know that if I’m having trouble, then you’re probably imagining a slightly different finished solution than I’m thinking of. And IT probably has a different picture in their heads again. Someone is bound to be disappointed when the final solution is rolled out.

Thirdly, we have relevance. Five years is a long time. Even three years is long, as Apple has shown us. Our requirements were conceived in a very different business environment to the one that the solution will be deployed into. We probably did our best to guess what will change during the delivery journey, we can also be sure that some of our predictions will be wrong. How accurate our predictions are (which is largely a question of how lucky we were) will determine how relevant the solution will be. If our predictions were off the mark, then we might have a lot of work to do after the final release to bring the solution up to scratch.

Finally, we have adaptability. A business is not a fixed target, as it constantly evolves and adapts in response to the business environment it is situated in. Hopefully we specified the right flex-points – areas in the solution which will need to change rapidly in response to changing business need – back at the start of the journey. We don’t want our transformed IT estate to become instant legacy.

A lot of these concerns have already been address with ideas like rapid-productionisation{{2}} and (gasp!) agile methodologies, but they’re solving a different problem. Once you have a transformation underway, advice that you should hire lots of Scrum masters will fall on dead ears. While there’s a lot of good advice in these methodologies, our concern is coping with the transformation we have, not to throw away all effort to-date and try something different.

[[2]]Rapid productionising @ Shermo[[2]]

So what can we do to help IT ensure that the transformed IT estate is the best that it can be?

We could try to test to success, making IT jump through even more hoops by create more and increasing strenuous tests to add to the acceptance criteria, but while faster and more intense might work for George Lucas{{3}}, it doesn’t add a lot of value in this instance. Our concerns are understanding the requirements we have and safeguarding the relevance of our IT estate in a rapidly evolving business environment. We’re less concerned that existing requirements are implemented correctly (we should have already done that work).

[[3]]Fan criticism of George Lucas: Ability as a film director @ Wookieepedia[[3]]

I can see two clear strategies for coping with the IT transformation we have. First, is to create a better shared understanding of what the final solution might look like (shared between business and IT, as well as between business stakeholders). Second is to start understanding how the future IT estate might need to evolve and adapt in the future. Learnings from both of these activities can be feed back into the transformation to help improve the outcomes, as well as providing the business with a platform to communicate the potential scale and impact of the change with the broader user population.

There are a number of light-weight approaches to building and testing new user interfaces and workflows, putting the to-be requirements in the hands of the users in a very real and tactic way which enables them to understand what the world will look like post transformation. This needs to be more than UI wireframes or user storyboards. We need to trial new work practice, process improvements and decisioning logic. The team members at the coalface of the business also need to use these new tools in anger before we really under their impact. Above all, they need time with these solutions, time to form an opinion, as I’ve written about before{{4}}.

[[4]]I’ve already told you 125% of what I know @ PEG[[4]]

Much like the retail industry, with their trial stores, we can create a trial solution to explore how the final solution should move and act. We’re less worried about the plumbing and infrastructure, as we’re focused on the layout and how the trial store is used. This trial solution can be integrated with existing operations and provided to a small user population -– perhaps a branch in a bank, an single operations centre for back-office processing, or a one factory operated by a manufacturer – where we can realise, measure, test and update our understanding of what the to-be solution should look like, bringing our business and technology stakeholders to a single shared understanding of what we’re trying to achieve.

Our trial solution need not be on the production platform, as we’re trying to understand how the final solution should work and be used, not how it should be implemented. Startups are already providing enterprise mash-up platforms{{5}} which let you integrate UI, process and decisioning elements into one coherent user interface, often in weeks rather than months or years. Larger vendors – such as IBM and Oracle – are already integrating these technologies into their platforms. New vendors are also emerging which offer BPM on demand via a SaaS model.

[[5]]Enterprise Mash-Ups defined at Wikipedia[[5]]

Concerns about the scaleability and maintainability of these new technologies can be balanced with the limited scale and lifetime of our trial deployment. A trial operations centre in one city often need not require 24×7 support, perfectly capable of limping along with a nine-to-five phone number of someone from the development team. We can also always fail back to the older solution if the trial solution isn’t up to scratch.

Our second strategy might be to experiment with new ideas and wholly new models of operation, collecting data and insight on how the transformed IT estate might need to evolve once it becomes operational. This is the disruptive sibling of the incremental improvements in the trial solution. (Indeed, some of the insights from these experiments might even be tested in a trial solution, if feasible.)

In the spirit of experimental scenario planning, a bank might look to Mint{{6}} or Kiva{{7}}, while a retailer might look to Zara{{8}}. Or, even more interesting, you might look across industries, with a bank looking to Zara for inspiration, for example. The scenarios we identify might range from tactical plays, through major disruptions. What would happen if you took a different approach to planning{{9}}, as Tesco did{{10}} or if we, like Zara, focused on time to market rather than cost, and inverted how we think about our supply chain in the process{{11}}.

[[6]]Mint[[6]]
[[7]]Kiva[[7]]
[[8]]Zara[[8]]
[[9]]Inside vs. Outside @ PEG[[9]]
[[10]]Tesco is looking outside the building to predict customer needs @ PEG[[10]]
[[11]]Accelerate along the road to happiness @ PEG[[11]]

We can frame what we learn from these experiments in terms of the business drivers and activities they impact, allowing us to understand how the transformed IT estate would need to change in response. The data we obtain can be compiled and weighted to create a heat map which highlights potential change hotspots in the to-be IT estate, valuable information which can be feed back into the transformation effort, while the (measured, evaluated and updated) scenarios can be compiled into a playbook to prepare use when the new IT estate goes live.

Whatever we do, we can can’t sit by passively waiting for our new, transformed IT estate to be handed to us. Five years is a very long time in business, and if we want an IT estate that will support us into the future, then we need to start thinking about it now.

Innovation [22-09-2010]

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

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

Business models for the old rules of IT

The old rules for enterprise IT{{1}} — the rules that have determined the nature of the enterprise IT market — has shaped the people and companies involved. The roles we took on fall into a few regular patterns, patterns which I’ve always thought of in terms of analogies. Outsourcers (AM, BPO …), for example, are similar to trucking companies. Software and hardware vendors can be likened to mining companies. Consultancies are the dating agencies of the IT world. While software integrators and services firms have something of the sandwich shop about them. These analogies do have their limitations, but I’ve found that pondering these stereotypes can help you uncover a few simple truths which are useful in your day-to-day interactions.

[[1]]The rule of enterprise IT[[1]]

I’ve always had a penchant for a simple analogy. Yes, reasoning by analogy can be problematic (just ask any witch from the middle ages{{2}}), but it can provide a new perspective which helps you to uncover some aspect of the subject which had previously eluded you. All too often a failed project or outsourced service can be traced back to a misunderstanding of the nature of the engagement — a misunderstanding of the roles both client and supplier play in the IT industry. The type of simple truths an analogy highlights can go a long way to understanding these roles.

[[2]]She’s a witch! from The life of Brian[[2]]

The roles organisations currently play in the IT industry are driven by the need to deliver large IT assets into the business. What started as a simple tools to manage tabulated data — calculating payrolls, inventory levels and the like — soon grew to the point where developing them was beyond the scope of what many companies could undertake on their own. The pyramid of skills required just became too large, with too many technical skills involved that most companies couldn’t afford to own. The systems we were building had outgrown the men in sheds at the bottom of the garden, and we need to become a bit more organised.

System Integrators emerged as as way for organisations to share these skills. Technologists banded together and travelled from client to client developing applications as they went. This was good. Clients won as they could hire a group who had the skills and tacit knowledge — the did it, done it stories — required to deliver these solutions on time and to budget. The travelling System Integrator won as there was now a big enough stream of work for which they were highly valued, allowing them to be paid what they were worth rather than what any one company could afford.

As the industry grew, the System Integrators rapidly became the sandwich shops of our IT world. When we don’t have the time or money to maintain our own kitchen or make our own sandwiches, it’s more efficient to simply head over to the local sandwich shop to pick up what we need. Their margins are thin and revenue is largely tied to the size of the sandwich you bought, so they’d really like you to buy a larger and more expensive sandwich. (Notice how sandwiches have grown so much bigger over the years, and everything is now gourmet?) And, of course, pre-made sandwiches are always a lot cheaper than special orders.

A ham sandwich
A ham sandwich

With the technology industry rapidly maturing, SIs soon found that most clients had all the sandwiches they needed (I don’t know about you, but I don’t eat more than one a day), so they started to focus on convincing you to upgrade your existing sandwich, replacing it before you had actually finished eating it. If you want some of those pickles they’ve just found at the bottom of a jar then you have to buy an entirely new sandwich, and not just the pickles. Don’t mind the fact that you’ve only half finished your last sandwich.

Consultancies, on the other hand, are the technological dating agencies of the IT industry. Where SIs focus on providing sandwiches, consultancies try and set you up with a skilled subject matter expert who can help you sort out what type of sandwich you’d like to eat. Procurement, supply chain, knowledge management, IT strategy … They take a fee for each date arranged, giving them a strong focus on generating repeat business.

Some organisations — of course — try and blend a dating agency with a sandwich shop. They hope that their SMEs can steer you toward the types of sandwiches that their sandwich shop makes.

Back in application land we have the software vendors: mining companies that spend vast sums of money spelunking for new solutions and technologies, which they then package up in a box and sell for a tidy profit. (In theory, the tidy profit is reinvested back into spelunking for more technology.) Maintenance fees can be considered the delivery charges.

Software vendors allow companies to pool their exploration resources, sharing both the cost and risk of finding new applications in the technological landscape, and extracting them. Be warned though, the more unique demands you make of the vendor, the less chance they have to pool your needs with those of other companies. If you have to many unique requirements, if you move from configuration to customisation, then you start to force the vendor to go exploring for you alone, accepting all the cost and risk yourself.

And finally we have the outsources (as I’ve already mentioned). Like trucking companies, they’re focused on sweating an asset. In the case of trucking companies it’s trucks: keep the trucks moving and don’t spend money on tires. For outsources its an application: make sure they’re running at near capacity, and try and avoid changes (either patches or change requests) as they all involve disruption which goes directly into the bottom line. To make the most of outsources, you need to pass them assets which you can afford to ignore — and not upgrade or change — for a long time.

Of course these analogies break down at some point, and we need to be cognisant of this. Regardless, I think that they could form a useful, shorthand way of understanding the goals and restrictions, the business drivers, for each role in the IT industry.

Planning should not require a Gantt chart

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 untimed1)Types of chess games defined at Chess.net 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 planning2)Martin Börjesson has put together some nice resources on Scenario planning 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 itself3)I’ve already told you 125% of what I know @ PEG). 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 normal4)The new normal @ McKinsey Quarterly. 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 Brooks5)Frederick Brooks on the Mythical Man Month 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 maps6)Strategy map defined @ Value Based Mangement by Kaplan & Norton, mission statements7)Mission statement defined @ The Centre for Business Planning, 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.net
2. Martin Börjesson has put together some nice resources on Scenario planning
3. I’ve already told you 125% of what I know @ PEG
4. The new normal @ McKinsey Quarterly
5. Frederick Brooks on the Mythical Man Month
6. Strategy map defined @ Value Based Mangement by Kaplan & Norton
7. Mission statement defined @ The Centre for Business Planning

Innovation [25-08-2010]

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

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