Data Collection and Reporting concerning the Project

Once we have decided on the type of data we want to monitor, the next question is how to turn them into information useful for controlling the project. In this section we cover the physical collection of data and the analysis of that data, if necessary, to transform them into information. 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 disseminat­ing 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, when we need to collect them, and precisely how we should go about collecting them. A number of ques­tions are raised. Should we design and use special forms? Should data be collected just before or after an important milestone or phase of the project? 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.

1. 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 Ball® can 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, 2016). 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.

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, 2016, Ch.7) 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, however, is much more interested in preventing fires rather than putting them out, thus the value of timely data collection and reporting.

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 Risk the risks necessary to achieve a project’s goals, or from mentioning problems when discovered.

2. 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 include 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 project 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 previous data, perhaps from earlier but similar projects, so that the PM and others can better 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 earlier 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 addition 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 and schedule while functional management may wish to see reports on technical accomplishments, 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 periodic reports 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 quarter do not get read. An exception to this rule against periodic reporting is made for reports 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 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. Important 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 technological 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 plan, again, identifies the level of tasks and responsibilities according 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 verification 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 reports, and in such a way that it cannot be overlooked. Similarly, it is of no value reporting 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 situ­ations 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 benefit 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 regard­ing the goals, progress, difficulties, successes, and other ongoing events of impor­tance 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 minimiz­ing 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.

It is not by chance that the PMI has labeled these collections of project reports, plans, charters, change orders, project histories, and other such documents as organiza­tional “assets.”

A special problem often encountered in designing project monitoring and reporting systems is the relationship between the project’s information system and the overall organization’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 regular information system as the definitional prototype for project monitoring and reporting, 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, and reports show the availability of various resources (see Chapter 6, Table 6-2) or the demands for work from individuals or groups (see Table 6-3 or Figure 6-9), just to name a few. MSP not only allows the PM to distribute the information anywhere that has electronic communication capability, but also allows easy customization of the reports limited 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 detail 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.

3. 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 email. 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 meet­ings only for making group decisions or generating input among meeting mem­bers for dealing with important problems or opportunities. That is, hold meetings to take advantage of face-to-face interaction when no other approach or technol­ogy is an adequate substitute.
• Distribute a written agenda in advance of the meetings. The lead time for distrib­uting 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 pro­ject, documenting important decisions and responsibilities. Do not delegate this responsibility. Microsoft Word® has 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. (Obviously 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 debate 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.

4. Virtual Meetings, Reports, and Project Management

Virtual meetings are now commonplace. Microsoft Livemeeting® is one of several pack­ages that allows any number of people to meet, hear, view, and discuss presentations or training sessions on conference call telephone lines and computers. Multiway voice and data communication allows questions and answers, either live (interrupting the meeting) or submitted via the computer. Multiperson conversations are quite possible.

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 revolu­tion.” 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 plan­ning and monitoring processes that are put into place and the project manager’s imagination.

Software programs such as Microsoft Project Server let you utilize the organization’s local area network or intranet, as well as the Internet, to help with project communication and monitoring. A project manager can electronically check the status of a task or any resource used on the project and have updated information automatically entered into a project plan. Electronic work groups can be set up to monitor task completion, resource usage, and to provide reports to a group of individuals who have an interest in the project’s status. For example, milestone reports can be sent to a senior management work group, and up-to-date personnel usage reports can be sent to the Human Resources department.

Using Microsoft Project, the converse is also true. With MSP and an appropriate computer network, anyone with authorized access can update his or her section of a pro­ject plan and submit it back to the PM for inclusion. Project teams and management at any site across the world will greatly benefit from these features. Using this network capability, users do not need access to a “resident” copy of the software. Valuable real­time reports can be prepared without lengthy phone conversations, or costly on-site meetings. The technological progress of the current “turn of the century” only means more effective and timely use of project information for planning, monitoring, and com­municating. Utilizing video conferencing, virtual presentations, Web posting, email, and so on greatly enhance the PM’s ability to manage a project.

Thus virtual project teams are created, perhaps spread across continents, with mem­bers contributing their own pieces of the project and being monitored and controlled by the PM at another location (Adams and Adams, 1997). In addition to its use for helping with the planning, monitoring, and control of projects, the Internet can also be a rich source of information. The project team can find building codes, technical aid, data­bases, patent information, expert contacts, and almost anything else on the Internet.

For the monitoring system, data in various forms have to be collected, analyzed, and reported. Data also need to be aggregated, manipulated in various ways, and compared with planned values in order to allow effective control. The monitoring system helps PMs prevent problems instead of having to solve them. Project reports vary in con­tent and frequency, depending on who the reports are targeted to and what controls they will exert. A special consideration is the relationship between the organization’s information system and the project’s system. In addition to printed reports, reports may also have to be given orally at meetings, but steps can be taken to maximize the effectiveness of such meetings. The Internet and the organization’s local area network or intranet have enhanced project communication and meetings as well as facilitated the management of geographically dispersed virtual projects.

Source: Meredith Jack R., Mantel Jr. Samuel J., Shafer Scott M., Sutton Margaret M. (2017), Project Management in Practice, John Wiley & Sons, Inc. 3th Edition.