Printer Friendly

Operational planning: going beyond PERT with TQM tools.

Conventional planning occurs in a spectrum from long-term (strategic) planning through project planning. We begin with vision and mission statements, define strategic objectives and adopt mid-term goals. This kind of planning is macroscopic and is necessary to provide overall direction in an organization. Mid-term goals may be further defined as a set of actions necessary to realize them, and these actions may be organized into projects. Project planning addresses sequences of activities, resource requirements and scheduling of work. Typically in a network format, such as PERT or CPM, the project activities are organized and resources assigned. The methodologies for this, including leveling resources and shortening the critical path, are well known. Beyond definition of activities, however, there is little guidance. Prior to the use of TQM methods, completion of activities was either left completely to the discretion of the responsible person, or, in large projects, activities themselves were large enough to decompose into a mre detailed project network. This left more activities with little guidance for their completion.

Risk is another issue that has been incompletely addressed in projects. True, PERT considers risk in activity completion time and provide a statistical estimate of the critical path time. Further advances hav been made in considering project activities as a stochastic process. Risk in successful completion of an activity had been addressed through Monte Carlo simulation and flowgraph analysis usually applied to the overall project. While this may provide information about project completion, it is of little help in avoiding failure with an activity.

In general, timeliness and success of activities have been left to management of the functions concerned. While this may be adequate in endeavors where activities are routine and timeliness is purely a function of resources, there are many project environments in which these assumptions do not apply. In research and development, for example, not all activities mau be completed successfully. In reengineering of production and business processes, it is not uncommon to find that improvement goals depend on success of new activities, and activity schedule and success are functions of more than resource applications.

We have three factors, all quality related, which allow us to take a fresh look at the operational level of projects -- that is the planning and implementation of activities. First, the emphasis on building in quality through design places new emphasis on the conduct of projects in research and development. Second, the reengineering of processes in continuous improvement brings about projects, typically conducted in teams, that are not routine in the sense of knowing -- in advance -- exactly what is required for success. Finally, many of the tools of TQM have been found to be useful in project planning and implementation. In particular, policy deployment provides the missing factor in managing successful activities, in that it provides the two-way communication between project and activity detail that is necessary to ensure success. The impact of these factors on project planning is described.

Planning with TQM

One of the most important aspects of TQM is its emphasis on planning and organization of work. Another is its strong use of teams and teamwork. Taken together, these emphases of TQM are highly applicable to project planning.

Figure 1 shows one possible integration of TQM tools and project planning. The process begins with the definition phase of the project. In this phase, we are primarily concerned with properly identifying project objectives and organizing those objectives into a manageable structure. The affinity process is a good method of synthesizing result of brainstorming. In this process, the project team is guided by an overall theme or task description, and within this description places objectives in groups based on their relationships. While this begins to imply some organization, the use of a tree diagram is helpful in adding organization beyond the affinity diagram and is bringing practicalities to bear on what might be idealistic.

The next phase is analysis. In this phase, the relationships among the objectives become clearer. The influence diagram, also called the inter-relationship digraph, is used to show graphically the casual or sequential relationships between pairs of objectives. Taken to completion with consideration of all pairs of relationships, we typically find patterns identifying key objectives or potential project bottlenecks. This leads us into a top-down flowchart, which show the marco level structure of the project as defined so far, and the flow diagram, which provides more information on sequence of potential activities. Note that at this point we are still defining the components of the project. The analysis phase ends with an assessment of our knowledge about these potential activities. This knowledged is organized through use of cause-and-effect diagrams, pareto charts and qualitative matrices of various type and shapes.

In the specificationphase we begin to define activities in more detail. A key step is development of operational definitions to ensure that all concerned have the same understanding. In particular, we may refer back to the current knowledge step and score or rate the current knowledge of potential activities. We can then use a pareto analysis on those scores and develop detailed operational definitions for those activities whose current knowledge is low. Next, we take those important activities that may be accomplished in teams or across departmental boundaries and develop deployment charts. These are flowcharts with an added dimension of responsibility. That is, deployment charts depict activity flow as well as who is involved in components of the activity.

All of these steps up to this point are really preparations to develop a plan in the conventional sense. The next step, which describes the structure of the project, may be done with a conventional PERT or CPM network. This is what people frequently mean when they say "project management." The quality and usefulness of this step, however, very much depends on how the structure was developed. The quality of the project plan depends on the quality of its planning. The earlier steps, beginning with definition of objectives, are important in providing definition, structure and the ability to revise and modify in simple ways, leading to a superior project structure.

Conventional PERT and CPM do not consider risk of successful completion of activities. A useful alternative when risk is a potential problem is the process decision program chart PDPC). An example of a PDPC use in this planning mode is found in Figure 2. this chart begins as a macro-level flowchart. For each activity we may have one or more optional approaches leading to completion. Each approach may have one or more possible outcomes, depending on the environment and problems encountered. Some of these outcomes may be undesirable. For each outcome, we then attempt to define a contingency plan in one of two sense. Either we allow the outcome to occur, and wish to recover fron it and move on, or the outcome is so negative that we wish to prevent it. Within each activity, we can study options, outcomes and contingencies to a great extent prior to beginning it. As a result of this study, we protect ourselves against undesirable outcomes by planning contingencies or selecting different options.

At this point the project activities and their relationships are defined and conventional project planning would stop. What we have done so far is to reduce an indeterminate process (achieve the original objectives or mission) to a set of determinate processes with known relationships. We have done this in a planned, structured way, designed to allow consideration of alternatives, identify gaps in knowledge, and reduce potential confusion. As a result, the plan developed is probably superior to one developed with no particular structured approach.

Most of the methods used to this point are those associated with the "Seven QC Tools," and the "Seven Management and Planning Tools." This use of flow diagrams and top-down flowcharts is described very well by Scholtes. Deployment charts are described by several authors, most notably Tribus. The concept of operational definition has been very well expounded by Deming.

Effective deployment

The steps leading up to defining the structure of the project are not especially difficult, requiring more will than expertise. The remaining steps, implementation and review planning also require the will to delay starting work on activities until planning is done. Implementation planning also requires some creative thought on ways to monitor progress within activities. Methods from policy deployment are very useful here, in particular the targets/means matrix and the flag system.

The key to good implementation planning is the alignment of goals and metrics. That is, each activity, and possible major components of activities, has one or more goals that are translated from overall organization goals. If a large corporate goal is to reduce downtime of equipment, the maintenance department goal might be to reduce downtime due to breakdown. A project within the maintenance department might have an activity involving training personnel in maintenance of a particular class of equipment. The goal for this activity would be to reduce its fair share of downtime is caused by lack of training in the equipment class. However, the metric for the activity detail. In this case, it could be the extent of training completed. The idea is to find a metric related to the progress of the activity and choose the metric so that it is closely correlated with the goal that has been deployed downward in the organization.

Figure 3 is an example of a targets/means matrix. In this context, the project activity is middle-manager progress in improvement. The targets, such as achieving high levels of personal and employee training and reducing project lateness, are translations of target from higher levels in the organization. Each of these has a code number (to assist in automating data entry and analysis), an item to measure (such as manager continuing education hours), and a way to display the data (such as a bar chart). In the language of policy deployment, these are called control points because they control, at the output side, the success of the activity, and deviations from targets are fed back as control signals. The means, such as holding informal quarterly personnel reviews, are the things done to achieve the targets. They also have code numbers, items to measure and ways to display the data. These are check points, in the sense that the manager in question can track these items and dedicate resources to them; they are within the manager's zone of influence. The symbols in the matrix show relationships between targets and means. These are commonly found in tools originating in Japan. The filled circle shows a strong relationship, the empty circle a moderate and the triangle a weak one. They are very useful in allowing some relative interpretation in a matrix be purely qualitative. In the targets/means matrix, they show relationships betwen measures on what the manager controls (means) and how the manager's performance is evaluatd from above (targets).

Figure 4 is an example of a flag system, a method used to track progress when several individuals or departments share in work that leads to success in a larger activity. In this example the measure, which could be a target or a means, is the number of personnel trained in TQM this year. Responsibility for this measure lies with a manager who has three departments reporting to him. Each department has a share in the overall measure and all are tracked by graphing absolute measure and its relative change over time.

The targets/means matrix is developed in the first stage of implementation planning. Action items that lead to completion of activities are associated with targets that measure compliance with overall objectives. These matrices should be kept as simple as possible and used by the people involved in the activity. They are self-management tools rather than supervisory tools. the most important factor in their use is development of means that have good correlation with targets. It is much preferred to divide the work and have a large number of simple matrices than to have a small number of unduly complex matrices.

The flag system further serves to keep lower-level tasks aligned with goals. Again, simplicity is a key, with a small number of simple charts tracking very important metrics rather than attempting to track everything measurable. Flag systems that span more than two levels of organization are possible, but the most useful span only two. They should be considered tools for the personal use of a manager, rather than an overall measures of success. The metrics appropriate for all involved to use are those agreed to and called out in the target/means matrix.

Review of project progress in an important factor, and should be planned just as other factors are. the best time to plan for review is before review is necessary; this means review planning is part of overall project planning. The tools for review are very simple, and may involve nothing more than matrices of various kinds and checklists. Review cannot be completely planned, nor should the project be initiated, before the project is completely documented. This documentation is developed as a result of the steps above, and taken together is the project plan. Not all documentation generated is necessary to include in the plan. Items of particular usefulness are operational definitions, deployment charts, PERT/CPM networks and PDPC diagrams, targets/means matrices, and checksheets or other means used to ensure that adequate resources are available. This package comprises the plan, and the measurable components (flag, targets/means matrices, timeliness) comprise elements appropriate for review.

Reviews need to be scheduled and taken seriously. If reviews are held quarterly, it is very easy for an activity to slip by six months before something is done. If monthly, the worst slip should be two months. The review schedule is adopted based on the amount of slip that can be tolerated. In between reviews, project directors can informally audit use of flags and targets/means matrices. Their primary purpose is to help the team members working on activity tasks to keep their focus and measure their progress between scheduled reviews. This is why they should be developed jointly with team members working on the activities, and they should one audited informally to ensure they are used.

Management of even a moderate-sized project is a major task. If a set of activities is large enough to warrant planning the work of several people, it is too large for a single person (the project manager) to keep under control by personal attention. Policy deployment provides tools that can be defined by the team members and used by them to ensure successful activity completion. Their use, in conjunction with early and detailed planning, drastically improves the changes for successful projects.

In a large TQM system

Operational planning fits in very well within a TQM implementation of broader scope. The tools used are typically used in other TQM contexts, and are either familiar to project team members or easily taught by doing. Beyond the project planning context, operational planning is a version of policy deployment. As such, it is the implementation interface between policy and action.

Operational planning, when combined with the trend toward doing many activities in teams, provides a vehicle for training as well as a guide to implementation. In reengineering and continuous improvement efforts, tasks or problems may be defined as projects and attacked as described here, with appropriate modifications to fit the context. (Corrective action teams, for example, may use a well defined problem solving method that could replace the definition and analysis phases. These teams, however, are frequently weak in communicating implementation details, so specification, structure, and implementation phases described here complement the problem-solving activity.)

The use of operationa planning methods itself requires a plan, usually developed at a higher level abd involving priorities for application. Given that the areas for its use have been determined and a team appointed, a team facilitator familiar with these methods is necessary. The team itself should learn the methods by applying them to a problem, ideally a problem that they need or want to solve. As with many other TQM tools, these methods are best taught by doing, on a just-in-time basis.

Operational planning is a blend of East and West, at the working detail end of the spectrum from strategic planning to implementation. A variety of tools, approaches, and methodologies are available for strategic planning brainstorming, and management. Most of these leave implementation to the user, with the result that, if the user is not already accomplished at making detailed and difficult things happen, the tool may appear to fail. More often, the tool worked but implementation failed

The basis for guiding implementation is policy deployment. While this approach has been used with success, it is rarely described in detail. There remain, as well, both the reluctance to use tools that are perceived as foreign, as well as the blind enthusiams to do the same. By placing policy deployment within the broader context of project planning, it is seen to be nothing more than setting up measures of performance or activity that apply at the detailed level and, when complete, ensure that higher level goals are realized. Further, it is a system custom developed by the people who are to use it. As such, it gives people the tools to help their own success, which is another wayy to describe the objective of TQM.

For further reading

Akao, Yoji, Hoshin Kanri: Policy Deployment for Successful TQM, Productivity Press, Cambridge, MA, 1991.

Brassard, Michael, The Memory Jogger Plus, GOAL/QPC, Methuen, MA, 1989.

Deming, W.E., Out of the Crisis, MIT Press, Cambridge, MA, 1989.

Ishikawa, Kaoru, Introduction to Quality Control, 3M Corp., Tokyo, 1990.

Moder, J. J. and Phillips, C. R., Project Management with CPM and PERT, Van Nostrand, New York, 1970.

Neumann, Klaus, Stochastic Project Networks, Sringer-Verlag, New York, 1990.

Pritsker, A.A.B. and Happ W.W., "GERT: Graphical Evaluation and Review Technique, Part I, Fundamentals," Journal of Industrial Engineering, May, 1966.

Scholtes, Peter R., The Team Handbook, Joiner Associates, Madison, WI, 1988.

Tribus, Myron, Deployment Flow Charting, Quality and Productivity Inc., Los Angeles.
COPYRIGHT 1993 Institute of Industrial Engineers, Inc. (IIE)
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 1993 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Title Annotation:project evaluation and review technique; total quality management
Author:Kimbler, D.L.
Publication:Industrial Management
Date:Sep 1, 1993
Words:3013
Previous Article:Financial risk analysis using financial risk simulation program.
Next Article:Economic implications of incorporating job value in dispatching rules.
Topics:


Related Articles
TQM and CPA firms.
TQM to the rescue.
Learn to use TQM as part of everyday work, not as a buzzword.
Meeting the new paradigm challenges through total quality management.
Project management and TQM: why aren't project managers coming on board?
Communication, commitment and corporate culture: the foundation for TQM and reengineering.

Terms of use | Copyright © 2017 Farlex, Inc. | Feedback | For webmasters