Project management keeps reengineering on the right path
To achieve success, we must reengineer the way we reengineer. The project management functions of leading, planning, organizing and controlling are the keys.
Ralph L. Kliem
Ever since Michael Hammer and James Champy published their celebrated work Reengineering the Corporation, business process reengineering (BPR) has been on the minds of executives. This interest has been backed by bucks. Currently, American firms are spending about $30 billion a year on reengineering and that figure will expand to over $50 billion in 1997, according to a Systems Reengineering Economics survey of 1,200 corporations (Information-Week, June 20, 1994, p. 50).
Despite this intense interest in and application of BPR, an undercurrent of dissatisfaction is growing. According to a survey of 600 information systems (IS) executives by Computer Sciences Corporation, BPR has fallen from top priority in 1990 to fourth place in 1995. It was eclipsed by (1) aligning IS and corporate goals; (2) instituting cross-functional IS; and (3) organizing and utilizing data (ComputerWorld, March 13, 1995, p. 6).
Other surveys reveal the same findings. Two surveys of IS and business executives at Fortune 1,000 firms by Arthur D. Little, Inc. revealed that over 80 percent expressed dissatisfaction with BPR efforts and over 65 percent said BPR had “unanticipated” or “unintended” side effects (ComputerWorld, June 13, 1994, p. 1).
Clearly, BPR has failed to meet the expectations of many executives. But why?
The four major functions of project management help avoid such reengineering problems as vague goals and objectives, unrealistic expectations, lack of adequate resources, minimal performance, and poor follow-through.
A major contributor may be the lack of project management disciplines applied on BPR projects. According to an Ernst & Young survey of chief financial officers at 80 corporations, over 85 percent plan BPR projects and 50 percent of them lack any “consistent” approach to measuring project performance (ComputerWorld, May 8, 1995, p. 28).
A study of 24 large users by the IBM Consulting Group revealed that project management was a critical factor for successfully completing client/server reengineering projects. Interestingly, most of the other items were project management issues, such as timely implementation, high customer satisfaction, skill participation, finishing within budget, and business support (InformationWeek, September 5, 1994, p. 52).
Michael Hammer, in an Information-Week interview (June 20, 1994, p. 60), cited three reasons directly related to project management that contribute to BPR failure:
- Lack of executive commitment
- Lack of knowledge about what they're doing
- Lack of knowledge on how to proceed.
In other words, lack of project management.
What is Project Management?
A common perception is that project management is only scheduling. Quite often, ask anyone what that means and they say “bar chart,” a “network,” or “PERT diagram.” Yet schedules are only one facet of project management. In a broader sense, project management is the knowledge, tools, and techniques to lead, plan, organize, and control projects. Leading, planning, organizing, and controlling are the basic processes of project management.
Leading means motivating people to perform satisfactorily. Planning means determining in advance what the project will achieve. Organizing means arranging resources in a manner that expedites the achievement of goals. Controlling means determining how well a project is progressing according to plans and taking corrective action, if necessary.
Many BPR projects go awry by failing to implement project management. Many BPR participants think their project is “unique,” excusing the application of well-known project management disciplines. Yet, as shown earlier, many BPR projects fail due to poor or nonexistent project management. They fail because project planners neglect to define the goals to accomplish, who performs tasks, when to complete major milestones, how to achieve objectives, where to conduct tasks, and even why the project exists.
According to a survey of 365 people (PCWeek, January 23, 1995, p. 74), the Standish Group International, Inc. discovered the following contributors to project failures that can also occur on BPR projects:
- Changing requirements and specifications
- Incomplete requirements
- Lack of executive support
- Lack of IT management
- Lack of planning
- Lack of resources
- Lack of user involvement
- Not relevant
- Technology illiteracy
- Unrealistic expectations.
How PM Can Help BPR
The four processes of project management can help BPR projects solve many problems.
Leading. A BPR project involves many players and, indeed, the process or processes being reengineered involve a variety of people. Widespread participation is absolutely necessary. Commitment, teamwork, and stakeholder involvement are critical for BPR project success.
A Deloitte & Touche survey of 400 chief information officers (Computer-World, October 3, 1994, p. 96) revealed several obstacles to BPR success, mainly motivational in nature:
- Lack of cross-functional project team
- Lack of executive consensus
- Lack of senior executive champions
- Limitations of existing systems
- Resistance to change
- Unrealistic expectations.
Leading provides the mechanism for overcoming such obstacles by encouraging ownership in the project plans.
One motivational project leadership tool is widespread participation in developing work breakdown structures, time estimates, and schedules. This builds ownership and, consequently, commitment. Project managers often implement such tools top-down, thereby only encouraging resistance.
BPR projects frequently have a cross-functional orientation. Without the input of key players, the opportunity for resistance multiplies. Participation in the development of project plans reduces fears and, of course, such resistance.
Two other project leadership tools that generate project support are publishing a project announcement and developing a statement of work.
The project announcement is a memo announcing the project, describing its goals, and appointing the project manager. A senior manager, who champions the project, signs it. The announcement helps to avoid the problems created by the lack of an executive champion or top management support.
The statement of work (SOW) defines the goals and objectives of the project and, just as importantly, of the customer. When the customer signs the SOW with the project manager, both agree to the goals, constraints, and major deliverables for the project. A SOW clearly aids in generating consensus and eliminating unrealistic expectations early on.
BPR promises many benefits (for instance, increased profitably) and people often exaggerate them. A statement of work helps bring everyone back to reality by identifying what is and is not possible.
Planning. This process is widely known but often not applied very well. It entails defining the tasks to perform, their sequence of execution, their times of occurrence, and the right people to perform them.
One planning tool, the work breakdown structure (WBS), is a top-down listing of tasks to perform to complete a project.
Many problems with BPR projects include not only lack of planning but an inability to determine exactly what to accomplish.
A WBS forces all project participants to be specific and accountable for their own tasks and, ultimately, for the quality of the final product. A WBS encourages specificity and accountability because it “explodes” tasks into sufficient detail to track progress. It also encourages accountability because it enables better tracking of people's performance.
For example, BPR projects often create tasks like “Choose Tool.” Such a task is so high-level that it's difficult to measure progress against it. With a well-exploded WBS, however, tracking and monitoring becomes more meaningful; a WBS makes it possible to detect slippage in a task and the impact the slippage has on subsequent tasks.
A second planning tool is the time estimates to perform each task in the WBS. Using the famous three-point-estimate technique (most optimistic, most likely, most pessimistic), estimating the work to perform becomes less of a scientific wild-??##!!-guess and more of a rational prediction. It helps avoid unrealistic expectations and enables the project manager to anticipate resource requirements reliably.
For example, the person responsible for “Choose Tool” may give a highly optimistic estimate that doesn't account for the complexities in selecting a tool (e.g., workflow technique).
A third planning tool is the schedule. A network schedule reflects the sequence of tasks in the WBS. This sequencing helps determine the start and stop dates for each task. A network diagram can easily be converted into a bar chart if management prefers the latter.
Schedules are only as valuable as their level of reliability and understandability. Because BPR projects frequently cross departmental boundaries, different audiences must use and comprehend schedules. For BPR analysts, for example, a network diagram may be more appropriate; for management in each department, a bar chart may be the preferred medium of communication.
A schedule can prevent BPR projects from continuing without results. It creates visibility, cuts short unrealistic expectations, forces everyone to plan, generates commitment, and reduces the “analysis paralysis” that frequently occurs on BPR projects.
A fourth planning tool is resource allocation, which entails assigning people to perform each task using the duration of the task, the time to complete it, and the availability of the resource. The resulting resource profiles, or histograms, help determine realistic resource utilization; “smoothing” the profiles to enable efficient and effective use of resources. Smoothing is done by reducing the product to build, by changing the logic of the schedule, or by altering team composition.
Resource allocation not only encourages the efficient and effective use of resources, it also reduces or eliminates other problems, such as determining adequate availability of resources and obtaining the right level of participation.
Organizing. Common sense tell us to arrange resources in a way that expedites achievement of project goals. Yet BPR projects commonly confront problems such as unclear responsibilities, ineffective resource application, poor skills mix, and inadequate resource availability.
Fortunately, several tools exist to organize BPR projects efficiently and effectively. These include a responsibility matrix, an organization chart, a project history file, a project manual, a project wall, project procedures, communications infrastructure, and tools.
The responsibility matrix is a chart or listing of the tasks and the people who perform them. The information can often be provided by person, by task, or for the entire project. This simple tool helps to address the problem of gaining consensus on BPR projects. The reason is that once the responsibility matrix becomes public, people—even those located in another functional area—feel compelled to take their commitments seriously.
An organization chart reflects the reporting relationships among different team members. It facilitates communication, clarifies responsibilities, and identifies formal interrelationships among participants. Because BPR projects have a cross-functional orientation, the roles, reporting structure, and responsibilities are frequently complex and unclear. An organizational chart helps to overcome this problem.
Project history files serve as a repository of key paperwork created on a project. The file helps to overcome problems when trying to perform audit trails, referencing background information for critical decisions, and conducting an impact analysis of changes to the goal or tasks performed on a BPR project.
The project manual is nothing more than a compilation of reference material, such as phone listings, work breakdown structure, and recent schedule. Each participant receives a copy. The advantages of having a project manual include expediting performance and improving communications, two major stumbling blocks on BPR projects.
The project wall or room contains the major documentation for the project. Examples of items hanging on the wall might include a high-level WBS, network diagram, and responsibility matrices. The wall not only facilitates communication but gives essential visibility for a BPR project. Often, many people wish a BPR project would just fade away. A project wall or room doesn't disappear and the same goes for the project it supports.
Project procedures can help BPR projects greatly and they need not be highly formalized or detailed. However, they should exist in some form and address the who, what, when, where, why, and how of subjects like collecting project data, holding status review meetings, and managing changes to a schedule. Procedures help reduce problems with communication and coordination—that is, if they're available to everyone on the project.
The communications infrastructure includes the responsibility matrix, organizational chart, project history file, project manual, project wall, and project procedures. But it needs one more element: meetings. Meetings build esprit de corps and facilitate communication if they are well-run and relevant. Staff, checkpoint review, and status review meetings are the three basic types of meetings for BPR projects.
Staff meetings are regularly scheduled sessions involving team participants. A checkpoint review is held upon achieving a major event or milestone (e.g., documenting the “As Is” process); often it results in a go/no-go decision to continue the project. Status review meetings are regularly scheduled sessions to collect data and assess project performance.
The right tools can help a BPR project proceed efficiently and effectively. The main tools are often the methodology (e.g., value analysis, process flow, activity diagrams, object-oriented diagrams) for capturing “As Is” and “To Be” processes and the workflow tools (e.g., Open/Workflow by Wang Laboratories, Inc. and Action Flow by Action Technologies, Inc.) to build and analyze processes. Output from planning, such as the SOW and the WBS, allows the identification of the appropriate tools.
A major obstacle in BPR project success is using the same tools to document, analyze, and revise processes. By identifying the right tools early via the SOW and WBS, communication not only improves but everyone knows what tools to apply when. Converting diagrams and data, for example, becomes minimal.
Controlling. Having plans and organization in place is fine but an effort must exist to ensure that what exists is actually used. That's where project control comes in. Controlling ensures that a project progresses according to plan. It involves detecting variances to plans, managing change, taking corrective actions if necessary, and using meetings. Detecting variances involves identifying the difference between what's expected and what exists. Variances can be either positive or negative.
BPR projects can easily deviate from project plans due to the breadth of processes being reviewed. Such projects are famous for costing considerable money, taking a long time to complete, and involving many quality issues. Citibank N.A., Amoco, GTE, USWest, and American Express are examples of companies having lengthy, costly BPR projects. But, from a project management perspective, cost, schedule, and quality can coexist.
Good tracking and monitoring of schedule, budget, and quality enables the meaningful evaluation of project performance at any time. Such practices help to identify variances before they become disasters. By identifying variances, project managers can provide consistent follow-through from concept to implementation. Long-term focus remains on achieving goals and objectives by consistently reviewing cost, schedule, and quality.
Managing change helps to handle one of the hardest aspects of managing BPR projects. Documenting and analyzing the “As Is” and “To Be” processes takes time. Changes to the baseline for each process requires control; that means developing ways to identify, document, analyze, and publish changes. This, in turn, makes it possible to do an impact analysis on the new process, schedule, and budget. BPR projects frequently suffer from misaligned objectives and inflexible requirements definition.
Holding the right meetings helps control BPR projects more effectively. BPR projects, because they deal with processes that cut through multiple functional areas, require good representation and participation. It's important, therefore, to determine in advance answers to the who, what, when, where, why, and how of a meeting and to communicate that information.
Project management also provides an important means of controlling future BPR projects by providing the opportunity to identify what went well and what needs improvement. Such lessons learned help to build on strengths and avoid difficulties on future BPR projects. For example, a network diagram can reveal tasks that were difficult to perform. With that information, the project managers of future BPR projects can take the necessary steps to avoid repeating the mistakes of the past.
Lead, Plan, Organize, Control
In two surveys of Fortune 1,000 firms conducted by Arthur D. Little, Inc., approximately 85 percent of the IS and business executives responding felt dissatisfied with BPR endeavors (Computer-World, June 13, 1994, p. 1). In addition, about 70 percent identified a host of unexpected problems, such as no management buy-in and poor implementation skills. The four major functions of project management, when applied to BPR projects, help project managers avoid these problems and many others, including vague goals and objectives, unrealistic expectations, lack of adequate resources, minimal performance, and poor follow-through. ▄
Ralph L. Kliem is a corporate auditor for a Fortune 500 firm and president and cofounder of Practical Creative Solutions, Inc., a Redmond, Wash., consulting and training firm.
PM Network • August 1996
PMI research shows project teams that draw from an array of perspectives and skillsets deliver powerful outcomes.