Successful Reengineering Demands IS/Business Partnerships

Breezy Services Company, a medium-sized service provider, was in trouble.1 New entrants threatened its domination of particular market segments, and competitors attacked its customer base. Its business practices and information systems infrastructure were decades old, and there was little hope of enhancing the company’s existing (or legacy) systems to support innovative products or services. And, although the company was still viable, its profit margins were shrinking.

Breezy’s top management decided to undertake a massive three-year business reengineering effort that would involve all business functions and include an extensive information systems (IS) project to technologically enable radical business change. Breezy executives expected the project to achieve orders-of-magnitude improvement in both operations and customer service. After initial analysis, selected business managers organized into teams structured around a newly defined reengineered business model.

IS also mobilized to support the business reengineering effort. After Breezy hired a new CIO from an external pool of candidates (and removed the incumbent CIO from the IS operations), the IS staff thoroughly assessed the company’s existing systems and IS employees’ skills and reorganized to focus on new technologies and operate parallel to the business reengineering teams. The department also introduced a new system development methodology and developed prototype systems to support business reengineering efforts using client/server technologies. Finally, the IS staff began to develop a comprehensive, long-term IT strategy designed to create an IS organization that would provide ongoing reengineering support.

Despite some earnest determination, however, the reengineering effort was only marginally successful in bringing about holistic, broad-based change. The reengineering teams found that making progress in the early organizing and creative analysis stages was easy and quite exciting. However, the later work of prototyping, experimentation, design, development, and implementation of new business models was much more difficult. In particular, they were surprised by the degree of organizational resistance they encountered, the complexity of maintaining quality communications with those outside the reengineering teams, and the difficulty in knitting together a working business model agreeable to all the constituencies on the reengineering teams.

The IS organization had mixed results as well. IS was able, for the first time, to introduce and support new client/server technology that incorporated server-based relational databases and client graphical user interfaces (which the business users embraced wholeheartedly). And IS did make permanent improvements in some legacy systems to support the new reengineered business model. However, IS did not deliver the systems and technology to enable the rollout of the new business model. Furthermore, because the IS staff also failed to help the business manage the reengineering effort, the project was plagued by a lack of coordination among teams and, as a result, was unable to meet its aggressive goals.

In the end, business reengineering at Breezy fizzled. Unfortunately, most of those involved did not seem to know what went wrong, when it went wrong, or how it could have been avoided.

The Challenge of Reengineering

Breezy’s effort was unsuccessful not because the company’s management misunderstood the concept of business reengineering; to the contrary, the initiative began with great promise because management clearly knew what reengineering is and is not. The views of some pundits aside, business reengineering (sometimes known as business process reengineering or BPR) is not just the management flavor of the week. It is not simply a slogan around which a poorly performing organization rallies the troops. And it does not mean just reducing head-count, streamlining business processes, or introducing new technologies. Business reengineering by definition radically departs from other popular business practices like total quality management, continuous improvement, or downsizing. According to its primary spokespersons, Michael Hammer and James Champy, business reengineering is “starting over.” It steps far beyond the incremental changes achieved by merely tinkering at the edges of the holistic business process.2

Organizations that truly reengineer achieve dramatic improvements in the way they do business and, in the process, realize impressive benefits: greater profitability, more effective employee utilization, and, perhaps most important, fundamentally improved, faster, and more efficient customer service. Business reengineering breaks down outdated assumptions and undocumented rules that impede radical thinking about developing cross-functional processes. To achieve these dramatic improvements, it is necessary to leverage IT to destroy what exists and rebuild by starting from scratch. The promise of reengineering is great; the benefits are real.

However, as business reengineering has made further inroads into corporations around the globe, reports of failure are emerging. Hammer, for instance, believes that reengineering has failed in 70 percent of cases, while some studies have cited failure rates ranging from a high of 84 percent to a low of 25 percent.3 Whichever statistic one believes, the fact is that some reengineering efforts fail. And, more often than not, the failure — including Breezy’s — can be attributed directly to the companies’ failure to engage IS as a true partner in reengineering and, where appropriate, allow it to assume leadership. Without the constructive partnership, technical leadership, and focused endeavors of the IS organization, a reengineering effort is doomed to fail.

The Need for IS Partnership

Breezy’s reengineering effort ran aground because its executive management did not ensure IS’s prominent role in providing valuable expertise and guidance. Information technology — hardware, software, telecommunications, and data management — is an essential enabler in reengineering, serving as an indispensable tool that supports redesigned business processes and facilitates cross-functional work flow.4 In most companies, the IS organization has the skills to identify the applicable technologies, design, implementation, and management of technology-based solutions.

The IS organization is also a source of another key ingredient to business reengineering success: large-scale project management skills and experience. Business reengineering projects are broad in scope and demand the rethinking and re-creation of all facets of an organization. As such, they are extreme examples of large-scale projects. The planning, management, and logistics challenges stretch the limits of even the best managers. The majority of businesspeople involved in a reengineering effort have had careers in areas such as marketing, sales, operations, law, and securities trading. However, although these areas are intellectually challenging and difficult, they do not expose managers to the structured demands of a large-scale project. Unless an organization has a natural demand to maintain project management skills within its business line management — such as in aerospace logistics or construction contract management — the internal IS organization is a logical place to seek those skills.

However, IS should not lead the overall business reengineering effort; that is clearly a job for the business process owners.5 The natural, obvious benefits of empowering business managers to lead reengineering initiatives are that it places responsibility and accountability for future business processes on those most knowledgeable about operations and most affected by the impending changes. However, because technology and project management are so important to the success of reengineering, it is imperative that the IS organization also assume a leadership role, where appropriate, in those efforts. With the technology itself no longer a limiting factor — the affordable processing power, flexible data access and management, and advanced data communications currently available can support highly ambitious business reengineering goals — IS must focus on its ability to direct large-scale projects and provide technical vision and leadership.

Table 1 shows a delineation of the roles for business and IS in reengineering. This is not necessarily the prescribed role allotment for all reengineering projects but presents one way a company can maintain clear business process ownership, leadership, and accountability while leveraging IS’s inherent expertise in technology and project management. The benefits of embracing IS as a full partner in reengineering solution analysis and development are implicit in the model.

In Breezy’s case, the reengineering leaders might have prevented such lackluster results if they had initially paid closer attention to the breakdown of business and IS responsibilities. Unfortunately, no one at Breezy addressed the project management challenge, and the IS organization did not aggressively demonstrate vision or leadership in identifying and using technology.

Facilitating IS Partnership

A complication in defining IS partnership and leadership roles is the way reengineering efforts greatly empower the business managers. This empowerment is necessary because business process owners must direct the reengineering project.

However, in practice, this often results in the disempowerment of IS managers, inhibiting IS’s ability to effectively use its technical and project management knowledge and experience. During reengineering efforts, business managers assume leadership roles and budgetary responsibility. IS people are commonly in staff roles and, in order to achieve the best possible business practices, may compete with outside organizations in providing IS services. This competition and the potential exclusion from the key reengineering teams, however, can make IS people defensive; staff members may become tentative and afraid to challenge the business managers. In turn, this creates the paradoxical situation of disempowering IS just when the business wants to significantly leverage the information technology expertise that IS can deliver. The risks are that creative technical solutions may be insufficiently investigated and relevant project management knowledge may be ignored.

At Breezy, for instance, sales and marketing managers aggressively took charge, marching forward with strong determination. They had waited a long time to reengineer and had a good deal of pent-up energy. Unfortunately, none were schooled or experienced in managing complex projects like business reengineering initiatives. As the project progressed, the IS managers assigned to reengineering teams could readily see many project management danger signs. For example, the team charged with creating new job descriptions, reward and recognition programs, and career paths had dangerously disconnected itself from the team that was reengineering customer sales. Because the business managers did not coordinate their efforts, the jobs they defined did not match the skill sets for operating in the technology-enabled customer sales roles. As a result, with each passing day, the efforts of these teams diverged more and more, creating the strong possibility that the employees drawn to the new jobs in customer sales would be underskilled technically.

IS team members attempted to convey their concerns about the lack of cross-initiative coordination and its damaging effects on the final reengineered model. Unfortunately, the business managers quickly dismissed their concerns as evidence of an old-fashioned command-and-control mentality. “The reengineering teams are excited and making progress,” the business managers surmised. “These IS guys just don’t understand the pace and empowerment of true reengineering.”

Without a legitimate position of power in the team structure, the IS managers at Breezy could not effectively register their concerns. Frustrated, many fell into the comfortable, familiar role of treating the effort as a traditional project. They asked business managers for requirements and made improvements and changes only when the business leaders instructed them and rarely on their own initiative. They were reengineering team members in name only, unable to brainstorm and collaborate dynamically with business process owners. Thus a primary source of valuable, necessary talent was seriously muted — and, in this case, project management danger signals were ignored.

Breezy is an example of an extreme situation that can arise when newly empowered business reengineering leaders assume that only ideas coming from the business side are worthy of consideration. They may view IS representatives as old-school thinkers or outsiders because IS personnel are not end-users of the systems they develop and maintain. In addition, business leaders may identify the IS staff too closely with the existing — and likely inadequate — computer systems that, unfortunately, can stymie IS’s efforts to bring credible technical and project management skills to the reengineering team.

Business reengineering process leaders should strive to partner with IS staff because, as reengineering moves toward implementation, IS professionals’ skills will be necessary for success. Furthermore, exclusion can damage or inhibit the overall spirit of teamwork and common purpose. Regardless of their background and prior loyalties, business reengineering team members are often overflowing with energy and accumulated ideas on how to radically improve processes. Having their positive spirit stifled just when change is occurring can have a disheartening effect on morale that could spread through the entire team.

Challenges for IS

Business managers should expect and encourage IS to provide leadership in two areas: project management discipline and experience, and technology vision and expertise. These two challenges are critical to IS’s success in the project and, by extension, to the success of the overall reengineering.

Provide Project Management for Large-Scale Projects

Many of the challenges and risks in business reengineering efforts are attributable to their large scale, rather than to their radical or innovative aspects. Managing the risks requires structure in some areas and latitude in others.6 Technical standards and methods become more important. IS team roles change, with some individuals serving as the “glue” between otherwise independent teams. Planning and anticipating requires both great attention and a flexible approach.

Perhaps the primary project management challenge in reengineering is managing the transition from creative experimentation to implementation of well-structured, tangible solutions. Implementing creative, out-of-the-box thinking requires managing the transition without losing the power of innovation and inductive thinking so essential to reengineering success.

An IS executive of a leading oil and gas company in the throes of a major business and IS reengineering project once noted, “When it’s all said and done, the bits are either on or off.” This captures the spirit of reengineering projects’ need for project management structure. Once creative thinking has been translated into IT-enabled new business processes and concepts, the overall solution must work — effectively, completely, accurately, and reliably. Even with the need for continuous learning looping back into business operations for continual improvements, operations must work correctly.

The introduction of project management discipline after a period of creativity can cause dissension among business and IS staff because of the delicate balance and critical timing required. Radical thinking is essential to reengineering; developing creative solutions to problems requires iteration through concepts, designs, and prototypes. However, once a decision is made to begin supporting business activity on the reengineered model, success depends on a well-managed effort to ensure implementation of quality systems and procedures.

For example, consider an on-line customer sales system prototype that was developed to the point where the business is satisfied with its operation and functionality. Before rolling out this technology to 200 sales representatives, it will likely be necessary to freeze all changes, perform rigorous testing, develop user documentation, add technical features such as the ability to restart transactions that are inadvertently aborted, and develop a sound training program.

How does an organization ensure that imaginative thinking — the core of reengineering initiatives — is not constrained by the structure of project management? One effective way (depicted in Figure 1) is to assign a time for creative thinking to be prominent and a time for project management structure and discipline to gain control. During the initial exploratory phases, there is likely no need for structured project management. Formal roles may be abandoned to encourage a free exchange of information. Often, basic questions are asked, scope is in flux, and the very existence of certain business functions or organizational units is challenged. Customer satisfaction surveys and cost analysis may reveal previously undiscovered problem areas. The reengineering teams may then move to prototyping solutions. Sometimes prototypes are developed, tested, and then discarded once they have served their purpose in enhancing learning and experimenting with new ways of doing business.

As solutions begin to take shape, however, they must be developed for actual business operations. Even if the solutions are limited in scope, for example, to a subset of the customer base, they still require a certain level of completeness. At this stage, effective project management should be established. When it is time to implement a reengineered business solution, the goals of reengineering become the same as those of good project management: ensure adherence to the vision, build a workable and implementable solution, maintain good two-way communications with all relevant constituencies, and plan for project logistics such as people, methods, and tools.

Creative thinking always has a role in implementation projects. Projects are dynamic, and new problems and opportunities arise at every stage. This occurs in all large-scale projects, including those that support reengineering.

Some of the other challenges and risks in managing large-scale projects are:

· Complexity.

Many large-scale projects fail because managers have underestimated the planning, logistical, and organizational complexity. Without a respect for a project’s enormousness, well-meaning managers can easily be overwhelmed by its demands. For example, systems integration — the development of a holistic, cross-initiative system design — is often ignored or de-emphasized, which may mean that reengineered business systems cannot be developed beyond stand-alone prototypes.

At Breezy, IS failed to train its people quickly enough in new technologies, tools, and methods, which resulted in shortages of trained personnel for reengineering projects, while legacy systems staffing levels were largely unchanged. Along with the lack of training for incumbent employees, IS did not augment its skills base with new employees fast enough to meet demands of new projects. Experienced large-scale project managers would have developed a training plan that identified the need and timing for new skills. Without a plan, Breezy management scrambled to supply the right skills to the business reengineering teams and, therefore, contributed to the slowdown in achieving results.

· Resistance to Change.

While resistance to new technologies is widely understood, large projects present change on many fronts and often encounter resistance from both current stakeholders and people merely uncomfortable with change.7 Change occurs in the project’s means and ends. New methods and development tools are required to develop IS solutions. In addition, the new systems and processes usually differ significantly from current operating practices. Unless the project managers have prepared communications plans, those interested in maintaining the status quo may undermine the project’s plans.8

At one insurance company, for instance, the claims investigation process was being reengineered. The new process required consolidating the claims investigation functions of several insurance lines into a single unit. This meant job loss, reduced process steps, and, for some low-dollar claims, little investigation. In all, it was a very thorough, bold reengineering vision. However, the claims managers were dismayed by their loss of power and the likely layoff of long-time claims adjusters. They forcefully argued that their fiscal responsibility required that all suspect claims be investigated; beliefs to the contrary were misguided. The result was a protracted stalemate between the business reengineering team and the old guard, which stalled the project for some time.

· Lack of Experience.

Organizations attempting business reengineering have historically delayed major systems investments that provide longer-term payback. Their IS projects have been small and focused on incremental changes to current systems. Even worse, some organizations have tried and failed to make large-scale systems change. Now they have become gun-shy about large efforts and instead use incremental approaches to satisfy business operations needs. As a result, previously attempted, large-scale projects often are managed by people who have never before successfully planned and executed major business, systems, or technology change.

One telecommunications company attempting ambitious, cross-functional reengineering relied on managers well schooled in both the business and technology. These managers, viewed as the best of the best, were chosen because of their responsibility for and hands-on management of a recent successful product launch that innovatively used leading-edge technology. It was therefore a surprise when they were unable to progress beyond the initial stages of reengineering. What the business leaders who assigned them this role did not anticipate was the managers’ complete lack of large-scale project experience. The managers were likewise stunned to discover that the techniques and practices that had been previously successful were now quite ineffective.

· Underestimating Migration.

Implementers of large-scale change strive to attain big improvements in business operations because of the expenditure of time and money that large projects require. However, sometimes this tempts them to design a utopian solution without thinking about a migration strategy. When this happens, the new systems and processes may make academic sense, but may not be implementable because it is uneconomical to transfer functions, products, locations, or databases to the new model.

At Breezy, a few business reengineering teams that were using prototype technology reached a point where they considered using the new business model in regular operations. However, when it was time to move beyond the limited prototypes, business decision makers balked at IS’s plans and estimates for rollout; the costs seemed too high and the schedules too long. Business leaders were also confused when they learned that underlying technical components would be wholly replaced for performance, security, and technical maintenance reasons. IS was unable to communicate successfully the difference between the effort and technology to support, for example, 1,000 customers on a prototype system and that to support 500,000 customers on a production system. Partly for this reason, the improvements were never funded or completed.

Part of Breezy’s difficulty in managing the transition from prototypes to wider implementation was due to a lack of migration planning. Good project management would have identified a trade-off: balance the costs of creating an unrestrained view of the future with the costs of adopting technical standards that make the prototypes more easily scaleable to regular business operation volumes. This control of scope is grounded in the reality of finite budgets.

Provide Technical Vision and Leadership

Revolutionary business change is facilitated by leveraging the power of technology. As a vocation, technology implementation is a complex specialty. Without a grounding in technology, few business managers are capable of assuming this leadership role. Thus they must recognize that, as technology experts, IS people can and should take leadership and visionary roles in devising ways to use IT for the business’s benefit.

Typically, IS units operate as “order takers” and “systems mechanics.” They do what the business managers ask and fix technology when it breaks. Business reengineering, however, demands that IS play a technology leadership role that requires innovative and visionary thinking. IS must balance its leadership in its area of expertise with supportive partnership with business managers. If it overemphasizes leading, IS may become disconnected from the business — perhaps to the point where managers look elsewhere for their technology needs. On the other hand, if IS concentrates too heavily on following, business managers may find that critical IT and technology management considerations are overlooked.

There are some instances when the lack of IS technical leadership inhibits the overall business reengineering initiative:

· A Focus Only on Visible Technology.

Without a deep understanding of technology and the methodology of building information systems, business people can undervalue the need to focus on systems infrastructure requirements. For example, business leaders may not approve a project to validate and clean up customer data because they do not recognize its need, even though data quality is critical. Similarly, an IS organization that is not in full partnership with the business may have difficulty obtaining approval for necessary internal development tasks, such as introducing a new methodology or developing technical coding standards.

For example, at Breezy, technical integration of business reengineering team initiatives did not receive adequate attention. The integration was invisible to the business managers and therefore deemed unimportant. With no advocacy, efforts such as the development of an integrated database and common coding objects faltered. Without an integrated database and common programming, the reengineering initiatives could not proceed beyond modest prototypes because the technology output from each reengineering team did not fit together or communicate.

· Estimate of Project Complexity and Size.

Inexpensive, easy-to-use microcomputer-based tools enable organizations to develop system prototypes and mock-ups (i.e., nonworking prototypes) quickly and cheaply. Business reengineering teams can prepare their own system mockups without IS participation, a benefit, however, that leads to potential misunderstanding. For instance, a team may ask IS to estimate what it would take to transfer a system mock-up the team developed with a few inexpensive software packages to a system that works from actual customer data. Unless the team members understand the dramatic differences between the two systems, they may be shocked by the project’s size, cost, schedule, and complexity.

The complexity of a reengineering initiative is frequently underestimated in testing the integration of several new technology systems. As the reengineering teams that focused on individual business processes begin to work toward their new vision, they must develop and test complex process and technology integration. Such tests require significant resources for preparation and execution. For all projects, these work phases frequently are underestimated and therefore underresourced.9

At Breezy, for example, the schedule of the overall integration test was developed by backing into a business-defined deadline. Appeals by some of the IS managers to develop a more accurate estimate and critical path were not heeded as key executives were eager to drive the team toward the reengineering deadline. Some were not surprised when the integration test ran significantly beyond its schedule and ultimately was cancelled before completion.

· Development of Holistic, Practical Technical Architecture.

Technology specialists can develop a holistic framework of necessary technical components that must gradually be built to support the new model. The framework is not a detailed specification but will allow the orderly, gradual creation of new technology to support the rollout. While highly technical, a holistic architecture framework has advantages for the business because it allows processes that leverage technology to be implemented within the context of a flexible, evolving technology plan.

Breezy’s technology leaders had the foresight to plan a long-term technology strategy and framework. However, they bogged down in the architecture development: they hesitated to translate the reengineered business vision into technology architectures on their own and were unsure how to involve business in the process. Proceeding cautiously, IS senior management eventually developed a “least common denominator” strategy that took weak positions and left the long-term technology frameworks and standards without definition or schedules. IS people were uncomfortable in the role of translating the business vision into a technology vision —even though they were the only ones capable of doing that.

How to Proceed and Succeed

Business leaders should ask their IS organizations for the enabling technologies and systems to achieve advances in operational effectiveness and efficiency. However, management’s direction to IS is often too vague. Typically, business managers do not know enough about IT to give IS staff a list of requirements. Modern technologies and methods are advancing too rapidly to reasonably expect business operations managers to understand the technology currently available, feasible, and advisable.

As I discussed earlier and illustrated in the Breezy example, IS should provide the initiative and leadership to meet the IT and project management challenges of reengineering. But business managers also must give IS direction and room. Next I outline an effective five-step model for business and IS. My objective is to define IS’s orderly approach to facilitate business reengineering by working toward the two critical success factors of project direction and technical vision and leadership. While many of the items in these steps fall in IS’s bailiwick, it is the business managers’ responsibility to ensure that IS understands and executes them.

1. Redefine IS’s Role

Ideally, IS should recognize the need for change and take the lead in redefining itself. If the IS staff is reluctant to take the initiative, business reengineering leaders should encourage them and involve its managers in assisting IS. IS and business should strive for a lively, creative, constructive debate on IS’s new partnership role. Both business and IS should agree on where IS is expected to provide leadership and vision, and where IS is expected to partner and support. Following are a few areas for exploring definition and priority. These topics do not imply a strictly correct direction for IS, but raise issues and provoke thought.

• Advocate for the company’s technical agenda. Modern computing presents all organizations with a great proliferation of technology alternatives, and there are many trade-offs between standardization and flexibility. For example, is it really beneficial to have three new applications that each uses different client operating systems and different network configurations? What are the implications for maintainability? IS should determine its role in defining IT strategic direction and the gradual adoption of standards.10
• Translate business vision to technical reality. Frequently, business leaders document their new business vision as a set of principles and goals. IS should analyze the vision to determine its technical implications. For instance, IS may determine that the business goal, “All customers will be able to have highly customized service billing,” implies the need to eventually discard its current billing system.
• Apply project management expertise. Frequently, IS is the logical source for experienced large-scale project management. The questions then are: Should IS provide the project management expertise for business reengineering? How will business give IS a legitimate role in order to gain the greatest benefit from project management disciplines? If a large-scale project has not been undertaken successfully for some time, will it be necessary to go outside business and IS to find competent large-scale project management expertise?
• Make the transition from order taker to partner. Business and IS leaders must consider: How can IS act as a partner with business to achieve the greatest benefit? Does it make sense to make IS representatives full and equal participants or technical coaches only? If IS is not a full participant, how can business ensure that the technical possibilities and constraints are adequately considered? How can IS raise awareness of “invisible” and “un-sexy” issues such as technical infrastructure or the need for IS investments in training and software tools?

2. Assess Current Capability

To plan where you are going, you must first know where you are. Business reengineering efforts focus on innovative processes. IS’s role is to assess the feasibility and steps for migrating to reengineered processes and includes assessing current capability.

Business leaders should direct IS to systematically evaluate the major technology architecture and capability. Typically, these areas include applications, data, organization, and technology. The organizational assessment should analyze relevant employee skills, experiences, and methodologies. The technology assessment should include development, production, and telecommunications technologies.

In preparing for the challenges of business reengineering, IS’s focus should be on the future rather than on past mistakes or academic inventories of current technology. IS should analyze the legacy system’s ability as a foundation for future needs and also determine improvements necessary to migrate to the new way of doing business.

The assessment enables IS to investigate and analyze areas less visible to the business and more in the realm of technical infrastructure or support. It is unlikely, for example, that business leaders would request improvements in data quality, development of more reliable backup and recovery procedures, or upgraded database management systems or software development tools. IS should use its assessment as a forum to educate business on critical items that, although invisible, can inhibit progress.

Some business leaders may say that IS is looking backward rather than forward. Others may imagine that IS has hidden motives to retain current systems rather than obliterate them. Should such concerns occur, business reengineering leaders and IS should resist them. Such critics expose the effort to the risk of defining a reengineering utopia and impossible schedules based on the legacy applications, data, and communications. Leaders should strongly encourage IS to ground reengineering in technical reality.

3. Develop a Strategy and Architectures

IS should develop an IT strategy to support and enable the objectives of reengineering over the long term. Business leaders should ensure that IS develops the strategy and architectures in coordination and cooperation with ongoing business reengineering. The strategy and architectures should encompass the applications, data, organizational skills and experience, methods and practices, and development, production, and communications technologies that were assessed earlier.11 For example:

• Developing a data strategy and architecture is central to successful implementation. Typical legacy systems’ data structures are disjointed and do not allow a consolidated view of customer or product information. Often the access to legacy data does not reflect common business process needs. IS can develop a new data architecture and address data management software and data quality.
• Analyzing new technologies and developing a technical architecture is another area where IS planning facilitates reengineering. For example, client/server technologies can significantly enable reengineered processes. IS can develop a technical architecture that leverages the power of client/server technology and provides for future enhancement and maintenance.
• Because business reengineering teams’ efforts frequently begin as independent initiatives that must be integrated when fully implemented, IS should develop an applications integration architecture. Without such an architecture, independently developed applications may need to be redesigned to enable integration.
• IS can benefit by defining its people, tools, techniques, and methods as an “architecture” area requiring a plan. The organization architecture is perhaps the most critical for IS. It should start by assessing current capability as it relates to the IS organization, which can be the basis for an analysis of training and/or hiring needs. Training should involve both the hard skills of new languages, methodologies, and technical platforms, and the soft skills of business partnership, workshop techniques, and facilitation.

4. Develop a Master Plan

During a reengineering effort, IS balances a number of different priorities, like maintaining the legacy systems, participating in reengineering teams, reorganizing IS, and developing long-term strategies, architectures, and other enhancements or projects. The business leaders should encourage IS to develop a master plan to ensure its control of all resources and critical paths. Business leaders and IS should then use the master plan to set priorities and recognize the infrastructure and support for implementing a reengineered model.

As I discussed earlier, reengineering initiatives are challenged by the transition from creative experimentation to more structured implementation. The master plan should recognize this transition and balance support for creatively focused reengineering teams by including tasks that address implementation.

Some think that business reengineering implies there is no need for planning; they cite the need for IS to remain nimble, flexible, and open to new ideas. While this thinking is partly true, it ignores how the IS staff can use its knowledge of the IT strategy, current legacy capability, development methodologies, critical path planning, and project management to anticipate and plan.

Without a plan, IS can find itself stretched too thin and incapable of meeting all its commitments to business reengineering teams and others. Regardless of whether the thinking is old or traditional, project crises usually result from a lack of advanced planning.12

5. Execute and Manage

Planning is only part of the overall solution. Consider Peter Drucker’s comments: The best plan is only a plan, that is, good intentions, unless it degenerates into work. The distinction that marks a plan capable of producing results is the commitment of key people to work on specific tasks. The test of a plan is whether management actually commits resources to action which will bring results in the future. Unless such commitment is made, there are only promises and hopes, but no plan.13

Drucker points out that plans are worthless unless they are used. His words would seem unnecessary, were it not for the number of projects (reengineering and otherwise) that fail to achieve their objectives by not following their own best counsel as represented by their plans. In maintaining overall responsibility, business managers should ensure that IS follows its plan. The business should particularly direct IS to focus on the critical paths such as technical training, staff augmentation, and technology equipment acquisition.

Conclusion

Working with business managers on reengineering activities, while supporting ongoing responsibilities, severely tests the mettle of most IS executives and managers. The challenge could not be more formidable: help obliterate and recreate what exists today, while keeping current operations running smoothly. The business’s active involvement in directing IS is essential because the business is much more than a casual observer.

During reengineering, business leaders call on IS to do many things: reorganize and redefine its role and mission, explore and define the meaning and role of leadership in its new mission, and prepare to manage a complex large-scale project for perhaps the first time. The excitement of experimentation quickly cedes to the practicalities of achieving reengineering through the implementation of new business processes and systems. Throughout, IS must balance its role of technical leadership and business partnership.

There are no secrets to success, but a productive approach borrows from traditional and breakthrough management practices. What could be more traditional than developing architectures and master plans? Conversely, what could be more innovative than working with the business in partnership and developing prototypes?

Erring to either extreme can result in a company’s inability to achieve the promise of reengineering. On one side, traditional thinking is incompatible with the spirit of breakthrough thinking and experimentation. On the other side is the risk that infrastructure and support activities will be ignored or mismanaged and therefore will undermine the implementation of reengineered business processes. For reengineering success, business leaders and IS must work together to strike the balance.