Local Government Finance: Capital Facilities Planning and Debt Administration by Alan Walter Steiss
PROJECT PLANNING AND OPERATIONS SCHEDULING
The primary purpose of project planning is to create both a plan and a schedule and to provide mechanism for continuous control over the operations of a program or project. In this context, a plan can be defined as a coordinated model of the sequence in which all activities must be performed to complete a given program or project. Scheduling involve the determination of the calendar dates or times that resources will be utilized in accordance with the total resource capacity assigned to the program. Resource requirements and availability, task or job sequence, and possible starting and ending times for program activities must be taken into account in order to produce a schedule.
Public Sector Applications
Many public programs continue to operate at far less than full efficiency, as evidenced by: (1) missed deadlines--often because they were unrealistic in light of the scope of work; (2) programs that require substantial time extensions because the anticipated results have not been achieved; and (3) the all-too-familiar practice of dropping items from a project schedule in order to meet overall budget constraints. Much of this continued inefficiency can be attributed to a lack of understanding of and/ or confidence in the techniques of project planning and operations scheduling.
The argument that these management techniques, developed in the private sector, are not directly applicable to public programs--particularly nonproduct-oriented, service activities--is fallacious. It may be valid to say that many governmental activities are "process oriented" and therefore, do not result in an "end product" as such. Most public processes, however, have some objective that can be held analogous to a project completion; for example, number of cases processed within a given time period. Further, a range of cost and time constraints can be associated with most governmental activities. Through effective programming, it should be possible for program managers to organize these activities in a more optimal manner. Costs can be more clearly defined and controlled, and time constraints can be utilized more effectively. Firmer assurances can be provided that the work will be completed within anticipated schedule deadlines. Assuming that the management plan is followed, the time saved by minimizing inefficiencies should enable an agency to undertake new and varied activities without appreciably increasing staff size.
Three Fundamental Elements
If a program or project is to be implemented successfully, three diverse and often contradictory elements must be coordinated into a management plan and operations schedule that will permit the program to be completed (or maintained) in the "best" time, at the least cost, and with the smallest degree of risk and uncertainty:
(1) Operations: the things that must be done (tasks, activities, or jobs), each with a sequential relation to other operations and each requiring resources for some time period.
(2) Resources: the things utilized in a program or project, often reduced to a common standard of cost, but including personnel, equipment, materials, and time.
(3) Constraints: conditions imposed by outside factors, such as budgetary limits, completion deadlines, availability of staff resources, inputs from other units, and so forth.
Two basic requirements for the application of project planning techniques are: (1) the ability to clearly state a work program (including the delineation of tasks into specific activities, jobs, or work elements) direct toward one or more defined objectives; and (2) the skill to attach cost and other resource requirements/constraints to each activity in the program. Given this fundamental management information, planning and scheduling techniques have been developed to determine maximum time allotments, as well as costs involved, for each job.
A management plan must be a dynamic tool--it should provide managers with the capacity: (1) to consider the cost, in dollars and time, of pursuing alternative sequences of activities; (2) to establish criteria for the allocation and scheduling of resources; (3) to evaluate the accuracy of cost and resource estimates and to assist in refining these estimates; (4) to identify and assess the consequences of change with the minimum delay; (5) to revise and update the plan with minimum disruption and within an acceptable time period; and (6) to assimilate, communicate, and analyze data concerning the progress of the program. A management plan will have certain practical restraints. Deviations between predicted and actual results, for instance, must be identified quickly so that the necessary action can be taken to correct such situations. Available data, however inaccurate, must be made to produce better results.
The Operations Schedule
An operations schedule must reflect the total resource capacity assigned to the program or project and the availability of resources, the sequence of activities or jobs, the resource requirements, and possible starting times for each activity. The basic requirement in producing an efficient schedule is to level the use of resources, i.e., to avoid dramatic shifts--ebbs and flows--in resource requirements (and particularly in staffing requirements). In developing a schedule, the critical path (i.e., the longest sequence of activities) is determined not so much by the duration of the various activities as by the segment of resources that can (and should) be assigned out of the total resource capacity in order to successfully complete each activity.
It may be possible, for example, to clear and develop a neighborhood park site in five weeks using five workers. It also might be possible to clear and develop the same park site in one week with 25 workers, or in two and a half days with 50 workers, or in four hours with 250 workers. There is an obvious fallacy in this thinking, however. Efficiency drops off rapidly as jamming grows, that is, as more resources are applied to the project. While it may be just as efficient for five workers to take five weeks as it is for ten workers to take two and a half weeks, due to the drop in efficiency, it may require fifty workers one week to do the job instead of two and a half days.
The requirement of scheduling, therefore, is to establish a duration for each activity with varying levels of resources to be utilized so that the schedule will remain within the limits of peak efficiency. This approach to scheduling yield a minimum cost for each activity and presumably, for the total program or project.
Project planning and operations scheduling techniques are excellent tools of communication because they can show graphically the interrelationships among activities in a program or project. They also indicate clearly where responsibilities for supervision and management have been assigned. When changes in the plan or schedule are required, the work program should show clearly which activities will be affected by such changes. This focus, by itself, can relieve program supervisors (e.g., field staff) of much unnecessary paper-work that only serves to keep them from their more valuable function--the continuous oversight of program activities.
Performance Requirements and Decision Criteria
Strategic objectives often reflect the performance requirements or desired "end product" of a program or project. For example, an appropriate end product for a construction project often may be defined in terms of general systems specifications. If a research study is to be initiated, a definition of the area to be examined and the subject matter of the final conclusions or recommendations often will suffice. If a physical activity must be performed, such as a move to a new facility, it may be appro-priate to describe the conditions to be attained and to identify the measures of accomplishment.
Performance requirements may also define any constraints on how the project is to be carried out--such as imposed schedule deadlines and budgetary limitations (see Exhibit 1). Any requirements for doing the work in-house or by subcontract should be stated. Appropriate manage-ment philosophies and strategies to be applied should also be identified. The amount of verification of the project's end-product performance also may be defined.
Exhibit 1. Performance Requirements and Decision Criteria
Decision criteria reflect the relative importance of project performance, development cost, production cost, and ultimate operational costs.
Decision criteria may also be incorporated into strategic objectives. Such criteria should reflect the relative importance of program/project performance, development cost, production cost, and ultimate operational costs. These criteria may be expressed in both quantitative and qualita-tive terms. Eventually, these factors may be translated into more sophisticated decision criteria, such as used in cost-benefit and cost-effectiveness analyses. In this initial stage, however, general decision guidelines will suffice--it is not necessary to be able to forecast every possible contingency.
Once the initial performance requirements have been stated, a sequence of broad tradeoffs must be made. These tradeoffs result in a decision on how much should be spent (cost) for how good an "end-product" (effectiveness). During this process, it may be discovered that assumptions about one part of the project or program tend to place unreasonable requirements on some other component. Assumptions may be changed, perhaps several time, in an effort to achieve an optimal design. Certain features of the project or program may add significantly to the time duration. Activities or even whole tasks may have to be modified in order to conform to schedule deadlines. Schedule risks may be reduced by spending extra money. It may be possible to improve performance by taking advantage of an emerging technology. This decision may increase the cost of the project or program by a few percent. It may be possible to accomplish some project tasks in parallel, while others will have to be undertaken in series. Large enough cost reductions may be possible to offset the additional resource requirements resulting from the overlap.
It may be argued that providing this level of detail will provoke disagreement and cause needless management difficulties. On the contrary, that is all the more reasons to take these actions. Any basic disagreement about the goals and objectives of the project should be exposed early and not left to give rise to inevitable misunderstandings and trouble later.
After end-products and performance requirements have been ident-ified and appropriate trade-offs have been made, the required tasks can be organized into some consistent format and the process of further defining tasks, subtasks, and activities can begin. Schedules and budgets can be prepared. Alternative approaches should be compared with performance requirements and the best ones selected as the basis for decision-making.
Finally there are interactions between the establishment of program objectives, on the one hand, and the planning of the project on the other. It may be that the desired end product simply cannot be achieved within the specified time frame or for the planned costs. Thus, it may be neces-sary to relax certain performance requirements to permit a more realistic set of management and operational plans. Or perhaps the appropriate decision would be to terminate the project/program immediately, rather than after a large expenditure is made in pursuing unattainable goals.
Task Identification
Operational objectives involve the delineation of specific tasks that must be effectively carried if the management and strategic objectives are to be accomplished. Obviously, if the proper tasks have not been identified at the outset, efforts to plan, schedule, and control them and to ensure that they comply with established standards will be in vain.
A task can be defined as a set of activities that will lead to the achievement of some desired results in a program or project. Tasks are the major divisions of the work on a program/project. It is extremely important to have broad participation in the identification of tasks relevant to a particular program or project. Task identification is far too important an undertaking to be left to a program planner or even to individual program managers. The active participation of all segments of the program staff is essential in order to increase the probability that all essential tasks will be identified.
Three major approaches can be used in identifying program tasks: (1) a deductive approach, (2) an inductive approach, and (3) a composite approach. Under the deductive approach, tasks are defined more or less intuitively from a description of the expected operations of the program. That is, an attempt is made to develop a picture of the required results of the program activities and to reconstruct the logical sequence back to the required tasks. In this way, the logic between each task and the preceding activities is clearly identified. This approach sometimes is referred to as back-chaining, since the analysis works back through a chain of events, linking the original inputs to the desired program. Experience has shown that this approach tends to identify only tasks that are really essential.
The inductive approach works almost in reverse of the deductive method. It begins with a detailed documentation of each task, including the anticipated results of each task. After this examination is finished, the tasks are sorted into logical groups, where the anticipated results of performing each grouping are discussed and recorded.
The composite approach is a combination of the deductive and inductive approaches. An attempt is made to examine the "big picture," while at the same time a group of identified tasks and their anticipated results are also analyzed. Using this approach, the analysts seek to determine how the present tasks should be modified to accommodate the newly stated program. In effect, the "knowns" of existing tasks are modified and rearranged in order to produce the desired results of a new program configuration.
The inductive and composite approach work best when prior program experience has been recorded, and the new program is an attempt to expand and improve upon these efforts. If the activities involved are completely innovative--without prior application--then the deductive approach may be the only route possible for task identification.
An example might help to illustrate these points. A local Health Department has established the following strategic objective:
To reduce the incidence and prevalence of disease and/or conditions declared to be communicable and/or dangerous to the general public by providing surveillance and epidemiological services.
A management objective that supports this strategic objective would be:
To increase public awareness of the need for early detection of cervical cancer through public health outreach workers and educational materials.
A related management objective which included measurable performance criteria would be:
To provide during the current fiscal year approximately 140,000 pap smears for women who are not currently receiving this service.
Operational objectives would include:
Schedule five pap test clinics in the evening hours in the neighborhood health centers and assign personnel to staff these clinics.
Work in cooperation with the county health department and specified health care providers to disseminate information about the need for early detection and the availability of these clinics.
A number of specific tasks must be undertaken to achieve these objectives, as shown in Exhibit 2. In analyzing the feasibility of implementing this program, some potential obstacles may be identified. Implementation strategies for this project must describe those activities that would respond to both sets of necessary actions--the management and operational objectives and the potential obstacles.
Exhibit 2. Task Identification and Implementation Feasibility Analysis
(5) Legal implications of the program and referral requirements must be determined.
Brainstorming, Opportunity Analysis, and the Delphi Technique
Organized brainstorming sessions often can be useful in identifying tasks and activities appropriate to a given project (see Exhibit 3). Such sessions should be fairly unstructured, freewheeling, and unconstrained. All ideas should be recorded no matter how "far-out" they may seem at first. All project staff should be involved in these sessions.
Exhibit 3. Brainstorming the Establishment of a Pre-natal Health Care Clinic
These activities are not listed in any particular order. Often in such brainstorming sessions, ideas will flow in a somewhat unstructured fashion. This approach should be encouraged to ensure that all ideas get out on the table.
It may be desirable for the program manager to maintain a relatively low profile in these sessions. A member of the project team can be appointed to serve as the session leader, so that the opinions of the manager will not overly bias the discussion or lead to premature closure. In this way, the manager can adopted the "observer's role" and not unduly influence the flow of ideas by his or her responses. This approach also tends to increase the involvement of those project personnel who are selected to serve in the facilitator's role. Efforts to refine, combine, and assign priorities to the ideas generated in the brainstorming sessions should follow only after the project has been thoroughly discussed and all participants have had an opportunity to express themselves.
Along similar lines, an opportunity analysis may be conducted to raise the enthusiasm and morale of those involved. Periodic sessions are held to discuss the current status of the project/program and to explore opportunities that may be presented. Many of the ideas generated in such sessions may not be relevant to the more pressing requirements of the project. However, an effective program manager cannot afford to overlook any possibilities in a preoccupation with status quo procedures. Such an exercise should help develop more positive attitudes among the staff.
Ideas about project activities also can be elicited and refined through the use of the Delphi technique. The relatively free exchange of brainstorming is replaced by a more formal exchange of information under the control of a steering group or exercise manager. This technique involves an iterative series of interrogations (usually through the use of questionnaires) of a panel of knowledgeable individuals. Responses are not matched with respondents, and the participants often are not revealed to one another until the end of the exercise. In this way, the psychological drawbacks of face-to-face confrontations are avoided as participants review one another's opinions.
After each round, the information generated in the previous stages is fed back to the participants so they may use it to revise their earlier responses (an often, to modify their attitudes concerning the project). Irrelevant or redundant materials may be eliminated to assist in sharpening the focus in subsequent iterations. Participant opinions tend to converge with feedback, although after several iterations, a spread of opinions is still a normal outcome.
Rather than forcing unanimity, a statistical index is used to represent the group response. The assumption is that, in this way, the pressure of conformity are reduced, and the opinion of every participant will play a role in the final determination of categorical responses.
The preceding discussion implies a linear progression from defining end products, to examining performance requirements, to identifying the specific activities of the project or program. The logic of such a process is sound. However, seldom is it possible to follow this process in a straight-forward manner. Many "loops" are made during project planning. Some are relatively small, but some may require major changes in the whole concept of the project or program.
An active set of decision loops--even loops within loops--produce increasingly better management plans. It is important, however, to bring the planning process to a conclusion so that implementation can begin--before funds are wasted on superfluous refinements and unnecessarily detailed restrictions are placed on doing the job itself. Project planning should provide a basis for project direction and a blueprint for program implementation. Typical products of this process include: (a) project specification; (b) Work Breakdown Schedules; (c) identification of project tasks and activities; (d) functional project plans related to organizational responsibilities; (e) activity networks; (f) operations schedules; (g) cost estimates and budgets.
Work Breakdown Schedule
As has been noted, the first step in formulating a management plan is to establish the major objectives to be accomplished and each of the supporting objectives for the entire project or program. These objectives must be linked together so that the manager can see the project in its true perspective--so that the relationships are clear between and among all of the procedural steps. A work breakdown schedule (WBS) is one important technique for developing a preliminary outline or "schematic" of the way in which supporting objectives mesh together to ensure the attainment of the major objectives. Work breakdown schedules have been used success-fully in the private sector for a number of years. Most of us learned the fundamentals of this technique, albeit under a different name, when we were struggling with English composition in junior high school.
Divide and Conquer
In simple projects, the major management objectives and the supporting operational objectives may be so obvious that complicated listings or other arrays of information are not required. In more complex project, hundreds of individual activities and events may be required and their linkages may not be easily recognized and related. In such projects, the work breakdown schedule aids in the identification of objectives, allowing the manager to examine groves of trees within the forest if not the individual trees.
The basic idea of a work breakdown schedule is to divide the total project into major tasks, then to subdivided these tasks into subtasks, the subtasks into activities, and so on. The work may be subdivided through as many stages or levels as necessary to provide final work units of the desired size. At the lowest level, the work units should be small enough to permit adequate visibility and control without creating an unwieldy administrative burden.
It is not possible to state precisely just how detailed the work breakdown schedule should be or exactly how many levels are needed for any given project. It should be detailed enough to allow the eventual formulation of an operations schedule that will accurately reflect the interrelationships among all the events and activities which make up the entire project or program. Each part of the WBS should be subdivided to the number of levels useful for managing the project. Excessive zeal in pushing the WBS into too many subdivisions, however, may well result in an unproductive management structure. It is not necessary to extend the WBS to the same number of levels for all tasks. Insistence on a uniform number of subdivisions may yield final units that are too small in some cases and too large in others. Tasks should be subdivided into smaller units according to their interrelatedness. Routine, repetitive work need not be excessively subdivided.
Since a good WBS is designed to serve many project purposes, it is not necessary to manage all project activities at the same level of detail. The structure of the WBS should be flexible enough that it can be expanded over time--in both depth and scope. The WBS need not be expanded initially to the desired depth in all areas. In fact, an early version of the WBS--containing only two or three levels of task subdivision--may provide a sufficiently sound basis for project planning. As the time approaches for initiating certain parts of the project, tasks can be further subdivided into additional levels as may be appropriate for cost and schedule control. Thus, managers with different responsibilities can look at large or small segments of the project presented in varying degrees of detail.
The initial division of work should not be made along organizational lines--this nullifies much of the usefulness of the WBS. Any schedule below the first level will only reflect what is required by the separate organizational units and will not reflect the dependencies or obligations among these units. Dividing tasks according to organizational respon-sibilities, therefore, should be deferred to a low level within the WBS.
A work breakdown schedule can be used for a variety of purposes in addition to describing the tasks necessary to realize the management and operational objectives of a project or program. A WBS can be used as a common framework for: budgeting and control of project costs; issuing work authorizations; scheduling work; reporting and monitoring the status of work activities; and tracking technical performance. In essence, a WBS can provide managers with an important tool for the integration of planning and control functions at various levels of responsibility and authority within an organization. It also serves as an important mechanism for the communication of project management information.
The WBS Format
One of the characteristics of a good manager is consistent, orderly, but flexible thinking. Therefore, a WBS should be structured in a con-sistent manner, according to some orderly identification scheme that will also provide the flexibility for expansion, if necessary, during the time required to complete the project. Such a structural approach is provided through the so-called indented decimal system. (see Exhibit 4).
Exhibit 4. A Work Breakdown Schedule for Pre-natal Health Care Clinic
3.3 Screen initial applicants for eligibility and complete their enrollment in the program
The straightforward application of this system is relatively simple and provides a readily understood mnemonic. The decimal format makes it easy to build the WBS into a management information system and to develop managerial accounting procedures that is useful to the project manager. For example, accounting codes can easily be expanded to include the numerics of a project's work breakdown schedule so that the project manager can monitor costs at various levels of activity.
The first subdivision (1.0, 2.0, 3.0, and so on) represents the major tasks of the project associated with the major management objectives. The second level (1.1, 1.2, 2.1, 2.2, etc.) represents the further breakdown of major tasks into subtasks. The third level (1.1.1, 1.1.2, 1.1.3, etc.) begins to identify specific activity clusters or job assignments that are required to successfully carry out the subtasks.
The work specified in each division is logically the sum of all the work described in the elements contained in that division or its subdivisions. Subtasks and activities are the logical divisions of larger tasks and should be distinct from each other. For this reason, each entry in the WBS should have its own, unique descriptive title which provides the manager and others with a brief identification of that work unit so that it is distinguishable from other work units. These descriptive labels need not be long and complicated. In no case, however, should the title of one level repeat words used in the subdivision. The numerical designation provides the traceability to larger groupings of work units at higher levels. The principal idea is to give the work units usable, understandable names.
It should be evident that no task should be "divided" into a single subtask, and no subtask should be "subdivided" into a single activity. Just as Ms. Finch, our eighth grade English teacher, used to drill into our heads, if there is a 1.1.1, there must be a 1.1.2. This admonition seems obvious; and yet, failure to adhere to this basic rule accounts for many shortcomings in the application of the WBS approach. It is also important to maintain the integrity of the task hierarchy--to guard against the misplacement of activities under an inappropriate subtask or to repeat the same activity under more than one subtask.
A graphic display similar in layout to that of a decision tree or an organization chart is also a highly effective way to represent a work breakdown schedule. Major objectives and associated tasks are indicated at the top of the chart, with the second level containing supporting objectives/subtasks, the third level indicating some of the more detailed work required to complete these second level supporting objectives, and so forth. Such a schematic diagram can be displayed on a wall to provide staff members with a total view of the project and the interrelatedness of various project activities. Typically, each box on the chart contains a task identifier and the name of the task or activity.
With the addition of narrative descriptions of each of the major tasks and subtasks, a WBS can serve as a more detailed management plan. Individuals with various functional responsibilities in the organization should be able to refer the WBS as a common source of information for the fulfillment of their planning and control responsibilities. Since there is no need to provide the same level of subtask division for each task, flexibility of the schedule can be maintained. This is especially important in the early developmental stages of a project. In fact, the WBS can be sent out to various personnel with the work only divided into major tasks. As the planning of the project is further refined, the major tasks can be subdivided. By issuing a "first draft" of a WBS, the project manager also allows for the fuller participation of affected personnel. Such a process may result in a better WBS and a more successful project. At a minimum, however, such a process allows relevant personnel to participate in the development of the operations schedule and the monitoring and control devices that will be applied to the project. By providing for such participation, greater cooperation and understanding of the project may be anticipated, as well as a greater potential for realizing a successful project.
Summary
The following characteristics should be kept in mind In developing a work breakdown schedule:
(1) The WBS should be structured in a consistent, orderly, and hierarchical manner.
(2) The work specified in each WBS element is the sum of all the work specified in the elements immediately below it. When a work element (task or subtask) is subdivided, all the work in that element is assigned to one of the immediately subordinate units.
(3) No work should be described in more than one element at a specific level of subdivision.
(4) The WBS should be detailed to the extent necessary to provide a useful basis for managing the project; the subdivision of these should be based on interrelatedness.
(5) The level of detail need not be the same for all tasks. The subdivision of tasks should permit, if appropriate, the development of a network or other scheduling techniques.
(6) Extensive subdivision of routine, repetitious work should be avoided. Subdivision of tasks/subtasks should not be extended to relatively small cost efforts. Breaking down tasks according to organizational responsibilities should be avoided except at the lowest levels.
(7) To maintain clarity and promote a common understanding, it is usually desirable to provide a supporting verbal description of the work in each WBS element. These descriptions should be concise and jargon-free, so that they are understandable within and outside the organization. Redundancy should be eliminated in the various subdivision descriptions.
(8) Properly done, a WBS can be used as a basis for preparing unit cost work statements, work authorizations, project schedules, progress reports, and technical performance evaluations.