The premise of this article: Simplicity and simplifying things isn’t all it’s cracked up to be. Too often the well-intentioned – but misguided – take it too far.
Why would I make a case that simplicity in business processes is not always a good thing?
Because I have seen people enamored, even infatuated, with the notion of simplicity to an extent that has significant, measurable, negative results. It’s not the idea that’s bad – it’s the consecration of the idea, leading to the pursuit of simplicity itself as an objective, divorced from the reality of whatever system or scenario we’re examining.
A senior executive told me that the management who implement big projects rarely last long after project completion; they’re too universally disliked. Why? Is it because the projects fail? No; the projects succeed – it’s the messaging that fails, resulting in a perception that the project was less successful than it actually was. In many cases, the messaging failure is about simplicity – or the reality of complexity.
Focus too much on simple and projects are perceived as botched despite any measure of technical success, services and the management providing them are seen as failures, labor resources are misallocated, training is misdirected, staff are subjected to real trauma, and value goes unrecognized.
I hit you over the head with that ominous list because this argument isn’t taken seriously. Now that I have your attention, I prefer to invert the thinking. Rather than pursuing a simplicity that does not exist or is impractical to achieve, understanding inherent complexity increases project implementation success, improves client impressions of services delivered and the management responsible for them, allocates resources efficiently, helps to identify when to train and when NOT to train, prepares staff for change in ways that reduce stress and create lasting partnerships, and ensures that value being created in the enterprise is recognized, acknowledged, and encouraged to continue.
Understand this issue, and you have a better chance of reaching project close-out celebrating a success.
Why Do We Get It Wrong?
Three paradigms propel our pursuit of simplicity. One is good, two are bad, and they begin to explain why we get it wrong.
The Good: Legitimate Pursuit
The simplest reason for getting it wrong is that simplicity is inherently good – and people confuse “inherently good” with “universally good”. Simplicity has a multitude of tangible cost savings and customer relations benefits. As a result we try to impose it to an extent that is inappropriate or impossible. We let our legitimate aims get swallowed by the other two paradigms, Defiance of Reality and Marketing.
The Bad: Defiance of Reality
The Defiance of Reality paradigm is driven by lack of knowledge coupled with a quasi-spiritual reverence for simplicity. Defiance of Reality is initiated by people who don’t know any better, but it’s supported by people who should know better, and fail in their duty by allowing simplistic fantasies to gain credence.
The Bad: Marketing
The second mode of simplicity misuse is intentional: Marketing. Simplicity is used as a tool for selling what may be regarded as otherwise unsellable, but its use is an abandonment of principles and a self-serving focus on the short-term at the expense of the long-term.
How Do We Get It Wrong?
Defiance of Reality and Marketing drive an overindulgence of simplicity. They’re the causes but not the specific behaviors that “get it wrong.” The behaviors are more complicated because the strategies invoked to simplify things rely in varying degrees on all three drivers[1]. We believe things should be simple in Defiance of Reality and because Marketing has used the simplicity angle so often. So we demand simplicity…so simplicity is what gets marketed to us, in a continuous cycle.
The cycle itself, going round and round for decades, creates a reverence for simplicity, like it is some ultimate truth. The weight of so many people saying it so often means that “it must be true”. Simplicity is not so much a business strategy as a religion.
Behaviors do not arise uniquely from each driver because the drivers are co-dependent; our behaviors exhibit all three to some extent.
Here are four examples of harmful behaviors engaged in pursuit of simplicity – and the positive behaviors that can replace them. I’m sure there are more; have you experienced one that I have not? I’d love to hear from you.
1. We sell projects as simplification exercises when they’re not.
The Amazon Effect
A common refrain from users of corporate systems is why these systems aren’t more like Amazon.
If Amazon can ship a million products to two billion customers in 18 countries with five clicks, why does it take ten times that effort to order a binder in our company? Doesn’t that relative complexity indicate a design failure? This is the Amazon Effect – the idea that Amazon or any of the hundreds of other superb, public implementations of complex systems are somehow a benchmark for how corporate administration should work.
The reality is that simplicity is not a goal of corporate system design. (And the project’s marketing of simplicity does not make it so.) I’ve never worked on a systems implementation where “make it simpler” was on anyone’s real list of reasons for the project. Simple is often chanted like a mantra all through the pre-implementation; that does not mean it’s a force driving the project in reality. Making it simpler is not why the project is being pursued.
This is not a surprise. Think about your company’s products or services. Is simplicity your primary product, or a key characteristic of your product? I’m not asking if simplicity is a feature; I’m asking if it’s the primary reason you achieve sales.
Probably not. I can think of no product I buy primarily because it’s simpler than the competition. If there is a predominant characteristic of successful products and services it’s “capable”. They best perform the functions I desire. The same is true of corporate systems. Systems are implemented or redesigned to increase quantity or quality of output – to improve their capability – which frequently has nothing to do with how simple they are.
Point being, we don’t embark on projects primarily to make things simpler so it should come as no surprise that the results are not simpler than what came before. The project may be sold to users as a simplification exercise – but it’s not.
2. We don’t understand that simplicity is a product – but it’s not our product.
Buying Simplicity: More Amazon Effect
Isn’t the failure to have simple corporate systems a failure to invest sufficiently in those systems? Doesn’t Amazon’s one-click ordering of anything to anywhere actually prove the point that anyone could do it?
It proves a point. It proves that if we want to spend a hundred million dollars over 20 years then yes, you can order a binder for the office as simply as you can order a blu-ray from Amazon.[2] My point is we don’t want to do that.
In essence Amazon’s ordering system is their product. (Or more accurately, Amazon’s logistics system, for which the ordering system is the front end, is their product.) They’ve invested hundreds of millions in the ordering and logistics system because it is the product that draws customers to the company. I can get an array of items delivered to my door tomorrow which I couldn’t assemble if I spent all day going from store to store. Selection, availability and ease of ordering is the product that makes me go to Amazon and the investment of millions in that ordering system has therefore been an excellent choice.
For them. What about our product? Does a 100 million dollar internal system help us sell it? Almost certainly not, which makes having such a system akin to having solid gold fixtures in the bathrooms. If a given system is not the product, then gold plating it is money spent for no valid purpose. The relative complexity of our systems is not an inadvertent failure – it is an intentional, rational, intelligent choice.
Simplicity is the ultimate goal only when it’s the product driving profit.
3. We believe (or fail to refute the view) that complexity is nothing more than dysfunctional bureaucracy, and simplification is elimination of the unnecessary.
OK. I get the idea. But this is still wrong. Complexity is your enemy? Complexity has no such characteristic – it just is.
Brain surgery is complex. Flying a jet is complex. Complexity isn’t created randomly, by fools or anyone else; many things are just complicated. To declare a war on the complexity “enemy” is to have no understanding of complexity.
The “fools” idea reinforces the error of the “enemy” idea by implying that complexity is a failing created by stupid people. Got a complex process in your enterprise? Apparently you’re an idiot. (Not my opinion – complain to Mr. Branson.)
At least the last sentence is true. But its very truth is, as we’ll see, a key reason we often should not try to make things simple. Simple is hard – often impractically so.
Inherent Complexity Cannot Be Promised Away
Amazon is not the appropriate measure by which to rate a corporate ordering system. Amazon has two concerns: where do we ship the order and how are you paying us? The corporation, and therefore its system users, have many more concerns.
Is the price appropriate (fair and reasonable in procurement terms)?
Am I authorized to sign this contract?
Is the source identified for these funds appropriate and correct?
Does the source of funds contain sufficient funds?
Does the expenditure have the proper approvals?
Is this shipping destination correct and authorized?
Who is the vendor?
How was the vendor selected?
Is the product approved for the intended corporate use?
Buying things as an individual you have a few potential sources of funds – a handful of bank accounts and credit cards. A large corporation may have thousands. You have one or two delivery addresses. The corporation, maybe hundreds. You’re personally authorized to do anything you like. In the corporation you’re not and a purchase may require multiple authorizations. If you make an error in a personal purchase only you and your family are affected. An error ordering for the corporation potentially affects the whole corporation.
The corporate situation is orders of magnitude more complicated. Therefore the ordering system is orders of magnitude more complicated. There’s no way around it — nor should there be. Complexity is a feature, not a bug.
Must we resign ourselves to an endless battle with complex systems? Not at all. But simplicity is not achieved by taking an axe to the inherently complex and chopping off bits we don’t like because they’re “too complex” for our tastes.
There is no simple brain surgery. There is no simple space travel. Trying to make the inherently complicated simple by deleting bits and pieces instead makes it incomplete, inadequate and even potentially dangerous.
The objective therefore is not to make the inherently complex simple, the objective is to encapsulate the complexity and present the user with a readily understandable, usable way to engage with the complexity on the user’s terms.
To start a car electric circuits must be completed to drive a fuel pump, starter motor and fuel injectors. Firing signals arrive at spark plugs 25 times a second. Sensors measure air pressure, air temperature, coolant temperature, camshaft speed, and an engine control unit manipulates fuel and air flows in accordance with these variables. It’s not simple, it’s complicated. But auto makers have encapsulated that complexity — in the push of a button.
Seeking simplification, we may accidentally cross the line from simplifying the use of a complex process to simplifying the process itself. That can be a worthy goal. By all means be merciless in excision of unnecessary steps, reviews, approvals, copies, files and notifications. But do not fail to differentiate between process that only “makes work” and process which serves a valid and sometimes critical purpose.
There’s never going to be a simple way to become a brain surgeon or an astronaut. Likewise there’s never going to be a simple way to maintain IT infrastructure for 50,000 employees. There’s never going to be a simple way to perform a $10 million procurement supporting a U.S. Federal contract. To suggest that these things “should be” simple is to defy reality itself.
Ill-advised simplification ignores the line between a process required to produce a result, and how that process is presented to the user. It’s the presentation that requires simplicity, not the process.
Car makers have made engines more complicated intentionally, and partly in order to simplify the user experience. More complexity in engine intelligence and control have simplified what we need to think about in order to start one. Adding complexity to the process has removed complexity from the user interface. This important point is often lost in the charge to simplify things: that inherent complexity cannot be promised away, and complexity may actually need to increase to simplify the user interface.
4. We sell projects themselves (as opposed to the end state the project will create) as simple exercises.
My team executed two major IT implementations and leaders that I otherwise had great respect for used the same false promises to promote these projects each time. The end state would be easier to use and we would work faster. The project would be a breeze.
We’ve got all these expensive consultants (so it’s GOT to run perfectly, right?). We’ve got a project plan that’s three inches thick. Everything’s in there, including who’s picking up lunch on Thursday of week 38 of the project. All users are getting a full week of computer lab training, not just classroom, but real hands-on stuff. This is the best-planned, most completely thought-out, guaranteed-to-succeed project ever!
In reality it doesn’t matter how thick your project plan is. It doesn’t matter how many millions you’ve poured into consultants. It doesn’t matter how much training you give people.[4]
When you’re tossing a bunch of your business processes in the dumpster and introducing something new and radically different, there’s only one possible result: chaos. By definition, big process reengineering projects are going to have a period of chaos. They have to; that's what change is, particularly big changes.
So why do so many experienced IT and project managers promise an easy ride when they have enough experience to know they can’t deliver on that promise?
I presented this question to a procurement director and was advised that if people were told in advance what a major systems implementation was really going to be like, they’d never agree to it and major systems couldn’t get done. This answer presumes that management is unable to lead people and be convincing in challenging situations. I reject that notion. In fact, I reject it specifically with reference to the person who proposed it to me. He was strong, smart, and lead us into a new procurement paradigm that improved our service and delivered greater success for the corporation. I believe he could lead people through anything he set his mind to, so the reluctance to be forthright about IT implementations puzzles me.
Does it matter? Isn’t it smart to avoid the pre-implementation battles by telling a few little white lies? No, it is not smart at all. 22 years later I spoke with one of my former colleagues who still had sharp and painful memories of that time. Brutal projects make an indelible impact which includes a dramatically negative regard for the responsible management.
But the project was only “brutal” because we’d been told it would be a breeze, no one was prepared for reality, and when reality struck there was no plan to handle it – because the “it’s going to be easy” lie precluded having one.
The final word, which I think sums up the reality of the situation:
[1] (1) Lack of knowledge, (2) quasi-spiritual reverence and (3) marketing.
[2] I have no idea what Amazon has invested in its ordering and logistics. I suspect “several hundred million” is conservative.
[3] But aren’t the most complex processes, like operating a nuclear reactor and airline flying, trained entirely in the classroom? Not really. Because nuclear plants and airlines must train to an extraordinary level of knowledge and proficiency they invest in extraordinarily expensive systems simulators. They put people into a training environment that is practically indistinguishable from the real thing. Their “classroom training” in multi-million dollar simulators is actually more akin to field or on-the-job training.
[4] I’m not saying training never matters; of course it does. I’m saying it doesn’t solve all the problems people like to believe it solves. If you think the answer to bad systems implementation is just more training, in that context training doesn’t matter – because your premise is wrong.
コメント