All Posts in Organizational Design

|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

|In: Industry Commentary|Last Updated:

If you’re a fan of the future, it’s time to write a letter.

K. A. Boriskin, a long-time correspondent, reports that there is a movement among science fiction readers to get the USPS to issue a stamp commemorating Isaac Asimov. Click here for details. Mr. Boriskin adds, “Unfortunately we’re dealing with the Postal Service here, so there’s no email address available, only snail mail.”

My 37 cents worth? Ask for the big three: Isaac Asimov, Robert Heinlein, and John W. Campbell, who together transformed the field. Send the letter to: Citizens’ Stamp Advisory Committee, C/O Stamp Development, 475 L’Enfant Plaza, SW, Room 5670, Washington, D. C., 20260-2437. And don’t complain that the USPS requires a letter. It is, after all, in the snail mail business — why would it encourage you to use its competition?

No, don’t answer that …

Speaking of the future, the future of IT (the organization, not the stuff) is that it will go away. That, at least, is the gist of a recent Gartner exercise in futurism, as reported and critiqued here last week. The quick version: Because tools for configuring and reconfiguring workflows are becoming user-friendly enough to transition to business units, IT will become unnecessary. The here-on-this-planet version: So what? Business units don’t reconfigure workflows very often, because have you ever tried to change a business process? If you have, you know it’s hard to do no matter how good the information technology.

The hard fact is that designing a good process is an engineering task, not just a matter of dragging connectors in Visio. The harder fact is that once you do, you have to actually get employees to do their work differently. And the hardest fact of all is that once you do that, you have to fix all the gaps in your process design, because no process designer has ever anticipated everything that can happen once actual work starts flowing through.

You just don’t want to go through this all that often.

But while Gartner-bashing might be fun (and “might be” is a pale description of the joyful reality), it isn’t fair to criticize without offering an alternative. Luckily, I am (to quote Asimov) “a keen-eyed peerer into the future,” and so, I will.

What’s the organizational future of information technology?

From a business planning perspective, anything beyond three years or so is little more than science fiction without the science. Within that window there are no obviously transformational technologies or trends that suggest a need for radical change. For most businesses:

  • IT operations will continue to be semi-automated. Systems management tools continue to improve; systems complexity continues to increase; the likelihood of true “lights out” operation is still far away. Savvy CIOs already know their job is to shift budget out of operations, but only as much as they can without harming the quality of service they provide.
  • IT’s bread-and-butter work will still be application maintenance and enhancement (small non-discretionary and discretionary changes, respectively). Today’s rules won’t change: Organize talent into teams that know the major applications inside-out and sideways; batch changes into scheduled releases; and make sure you’re very, very good at integration and regression testing.
  • Most companies will continue to organize their technical architecture around one or a very small number of enterprise applications — usually an ERP suite. Integration will be hub-and-spoke with those applications. If it isn’t already, make it so. And integration will continue to be more about data than about business logic: The former is a necessity, the latter is a convenience. ERP suites will continue to simplify the process of integrating peripheral applications into their architecture. That’s great news — but not the stuff of organizational change.

In the next three years, IT will transform in one very important respect: Its role in the business. At the risk of flogging even further a horse that’s already been tortured in this space, IT, in most companies, will stop trying to be a supplier to its internal customers, and will start being a partner and collaborator in the achievement of business change.

The change will hit business analysts the hardest. Much of what they know today will become irrelevant. Much of what they don’t know will become essential. More than anything else, they will have to become experts in the disciplines of process design, and in designing large-scale change programs that translate strategic intent into achievable action.

Are they ready for this? Ask them. They’ll probably tell you, “We’re doing that already.” If they do, it’s possible they’re right. It’s more likely that they don’t know what they don’t know.

Yet.

Comments