6: Who Will Reengineer?
It is too vague to suggest that "a company" must seek to reengineer processes - unless you are very specific about the person who will take on this responsibility, everyone will assume that someone else is doing it, and the company will remain stagnant. In the author's experience, he has seen various combinations of people drive the reengineering process, but it largely falls to five roles:
- Leader - A senior executive motivates and authorizes the reengineering effort
- Process Owner - A manager who has responsibility for a specific process seeks to change it
- Reengineering Team - A group of people is assembled and dedicated to examining and reconsidering processes
- Steering Committee - A group of senior managers and board members who develop the organizational strategy drive reengineering efforts
- Reengineering Czar - A senior executive who does not have a place within the operational organization is assigned the task of company-wide investigation and planning
In an ideal situation, all the roles would be involved: a steering committee provides a mission to the czar, who engages leaders to organize reengineering teams with the assistance of process owners. But very often, it is not as comprehensive or well orchestrated.
Leader
Given corporate politics, any significant activity needs a senior executive with considerable esteem to persuade people to support the effort. Absent a leader, you can do studies and present concepts, but nothing is likely to actually happen - or even if it does seem to catch on informally, it is in constant risk of getting sandbagged in favor of other initiatives that have such support.
It would be unusual for an organization to assign a leader the task of managing reengineering - an existing leader generally sponsors an effort whose greatest impact or benefit is to his functional unit.
The function of a leader is as a shepherd, visionary, and motivator. His voice is heard far and wide, and makes clear to everyone that it is a serious effort that merits the commitment of time and resources. Moral support and lip-service are not sufficient - he must take an active role in supporting the effort within the organization, and particularly in providing authoritative support against resistance to change.
The CEO of a large organization is rarely the leader of reengineering. He may be supportive of it, but his concerns are generally broader than operational issues, even those of significant size. It's generally another executive, ideally on the VP level, though the task might fall to a division manager. The problem with delegating it too far down in the organization is that a division manager may run into insurmountable obstacles if the reengineering requires changes outside of his own division.
The author also considers what is meant by being a "leader" - it's not merely managing or overseeing the effort (a project manager can handle that), but providing support to the effort and encouraging, rather than coercing, the changes that need to be made.
The author speaks in a roundabout way of signals, symbols, and systems:
- Signals are messages the leader sends to the organization about the effort: what it means, why we're doing it, why it's important. It sets expectations to encourage collaboration and overcome opposition (or elicit it early enough in the process). Big efforts need big signals, and a leader must be inspirational to the point of fanaticism to sell a very large change.
- Symbols are actions performed to reinforce the content of signals. They are not functional activities that directly impact the work, but gestures that demonstrate that his support of the idea is more than words. (EN: This is a bit vague)
- Systems are routine activities that reinforce the message in a more direct manner: they are used to provide rewards and incentives to people whose actions serve the effort.
The author notes that signals, symbols, and systems can also be negative. A common example is firms who punish (demote, fire, or relegate to a dead-end) individuals who have suggested innovations that fail. There is no better way to squelch all innovation in a firm than to punish risk-taking. He shares a motto from Motorola, "We celebrate noble failure," as an indication that people are rewarded for innovative thinking, sound decision-making, and careful action even when the outcome is not what they had hoped to achieve.
It's also worth noting that some leaders will be reluctant to support an effort, in spite of its benefits, in a corporate culture where innovation is discouraged - leaders who burn bridges and sully relationships to get things done do not last, so much depends on the organizational culture and the personal power of an individual. On the other hand, championing a project can help a leader to build esteem and credibility within an organization. Any leader approached with the prospect of sponsoring a dramatic effort will be motivated by hopes and fears, the resolution of which will determine his interest in lending support.
Most reengineering failures stem from breakdowns in leadership: there is not sufficient leadership support to convince those who are more directly involved to give their own support to the initiative - and so it does not get off the ground or is abandoned. Such failures damage the credibility of reengineering in general, as well as that of the leaders who support efforts that fizzle.
For that reason, it's important to curb your enthusiasm and refrain from attempting to move forward without a strong and enthusiastic champion.
Process Owner
The process owner should also be a senior-level manager with line responsibility over the functional areas of the firm most directly impacted by a reengineering effort. While an enthusiastic leader can provide support from on high, the process owner is more accessible and has more frequent contact with the individuals involved - and while he may have less prestige across the organization, he has far more credibility with the front lines.
Few companies have dedicated process owners because they do not think in terms of processes. Instead, they have functional managers whose units each own a small part of a process that was designed long ago. They are focused on the activities of the people in their department, to make sure that they are doing their jobs and following procedures, and have no broader vision or authority. At best, the managers of multiple units can get together to negotiate a process, but it is invariably done in a contentions manner, with each manager representing the interests of his own business unit. This is highly dysfunctional.
And so, the reengineering effort begins with identifying a process and assigning the process to an owner who has oversight across that various departments in impacts, and the responsibility for the end-to-end flow of work through the process, coordinating as necessary with the various units that will be impacted. This will require negotiation and persuasion skills, as it is often done without formal command authority to compel unit managers to accept changes -the leader will encourage a cooperative spirit, so that the process manager may draw upon it.
The process owner does not "do" the reengineering, but sees that it gets done by coordinating the work of a reengineering team, providing them with the resources and support they require, handling administrative and bureaucratic tasks, and negotiating with other managers whose functional groups are impacted.
The process owner is likened to a project manager during the reengineering project, but he also remains in place after the project is completed to monitor the process on an ongoing basis and ensure it continues to function as desired, or identify opportunities for modification when needed.
Reengineering Team
The actual work of reengineering is done by a team of people, who must produce the ideas and plans and turn them into realities. The author splits hairs between a "team" and a "committee" - the reengineering team is a small group, five to ten people, who are involved in planning and execution, whereas a committee tends to be a larger body of people who talk about ideas that other people will be assigned to effect.
The author recommends dedication of resources to tasks - it is not efficient to have a team that attempts to reengineer multiple processes at once, nor to have multiple teams working on the same process simultaneously. This is the road to chaos.
The team should involve a number of "insiders" who come from the various functional units involved in a process and have familiarity with the way things are currently being done and the resources they already have at their disposal. However, this can be a double-edged sword, because insiders are often institutionalized and have an agenda to defend present practices - like the managers of their units, they may have a sense of what is or is not "my job" and will defend the position that any inefficiency is someone else's fault.
As such, attitude is as important as expertise when selecting people to participate on such a team - they must embrace the possibilities rather than fear change. Credibility with their coworkers is another important asset, as they will likely be the ones to whom others turn when they are nervous about changes that the team is making, and have the greatest ability to convincingly "sell" the ideas.
Insiders are seldom capable of approaching a reengineering process without assistance. While some may be aware of problems with the present systems and eager to make change, they meanwhile see things from their own perspective and will seek to serve their own agenda. They may be accustomed to ways of working and will often return to what is familiar, making it difficult for them to envision radical new ways of improvement. The author suggests that a team of insiders will arrive at a 10% improvement, and generally look to streamline a process rather than reinvent it. They need to be disrupted to break free of the patterns to which they are inured.
This is where outsiders come in handy. These are people who do not work in the units that will be affected, and can bring a broader and more objective perspective to the team. Disruptors rattle the cages, talk about the white elephants, poke the sacred cows, make waves, and other shopworn metaphors as well. They must be capable of learning quickly, thinking about the big picture, describing innovative ideas, and persuading others to play along.
By definition, outsiders come from outside the process. There is no standard answer, but it should be clear from the nature of the project which departments to tap: if reengineering requires information systems, a technical expert can be pulled from that department, or if it impacts the customer, someone from marketing can be called in. Where internal resources are lacking, outside consultants can be brought in to lend a perspective.
The author suggests that about 25% of the team should be composed of outsiders - a little disruption is necessary, too much can be frustrating and counterproductive.
It should be anticipated that the insiders and outsiders will not get along at first. The insiders will be dismissive of the value outsiders bring; the outsiders will be frustrated at the obstinacies of insiders who seem to want to prevent change from occurring. Early encounters will be difficult and bordering on hostile, but they will eventually come to respect one another and work more collaboratively.
It's important for reengineering teams to be self-directed. The process owner can coach them toward agreement, but should not play the role of a boss who takes sides in a dispute rather than letting them work things out on their own. The team should work as peers with a facilitator.
Collaboration requires getting the team together in one place, outside of their regular work environment. This may require moving them out of their areas and into a central location for the duration of the effort. This can be difficult, as most companies design their workplaces to suit their existing silos - in effect, to keep people separated and prevent collaboration. Real estate can be an issue.
Culturally, the team members must be tolerant of a looser development process: they must be willing to make mistakes, learn from them, and iterate towards a solution rather than feeling the need to be very detail-oriented and expect immediate perfection. (EN: Team members are seldom the problem, but management often is. If the tone is set so that people do not fear punishment, that will enable some to relax - but the real test is what actually happens when a mistake is made. This can either ease the anxiety or ramp it back up to fever pitch.)
The author strongly advocates a 100% commitment of resources to reengineering teams: members should completely step away from their "regular" jobs to support the effort. When it is not feasible, such as in instances of employees who have unique knowledge that is indispensible, then they should be able to commit 75% of their time - that is, the reengineering project is their primary focus and they can return to their normal group an hour or two each day to do only what is absolutely necessary. (EN: Where any employee is "the only person" who can do something, chances are this is a bigger problem that should have been solved before - but often, this is not discovered until they are pulled off the job.)
The duration of a reengineering project varies according to its scope. It is not a ninety-day assignment, and it may be a year or more. Team members should not worry about heir ability to go back to their old jobs afterward - once the process is changed, the organization will change, and their old jobs may no longer exist. Instead, they should be encouraged to look forward, and anticipate what their new job will be after the organization has taken place. Not only does this keep them looking forward, but it also gives them a serious perspective about the work they're doing - they are not creating a job for someone else, but a job they will have to do.
In addition to the core team, there will likely be an "outer ring" of part-time and occasional contributors who attend to the effort on an as-needed basis. They have information or expertise that the team may need from time to time, and can be involved on an ad hoc basis.
Steering Committee
Brief mention is made of a steering committee, which the author refers to as a collection of senior managers whose parts of the organization will be impacted by a reengineered process. The group will be chaired by the leader. The committee deals with overarching issues and decides which projects get resources when they run into conflicts, and have the ability to allocate additional resources.
(EN: The author's coverage is short and not very specific. My own experience with such committees is that they are focused on higher level concerns such as impact to the organizational mission, the desired results, and related topics that are beyond the scope of the specific effort. Such committees often bring together employees and board members to discuss long-term issues, things that have a scope of five years or more, and do not delve into the specifics of the current effort.)
Reengineering Czar
In a company in which there are multiple, concurrent reengineering efforts, the author advocates appointing a "reengineering czar" with oversight to all reengineering efforts across the entire organization. His functions are to enable and support all process owners and teams and to coordinate all the ongoing reengineering activities.
The czar owns the process of reengineering itself. He can coach and guide teams who are undertaking these efforts, help them to engage the appropriate insiders and outsiders, brings together process owners when efforts overlap, maintains and promotes reengineering methodologies that are successful for the firm, and plans for common needs.
One final point is that "czar" may connote power, but it is a supporting role - such a person should encourage and support. If he becomes too controlling, he is interfering with the projects.