Once we have decided on the type of data we want to monitor, the next question is how to collect these data and turn them into information useful for controlling the project.
This is the activity of data collection and reporting. In this section we cover the physical collection of data and the analysis of that data, if necessary, to transform them into infor- mation. Once transformed, however, there are many ways to present the information and these are covered under the topic of reporting, including a discussion of the three main types of reports. A very special means of both collecting and disseminating data, and even sometimes information, is the proverbial “meeting,” and we offer some advice for this often painful phenomenon—both in-person and virtual meetings are included.
The use of electronic means for distributing information or reports is briefly examined.
At some point we have to decide what data we need to collect and precisely how to go about collecting them. A number of questions are raised. Should we design and use special forms? Should data be collected just before or after an important milestone?
Should time and cost data always be collected at the same time each month? There are many such issues that arise when considering the data collection process and most of them can only be answered in the context of a specific project. There are a few general- izations that can be made concerning the information needed to control projects; these are described in the next section.
Data Collecting
The majority of data to be collected will eventually exist in one of the following five formats.
1. Frequency counts A simple tally of the occurrence of an event is common—for example, days without an accident. Often a count of events per time period or as a fraction of some standard number is used, such as complaints per month, defects per thousand products, and fraction of luggage lost.
2. Raw numbers Actual amounts are used, usually in comparison to some expected or planned amount, such as dollars spent, hours required, and pounds consumed.
The comparison to plan may take the form of variances, that is, differences between planned and actual, or ratios of one to the other. The ratio format is particularly ap- pealing for reporting on a control chart with predetermined limits, as is described later in the chapter. When collecting raw amounts it is important that the basis, time period, and collection process always be the same.
3. Subjective numeric ratings These are usually subjective estimates of some quality offered by specialists in the topic, such as ordinal “rankings” of performance. They can be reported in the same ways as raw numbers, but they often cannot be mathe- matically processed in the same ways raw numbers can.
4. Indicators and surrogates When it is especially difficult to find a direct measure of a variable, indicators or surrogates are frequently used instead. If this approach is taken, it is important that the indicator or surrogate be as directly related to the vari- able as possible. For example, body temperature is an indicator of infection and years of experience can be a surrogate for expertise. The number of salespersons, however, would be a poor, and clearly indirect, measure for level of customer service.
5. Verbal characterizations Other variables that are difficult to measure, such as team spirit or client–supplier cooperation, may take the form of verbal characteriza- tions. These forms of data are acceptable and useful as long as the terminology is limited and is uniformly understood by all parties.
Data Analysis
Following the collection of the data through the monitoring system, it is frequently necessary to analyze or process the data in some manner before reporting it for control purposes. This may take the form of simple aggregation of the data, such as averaging the values, or something as complex as fitting statistical distribution functions to the data to ascertain relationships, effects, and trends. Crystal Ballcan do this with ease.
Some of the quality management techniques for the presentation and analysis of data are often useful here [e.g., see Meredith and Shafer, 2007]. As an example, a common graph used in quality management shows the range of sample values taken on a periodic basis, such as daily. If the samples’ range—the largest minus the smallest value—appears to be increasing over time, this may indicate that a machine is wearing out or needs maintenance.
Figures 7-2 and 7-3 illustrate curve fitting where charts are updated on a regular basis and curves are fit to the data in order to help the PM estimate the cost and time required to achieve the performance goals for the project. Figure 7-4 shows the trend in the ratio of actual material cost to planned cost so the PM can step in should the values indicate a likely problem.
In general, significant differences from plan should be highlighted or “flagged” in some way so the PM or other person exercising control cannot overlook the potential problem. The many techniques of statistical quality control [see Meredith and Shafer, 2007, Ch. 4] are helpful for determining what size variances are “significant,” and may even help in determining causes and effects. These formal approaches, however, are often “after the fact” techniques for correcting (controlling) problems—variances occur, are reported, investigated, and then some action is taken. The astute PM, how- ever, is much more interested in preventingfires rather than putting them out, thus the value of timely data collection and reporting.
Figure 7-2 Number of bugs per unit of test time during test of Datamix software program.
Figure 7-3 Percent of speci- fied performance met during successive repeated trials.
7.2 DATA COLLECTION AND REPORTING • 243
Last, it should be noted that data analysis is sometimes used for the assignment of blame. The PM will not find this a helpful endeavor in managing the project. The goal is to achieve the project objectives through correcting deviations from plan, not to find scapegoats or assign guilt. The PM needs all team members performing at the top of their capabilities. Frequent blame placing strongly encourages team members to avoid taking the risks necessary to achieve a project’s goals.
Reporting and Report Types
After the data have been collected and analyzed, they need to be reported in some form. For example, PMBOK suggests in Chapter 10 that routine performance reports in- clude status reports, progress reports, and forecasts. There are also many other possible report formats, such as time/cost reports, variance reports, update presentations, and similar documents. All tables, charts (such as PERT/CPM and Gantt), and especially action plans should be updated to reflect current reality. In addition to alerting team members to potential problems, such updates help maintain team morale. Where known, some form of “comparables” should also be reported such as distributions of pre- vious data, perhaps from earlier but similar projects, so that the PM and others can bet- ter interpret the data. As we have noted before, any time project reports, plans, or other documents are updated, great care should be taken to preserve all documents from ear- lier stages of the project’s life. These materials will be invaluable when the project is completed, and a project final report (project history) is written.
Although everyone concerned with the project should be tied into the reporting system in some fashion, not everyone needs to receive the same information. In addi- tion to, say, aggregating the data for senior managers with many other such projects under their authority, reports may vary in terms of the frequency of distribution and detail as well as the particular measures being reported. The client may wish to have reports on cost or schedule while functional management may wish to see reports on technical performance, for example. Project team members may need information at the task or subtask level on a frequent, perhaps daily, basis.
In general, it is a good idea to avoid periodicreports except in those cases in which the flow of data is periodic, for example, accounting data. Let the project’s milestones, scope changes, problems, and the project team’s needs for information dictate the timing of reports. It is our feeling that reports issued routinely every day, week, month, or quar- ter do not get read. An exception to this rule against periodic reporting is made for re- ports mandated by senior management who must examine the status of many projects and may need to compare the performance of many projects against the same time frame.
The explosion of electronic media for both collecting and disseminating data and information, including project management software such as MSP, makes it possible to customize a wide range of information for different audiences. This means that more Figure 7-4 Ratio of actual material cost to estimated material cost for aircraft parts company.
data are available for collection, and more frequent updating is possible. Clearly, this can lead to an overload of reporting that is just as dangerous as underreporting. Impor- tant events, problems, and trends tend to be hidden in a mountain of detail. Thus, it is crucial that the reporting system be well designed to make use of such modern techno- logical marvels without abusing the recipient of their capabilities. More is said about this later in this section.
The reports delivered to those engaged in carrying out or managing the project should be timed to allow control to be exercised before completion of the task in ques- tion. The project action plan, again, identifies the level of tasks and responsibilities ac- cording to the level of management, and this provides guidance for both the level of detail and the timing of reports. For example, drug efficacy tests require a long time to conduct so frequent reports would not be appropriate. In contrast, performance verifica- tion tests on new silicone chips can result in hundreds of discrepancies within a matter of hours, so daily or even more frequent reports are necessary.
In addition to WBS-determined data and information, individual managers may wish to see specific types of information in their reports and these should be included as well. Moreover, they may even have preferences on the timing of reports, which should also be followed when they are within reason. The PM, however, must make sure that the relevant (for their level) information about project progress is included in their re- ports, and in such a way that it cannot be overlooked. Similarly, it is of no value report- ing information or data to those who cannot use it for purposes of control, such as reporting overhead costs to the project chemist.
For projects, there are primarily three distinct types of reports: routine (which we have been describing), exception, and special analysis.
• Exception reports are primarily intended for special decisions or unexpected sit- uations in which affected team members and outside managers need to be made aware of a change, and the change itself needs to be documented.
• Special analysis reports are prepared to disseminate the results of a special study in a project concerning a particular opportunity or problem for the project. They may be distributed to top management, other project managers who would bene- fit from the knowledge, functional managers, or anyone who might be affected or interested. Typical subjects might include studies of new materials, capabilities of new software, and descriptions of the impact of new government regulations.
In addition to the benefits of reports for the purposes of control, they offer these benefits.
• They provide the mutual understanding between stakeholders in a project re- garding the goals, progress, difficulties, successes, and other ongoing events of importance to the project.
• They help communicate the need for coordination among those working on the tasks and subtasks of the project.
• They establish and maintain a communication network for global projects.
• There are often changes to the goals and functioning of projects. Reports can communicate this information in a timely and appropriate fashion, thus mini- mizing the confusion often encountered during such changes.
• They help maintain the visibility of the project, and the project team, to top management, functional managers, colleagues, and clients.
• Finally, unless the project is a disaster, status reports help keep the project team motivated.
7.2 DATA COLLECTION AND REPORTING • 245 A special problem often encountered in designing project monitoring and reporting systems is the relationship between the project’s information system and the overall or- ganization’s information system. The PM is, understandably, not free to define costs and other measures in ways that differ from the organization’s definition of such measures as documented in the overall information system. Thus, the PM is advised to use the regu- lar information system as the definitional prototype for project monitoring and report- ing, making adjustments and additions as necessary for the special circumstances and measures needed for the project at hand. The PM should be aware, however, of another danger—modules of the parent organization’s information system may not fit the needs of project monitoring and reporting. For example, an accounting module to track costs for an assembly line will not be adequate for tracking project costs.
Software packages such as MSP offer extensive and varied reporting mechanisms.
Gantt charts show the current status of a project (see Chapter 5, Figure 5-26), and re- ports show the availability of various resources (see Chapter 6, Table 6-4) or the de- mands for work from individuals or groups (see Table 6-5 or Figure 6-12), just to name a few. MSP not only allows the PM to distribute the information anywhere that has elec- tronic communication capability, but also allows easy customization of the reports lim- ited only by the PM’s imagination. A PM can highlight tasks that are running late (or running early if such exist), and add large red Xs to mark cost overages. The level of de- tail reported on Gantt charts is also completely controllable, so the PM can send only first-level tasks to senior management, and the highest level of detail to project team members.
Meetings
For many project workers and managers, meetings are about as welcome as Herpes dis- eases or a call from the IRS. So far in our discussion, we have talked about reports as if they were going to be delivered by hand, snail mail, or e-mail. Often, however, they (or their substance) are delivered through face-to-face meetings. These meetings can range from regular, highly formalized and structured presentation/question/answer sessions to informal, off-the-cuff get-togethers. Project review meetings, regardless of the format, are always important.
Although such meetings are usually dreaded because of their length, lack of action- able conclusions, and general waste of time, this need not be the case. The following guidelines should help avoid the problems with such meetings.
• Some meetings, such as the Weekly Progress Report (also known as “show and tell”), should rarely be held at all. Although not always possible, try to hold meetings only for making group decisions or generating input among meeting members for dealing with important problems or opportunities. That is, hold meetings to take advantage of face-to-face interaction when no other approach or technology is an adequate substitute.
• Distribute a written agenda in advance of the meetings. The lead time for dis- tributing the agenda should be sufficient to allow attendees to prepare to deal with agenda items. In addition to a list of the issues that will come before the group, the agenda should announce the meeting’s pre-set starting and stopping times. Stick with both. Don’t wander off the agenda, don’t let the meeting run into overtime, and especially do not penalize those who show up on time by making them wait for those who are late. Obviously, in the case of meetings called to deal with emergencies, feel free to disregard the advice in this section.
If a crisis arises and a meeting is deemed necessary to deal with it, make sure the
meeting is restricted to that issue. If a stopping time cannot be predetermined, an acceptable alternative is “when the crisis is resolved.”
• If homework needs to be done before the meeting by the attendees, check to be sure they will be prepared, and above all make sure you are prepared.
• If you chair the meeting, you should take your own minutes. The minutes should contain a final set of action items including what is to be done, by whom, and by when. The minutes are a critically important piece of documentation for a project, documenting important decisions and responsibilities. Do not dele- gate this responsibility. Microsoft Wordhas a template for creating an agenda and for taking minutes that focus on action items.
• Avoid attributing remarks to individuals in the minutes. Remarks are meant to foster group process, not to be documented for eternity and for all to see. (Obvi- ously this doesn’t apply to designated or volunteered responsibilities.) As well, do not record and report votes taken in the meeting. It seems inappropriate to report that the motion to send a get-well card to the boss was passed—four yea and three nay. When the group has made a decision, by whatever means, that decision becomes the unanimous position of the group. Disagreement and de- bate are appropriate during the meeting, not after the decision is made.
• Although courtesy is always in order, excessive formality at project meetings is not. Robert’s Rules of Order can safely be left at the door.
Virtual Reports, Meetings, and Project Management
In this chapter on monitoring, reporting, and control, it is important to note that PMs can and do effectively utilize what has come to be called the “information revolution.”
Using the Internet to communicate and report about the project’s status is now easily accomplished whether project team members are in the next cubicle or across the world. One large high technology company uses secure Web pages on the Internet to collect, store, and disseminate information on various projects. They have several Web pages that are specifically designed to communicate project information to and from clients. Others are designed for the sole use of members of the project team. Still others are created to communicate with the firm’s senior management.
A senior project manager in the software firm mentioned above offered the follow- ing comments on project communication:
In today’s entrepreneurial corporate environment, it is necessary to commu- nicate project information at varying levels of detail. Users run the gamut from software engineers to Business Unit (BU) general managers. Many of these users may not know or need to know how to use the project manager’s planning tools. In addition, management may not want users from other BUs to have the same level of access as users doing and managing most of the work. It is important to have tools capable of limiting the detail if the user is not interested in it or is not permitted to see it, and providing detail where and when the user needs it. There are third-party software tools that claim to do at least some of this.
Web pages can hold any information that the project manager wants to share, such as progress-to-date on a project, resources assigned to a task, status of a particular task, and expenses to date. The amount of information that can be shared is limited only by the planning and monitoring processes that are put into place and the project manager’s imagination.