IN THIS CHPATER, YOU WILL LEARN:

16.1 INTRODUCTION

Though this is not a book on project management, it is appropriate to pause here, in this last chapter on modeling tools, to present some modeling tools that are useful for managing a systems development project; we will focus primarily on modeling tools known as PERT charts and Gantt charts.

Why should you be concerned with management modeling tools? There are several possible reasons:

In the rest of this chapter, we will examine the most commonly used management modeling tools and see how they address the major issues faced by project managers. We will also see how the project management tools are related to the other system modeling tools discussed in the last several chapters.

16.2 WHY DOES MANAGEMENT NEED MODELS?

There are three primary reasons why project management needs models associated with a systems development project:

Budget and estimates are, of course, a major activity of managers in any project; they are all the more difficult in many systems development projects because each project is (or at least seems to be) unique. Appendix B discusses a number of formulas and methods for estimating the amount of work to be done on a project, and the number of people that will be required. However, management still needs models — and graphical models are desirable, for the same reasons that graphical models are useful in other aspects of systems analysis — to see when the people are available to carry out tasks in the project, what will happen if those people are not available, and so forth. We will examine this in more detail in Section 16.5

Even the best plan, though, is likely to fail if it is implemented blindly. Circumstances change continuously during the project: critical resources may not be available at exactly the time they are needed; important staff members may get sick or may leave the project; the original estimate of the amount of work to be done may turn out to be inaccurate; the user may suddenly announce that he needs the system to be operational a month earlier than originally anticipated; the manager may see that the work is being done more slowly than originally expected. Thus, it is important for the project manager to have models that can let her or him explore the consequences of changes in the plan.

And finally, the project manager must not only manage tasks, he or she must manage people. The manager must ensure that all the systems analysts, programmers, systems designers, and other personnel are doing what they should be doing, when they should be doing it. Thus, the manager needs modeling tools that will focus on the people, in addition to modeling tools that focus on the tasks

16.3 PERT CHARTS

PERT is an acronym that stands for Program Evaluation Review Technique. It was originally developed in the 1960s as a management tool for the U.S. Navy’s Polaris submarine project; Booz Allen (the consulting firm), Lockheed Aircraft, and the Navy are generally credited with developing the concept. PERT charts have been used widely in industry and government projects since then; many people now refer to them as activity diagrams.

Figure 16.1 shows a typical PERT chart for a hypothetical project. Each rectangular box represents a task or an activity (i.e., a recognizable chunk of work that needs to be done). The boxes with rounded corners are known as milestones, and they have an obvious meaning within the context of a typical project. The lines connecting the boxes show dependencies; that is, they show which activities must be finished prior to the commencement of some other activity. The heaviest, dark lines that form a contiguous path from the beginning to the end of the project represent the critical path, those activities whose delay would force a delay in the overall project (activities not on the critical path have “slack time” available; they can be started later than the scheduled date up to the amount of slack time available, if desirable, without affecting the overall project).

Note that it is the project manager (or a subordinate) who determines which tasks are dependent on which other tasks. In many cases, the dependency is data related: activity N + 1 requires, as its input, something that is produced as an output by activity N. In other cases, the dependency represents a checkpoint in the project (e.g., milestone N might be a management review meeting that must approve the work that has been done up to this point, before activity N + 1 is allowed to begin).

Note that that the example of Figure 16.1 is truly a trivial one: it contains only ten activities and ends when the systems analysis activity has been finished. A typical project, of course, continues on after the systems analysis work has been done and spends a considerable amount of time in the area of design, coding, testing, and so on. Indeed, a typical project is likely to have several hundred activities that would be shown on a PERT chart. This may fit on the wall of the project manager's office, but it certainly would not fit conveniently in this book!

Figure 16.1: A PERT chart

More importantly, most projects identify major activities, which are then broken into smaller ones. For example, Figure 16.1 shows an activity labeled “Conduct systems analysis activities.” As we have seen throughout this book, there are many, many things that fall under the heading of “conducting” systems analysis; indeed, we might expect to see a large PERT chart that elaborates on those subactivities. Thus, just as we saw the concept of leveled dataflow diagrams in Chapter 9, we could imagine the concept of leveled PERT charts to help organize the complexity of many hundreds, or even thousands, of tasks in a large project.

Note, by the way, that the PERT chart focuses on the activities and interdependencies between activities, but it says little or nothing about many other aspects of a project that are of interest to a manager. It does not indicate, for example, which person or group of people is supposed to carry out the various activities; nor does it say anything explicitly about the length of time (or number of person-days) that each activity requires. And it does not show what products or outputs are produced by each activity. Some of this information, however, is highlighted in the other management models discussed next.

Finally, note that the PERT chart appears to make the assumption that everything moves in a forward direction, as indicated by the left-to-right sequence of the activities. In fact, it is often necessary to cycle back and redo some of the earlier activities if problems are found at a later stage. This kind of iterative activity is not shown well on a typical PERT chart.

On the other hand, the PERT chart does show, quite vividly, the fact that many activities can take place in parallel in a real-world project. This is important, because many of the other project models strongly imply that activities must take place in sequence (see, for example, Figure 5.1). Project managers generally want to take advantage of as much “parallelism” as possible, since it can help reduce the calendar time required for the project.

16.4 GANTT CHARTS

A second kind of project management model is the Gantt chart, sometimes known as a task timeline. Figure 16.2 shows a Gantt chart for the same hypothetical project used in Figure 16.1. Note that each activity is shown, with an indication of when it begins and when it ends; the shaded area indicates slack time, while those activities in white rectangles are critical path activities.

Figure 16.2: A Gantt Chart

As you can see, the Gantt chart presents much the same kind of information as the PERT chart; its primary different is the fact that it shows the duration of each activity [2], which the PERT chart does not. Because it is somewhat more of a tabular representation of the project, it can often be used to present a large amount of information in a relatively compact form.

16.5 ADDITIONAL MANAGEMENT MODELING TOOLS

In addition to the two primary modeling tools discussed above, project managers often like to use additional charts and tables to help them keep track of their work. For example, instead of showing the tasks as we did in Figure 16.2, we could easily produce a chart showing the activity of each resource in the project [3]. Figure 16.3 shows a resource listing for the same hypothetical project; obviously, this would be useful for keeping track of the various activities that each project member is responsible for. Similarly, we may decide that it would be convenient to have a tabular listing of the various activities in the project, perhaps with an indication of the earliest date that each activity can begin and the latest date that it could begin without disrupting other tasks and delaying the final completion of the project.

It should be evident that the information in Figure 16.4 is yet another view of the management aspects of the project; it should be compatible with the other views, just as the various DFD, ERD, and STD models of an information system are compatible with each other. Indeed, having created any one of the project management models, we should be able to derive the others in a mechanical fashion; we will return to this point in Section 16.7.

16.6 RELATIONSHIP BETWEEN PROJECT MANAGEMENT AND OTHER SYSTEM MODELING TOOLS

What is the relationship between PERT charts, Gantt charts, and the various system models (DFDs, ERDs, STDs, etc.) that we have discussed throughout this book? The strongest relationship seems to exist between the PERT chart and the dataflow diagram: both show activities (or functions) being carried out, and both show something about the interaction between those functions. However, the DFD shows absolutely nothing about the sequence in which functions are carried out, while the PERT chart does indeed show which activities can take place concurrently and which must take place in a sequential fashion. Also, we saw that the PERT chart does not show the output produced by each activity, nor does it indicate the inputs required by each activity.

As we saw in Chapter 5, DFDs can be used to show activities in a project, as well as inputs and outputs; hence, it could conceivably be used as a modeling tool in place of the PERT chart. However, most project managers would want the diagram to be annotated to show the critical path; and they would need additional information, such as the duration of each activity and the people working on each activity. Hence, it is more common to see the combination of the classical PERT chart, together with the Gantt chart and the resource timeline that we discussed earlier.

Figure 16.3: A resource listing

More significant is the fact that the activities shown in the typical PERT chart will be the various activities of drawing DFDs, ERDs, and so on. Thus, while Figure 16.1 showed a high-level activity of “conduct systems analysis,” a realistic PERT chart would probably show a list of activities like these:

Figure 16.4: A task listing

As we will see in Part IV, the modeling tools of dataflow diagrams and the like are used to build a series of different models of the new system. Thus, we are likely to find the following high-level activities:

At this point, none of these terms will make much sense to you; we will discuss the environmental model in Chapter 18, the behavioral model in Chapters 19 and 20, and the user implementation model in Chapter 21.

The major point to keep in mind is that the activities that we show in the PERT chart and Gantt charts correspond to the model-building activities that we have discussed throughout this book. Of course, a real PERT chart for a project, encompassing the entire life cycle, must also show the activities of design, programming, testing, database conversion, and installation.

16.7 THE ISSUE OF AUTOMATION

Three things should now be evident from the brief discussion of project management tools in this chapter:

This leads to a very obvious conclusion: it would be tremendously helpful if the project management modeling tools could be computerized. And indeed they have been; there are now a variety of project management packages available on personal computers, as well as on mini and mainframe computers [4]. Indeed, a project manager in the late 1980s would be foolish to manage anything other than a truly trivial project without such automated tools. In addition to the simple modeling activities discussed in this chapter, the computerized tools generally have the following features:

For small- or medium-sized projects, a PC-based project management package is usually quite adequate; among the more popular project management packages for the PC are Microsoft Project, ABT’s Project Workbench, CA SuperProject, and Digital Tools’ AutoPlan II. For large projects with thousands of tasks and hundreds of resources to manage, a larger computer may be required. Also, many large organizations integrate the plans of individual projects into aggregate models and budgets; so it is important that everyone use a compatible PC-based modeling system or that they share a larger, mainframe-based system.

16.8 SUMMARY

Obviously, there is more to project management than just drawing PERT charts. The typical project manager is involved in hiring and firing, in negotiating, motivating, communicating with, and cajoling programmers, systems analysts, users, and higher levels of management. But without modeling tools of the nature described in this chapter, it is almost impossible for the project manager to keep track of the activities, costs, and resources involved.

REFERENCES

QUESTIONS AND EXERCISES

FOOTNOTES