The Reengineering Process

There is a great little book titled The Outsiders by William Thorndike. It presents Thorndike’s quantitative analysis of CEOs over time, and highlights eight who delivered extraordinary returns, far exceeding their peer group, celebrated CEOs, and the market. These CEOs had several things in common, the dominant one being that they were excellent capital allocators. They viewed that activity as their primary job, not to be delegated. They spent their time determining what businesses to enter and exit. When I claim a reengineering process should begin with a strategic diagnostic, I am channeling Thorndike and his eight extraordinary CEOs.

Having a keen knowledge of what businesses a firm should enter and exit is critical to reengineering because there are some businesses that cannot become attractive again through reengineering. Those businesses should be exited. That is good capital allocation in action.

Strategic Diagnostic

A company-wide reengineering effort is a huge undertaking, potentially disrupting the firm in many ways. Spending some time at the beginning of the process thinking carefully about what the firm’s future should look like is time well spent. The Board, CEO, and management team should have frank conversations about their goals, benchmark against competitors, take a critical look at the company’s competitive advantages, and scrutinize its financials. There should be a healthy debate about the allocation of the company’s capital. They should produce a document that memorializes their objectives for the foreseeable future. This will define what their company will become in the near future.

Selecting and Mapping Processes

The strategic diagnostic and careful look at the financials will help identify which areas of the company are ripe for reengineering. Processes that require many hands and have high associated expenses, with not much benefit to the company, are likely high on the to-be-reengineered list. Not all processes can be examined at once; a triage approach makes much more sense.

Mapping how the process currently works — the inputs, the steps involved, their associated labor intensiveness and cost, and the outputs — is an art. You want enough detail, and the right detail, to convey the necessary information without getting lost. Different levels of abstraction can help different types of users grasp the essence of the process.

It is critically important to remove people and department names from processes. Workers and managers innately try to protect their jobs and their turf. We want to de-personalize the process as much as possible.

Designing an Ideal State

Now that we can look at a process unhindered by organizational considerations, we can start to ask “why?” and “what if?” questions. What is possible through technology that was not available five years ago? How have consumers’ preferences changed? What suppliers and services exist now that didn’t exist in the past? We can visualize completely different approaches. With this ideal state in mind, we can start fleshing out what types of people we will need to operate it, and how they will be managed.

The Transformation Path

How we get from our current state to our ideal state is simple in theory and complicated in practice. There are all the typical project-management elements: the tactical plan, ownership of different pieces, timeline, review cadence, acquisition of software, testing of new processes, and reassignment or restructuring of teams. It all sounds very mechanical, but the human element is very emotional. Employees will likely lose their jobs. They will exit the company because the company no longer has a use for them. That is difficult and painful for everyone involved. Team morale will nosedive, and employees who are not slated to leave might jump ship out of worry for their paycheck. Suddenly the department is understaffed, and operational issues arise. Transformation from the past to the future is fraught with potential landmines. There needs to be several layers of backstops to prevent the wheels from coming off the bus.

Who Runs It

A reengineering effort needs a small number of very specific people, not a large committee. The CEO has to be the visible sponsor, not because CEOs are especially good at project management, but because nothing this disruptive survives without someone at the top willing to spend political capital defending it once it gets uncomfortable, which it will.

Below that, someone needs to own each process being redesigned: a process owner, responsible for it end to end, who isn’t necessarily the manager who ran the old version of that process. That last point matters more than it sounds. The person who managed a process for ten years has real knowledge worth using, and a real stake in defending the decisions they made along the way, including decisions about which of their own people stay. A reengineering team, small and cross-functional, reporting to the process owner rather than to any single department head, does the actual mapping and redesign work. Its value comes specifically from not being embedded in the reporting lines it’s evaluating.

I’ll come back to exactly why that separation matters later in this book, when the question isn’t just who owns the process, but who has the authority to decide which specific roles survive it.