Oops! That page can’t be found

It looks like nothing was found at this location. Maybe try a search or browse one of our posts below.

|In: Leadership|Last Updated:

Consultants are attracted to Mission Statements the way flames attract moths. They always seem like such a good idea … until you get started. Almost inevitably, the roomful of people deteriorates into a squabbling mass. Some are fighting to make sure what they do is included; all argue passionately about the placement of commas and whether “happy” or “glad” is the more appropriate adjective.

I proposed a solution a long time ago (“Mission statements: Their cause and cure,” January 29, 1996) and updated it in Leading IT: The Toughest Job in the World. (Short version: Focus on concepts, not phrasing; make sure each concept is viewed as an alternative, not an embellishment; and insist that each concept describes ends, not means.)

It’s time to wrap up our discussion of organizational optimization. It began with a proposition from the KJR Manifesto: That to optimize the whole you have to sub-optimize the parts. Then we figured out that “optimize” has to be with respect to only one system variable. And last week we found that for real-world businesses, optimization is really a chimera anyway because there’s no practical way to understand a business and its markets well enough to figure out what “optimum” even means.

What business managers need to do, it turns out, is to set their sights a bit lower — to improve. Since “form follows function,” is the touchstone of organizational design, just as it is for any other design discipline, if you want to know what constitutes improvement you have to know what you’re trying to accomplish. That means understanding the enterprise’s mission, vision and strategy. Then you can craft your own organization’s mission, vision and strategy so they further those of the enterprise.

This is why consultants facilitate Mission Statement drafting sessions. It isn’t because we find Mission Statements … and Vision Statements, and strategies … appealing because we lack better ideas for padding our contracts (well, okay, some consultants do that, but at IT Catalysts we would never stoop that low — it would hurt our lumbar vertebrae). It’s because clients hire us to help them improve organizational performance, and we can’t until we know in which direction “improve” lies. (Just to make sure we’re on the same page: Mission is about the present — what you’re supposed to do. Vision and strategy are about the future: Where you’re going and how you’re going to get there.)

Were it not for the future, this wouldn’t be all that difficult. With clarity about what you’re trying to support and how you’re supposed to support it, you can be pretty clear about what you need to improve so you support it better.

But you can’t ignore the future. Businesses have strategies, strategies are about change, and that makes things messy. You and all the other parts of the whole have to figure out how to change in ways that are sufficiently well orchestrated that the business doesn’t tear itself apart, but not so carefully orchestrated that it loses all elasticity. You also have to figure out how to allocate your budget and staff so you don’t stop supporting the present, but also don’t support the present at the expense of the future. There is no magic formula. There is, however, Guideline #2 from the KJR Manifesto: Big solutions that work great generally start as small solutions that work acceptably.

Strategies start with a design and a plan. The successful ones start with an additional item: Recognition that the design, the plan, or both might be flawed.

That being the case, the plan should, if at all possible, be organized into small steps, not giant leaps. Each small step is defined in terms of improvement to one or more parts of the enterprise. Following each small step you reconnoiter, to make sure the design, plan, and company are all holding together.

To illustrate the point, imagine you and a friend decide to attend a Halloween party in one of those two-person horse costumes. Now imagine that the first thing you and your friend try to do is gallop around a path with a lot of twists and turns.

You might make it. More likely, one of you will zig while the other zags, tearing the costume apart. If that happens, both of you will be at fault, for trying to go too far too fast.

But while you both might be responsible for the problem, only one of you will end up looking like the back end of a horse.

Comments

|In: Leadership|Last Updated:

What if we called it herbal IQ juice?

Highly organic friends of mine routinely disparage my coffee drinking, telling me how unhealthy it is to quaff vast quantities of the caffeine and other chemicals it contains. But if a health food store sold the same stuff as a natural infusion that increases alertness, they’d be recommending it to me, don’t you think?

How you communicate a concept has a lot to do with who accepts it and who rejects it. Which gets us to the issue raised last week — what causes management DRIVEL (Direct Reduction In the Value of Engineering Likelihoods) in response to the recommendations of their technical experts.

It’s time for equal time: The root cause isn’t always management ignorance, stupidity or short-sightedness. Sometimes, it’s that when explained by engineers, Benefit Language is Awfully Thin, Horribly Elucidated, or Ridiculous. (BLATHER). Engineering BLATHER is a major cause of management DRIVEL.

Think back to the early days of the World Wide Web. Marketeers put up websites with blithe disregard for engineering discipline. Getting new pages up quickly trumped such minor considerations as testing, server reliability, or security.

I know from first-hand experience that many IT professionals sat on the sidelines, sulking at such disrespect for quality engineering. They presented their BLATHER to the marketing director, and the marketing director ignored them.

Marketing directors might not know much about engineering, but they do understand that in their world, when faced with the old quicker/cheaper/better trade-off, quicker usually comes first. They viewed their discussions with IT the way a film director might react to recommendations for professional plumbing and electrical work when building a set. It’s just a bunch of BLATHER.

Let’s be honest with ourselves. Bullheadedness is something of an occupational hazard among professional engineers. Many ignore Louis Sullivan’s famous dictum that form follows function, instead considering quality engineering to be an absolute characteristic with intrinsic value. If anyone challenges The Rules, engineers of this persuasion commiserate with each other regarding the sad ignorance of the unconverted heathen, never once considering the possibility that they’re applying their Rules to situations for which they aren’t suited.

Even among engineers who understand that Hollywood sets call for different engineering standards from factories, factories from office buildings and office buildings from domiciles, many still rely on BLATHER to explain what’s required for a project to succeed. They find to their dismay that it’s rarely convincing.

Which brings us to an inviolable rule of communication: At least one party must learn the perspective and vocabulary of the other.

Sophisticated managers, willing to take the time to learn how engineers think and speak, are able to penetrate engineering BLATHER to understand why the recommendations of the engineers matter. They’re the minority. Luckily, the perspective and vocabulary of management are sufficiently simple that engineers who want to can learn them in … well, in what’s left of this column.

All you gotta do is connect your engineering requirements to one of the “Big Four” management evaluation criteria: Increased revenue, decreased cost, reduced risk, and career impact.

Take an example: Microsoft Access and why it’s not the right tool for building production-grade IT systems. Many IT professionals will tell a business manager who’s interested in using it that it’s just a toy, inappropriate for a production system — trust me.

Faced with that impenetrable BLATHER, the business manager contracts development of the system … in Access … to an outside contractor who builds the system at a tenth the cost of IT’s estimate.

An IT professional who’s as interested in being persuasive as being right will take a different approach: “Access is suitable for small or prototype systems only. If this project succeeds, too many users will be hitting the database, which means the system will slow to a crawl. You’ll want us to add more features and functionality, which means the system will slow even more. And the database will grow, which means … yes, that the system will get even slower. That means that instead of increasing productivity, you’ll have a lot of employees twiddling their thumbs waiting for the software to respond, which will cost you a lot more than you’ll save by building the system in Access. Even worse, Access databases become fragile when they get too big, which means that if you’re lucky we’ll have to take the system offline fairly frequently to repair the database, and if you’re unlucky you’ll lose data.”

No matter how much you avoiding engineering BLATHER, you won’t entirely eliminate management DRIVEL. Nothing will.

But at least you won’t cause it to increase. And that’s a worthy goal.

Comments

|In: Leadership|Last Updated:

According to just about every industry consultant I’ve ever known, businesses are supposed to have well-defined processes that move the work along in a series of orderly steps. Those who execute the various steps are fungible — interchangeable, except for the specific skills and knowledge they use to carry out their role in the grand process.

It’s actually more than that: Businesses, many assert, are nothing more than collections of processes — equivalent, perhaps, to a physicist asserting that the universe is nothing more than its energy flows. Matter, in this view, is only important as the stuff energy acts on to demonstrate its presence.

But matter does matter, and the universe, we’re starting to realize, consists of far more than matter and energy: There’s dark matter, dark energy, antigravity (Einstein’s cosmological constant), and virtual particles (which are matter, but only temporarily). Not to mention the additional 6 spatial dimensions beyond length, width, height and time that string theory requires. The universe is, clearly, far stranger than it appears. Not as strange as the average corporation, to be sure, but strange nonetheless.

But I digress.

Viewed from one, narrow angle, businesses are collections of processes. It’s a useful perspective for organizational engineering. It’s dreadfully incomplete, though, when your goal is to actually improve things. That’s because the starting point for an efficient business isn’t the design of efficient processes. That comes second.

What comes first? Trust among the parties who design the process, staff it, and use it. Relationships, to choose a word. Anyone who has been through a successful process redesign and implementation knows this, although many don’t know they know it.

Successful process redesigns involve all stakeholders, or at least representatives of all stakeholder groups. There are three reasons for doing so. The first, least important reason is that every stakeholder group knows something nobody else knows, and unless the process design takes that something into account, it won’t be able to accommodate all of the situations the world will throw at it.

The second, more important reason is to build confidence in the new process on the part of all stakeholders. Without that confidence, everyone will simply do things the old way, because they know it works and have no faith in the newly designed alternative.

The third, most important reason is to build relationships — to build trust on the part of everyone involved in each other. Those who make use of the process have to trust those who staff the process to do their work properly, just as those who staff the process need to trust that those who make use of it won’t bypass it the moment it appears the least bit inconvenient. Those who staff the process also have to trust each other — trust, that is, that all will play their parts properly.

That’s a whole lot of trust for a corporate environment. Is it any wonder one of the most important skills in many corporations is knowing how to bypass the formal processes and procedures, using relationships to “get things done”?

But every time someone bypasses the processes and procedures to get things done they damage the organization a bit. If the processes and procedures are badly designed that might be a good idea: Damaging a mindless bureaucracy is akin to damaging a logjam. Damage isn’t always a bad thing.

Most processes and procedures, however, are appropriate for the situation, simply inconvenient to those who, accustomed to privilege, are looking for inappropriate attention or importance. Each time one of them bypasses the process, it breaks the whole system a little more.

That brings up one of the most difficult challenges faced by any process engineer: Determining whether the existing process really is sufficiently broken that it should be replaced, or whether the problems aren’t with the process, but with the relationships among those who are supposed to use it.

If the problems are with the relationships, redesigning the process will only improve the situation by accident. If the problem does, on the other hand, involve an inefficient process, one of the first places to look when finding ways to streamline the workflow is to eliminate delays created by the need for multiple signatures and approvals — the result, ironically enough, of distrust.

Which is to say, many bad process designs are both the result of a lack of trust, and its cause.

Comments