7 Progress Monitoring
Monitoring project performance is essential to keeping the project manager informed of the status of the deliverable. Data collected during the process is crucial in managing the issues and circumstances that will be brought on by the inevitable changes to the project.
The focus and emphasis of project progress monitoring is fundamentally different from traditional cost accounting. Cost accounting by and large deals with issues involved in reporting the expenses to the correct components of the established budget cost centers and account codes. Cost accounting focuses on collecting accurate actual cost information with specific attention to the elements of the code of accounts; project progress monitoring, on the other hand, focuses on areas of resource expenditure as delineated by the WBS.
There is no question that accurate collection of cost information should be part of the data that are collected or computed by a project monitoring system. However, cost is not the primary concern of the project management data collection; rather, deliverable-specific resource expenditure data are the key concern. There is also a belief that cost accounting, by and large, focuses on history, whereas project monitoring collects data for improving performance and for predicting the future.
The observed variances in resource expenditure, cost, and project duration will be used to identify trends, which will in turn be used to make midcourse adjustments to project plans. Depending on the organization, these adjustments might or might not result in a new budget, but at the very least a realistic prediction of these values for project completion will be developed. The reliance on the RBS and WBS, provided by a formalized progress monitoring system, will allow project managers to compile meaningful historical data that will be useful in managing the changes in the texture of the current project, while providing useful historical data for streamlining the estimation and management of future projects.
The accuracy and efficiency of the project estimate depends on data collected from previous experiences in similar projects, and in turn a formalized monitoring system will produce a new set of data. These data will be very useful in collecting historical data for cost estimating models and general organizational memory, which will in turn benefit the effectiveness of future projects. In essence, although the progress monitoring system benefits the project at hand significantly, it has far-reaching benefits for future projects and for organizational project management effectiveness as a whole.
Progress monitoring is most successful when it is fully embedded into the formalized organizational procedures for managing projects. Therefore, progress-monitoring procedures should be part of the organizational project management culture, rather than narrowly focused just on the project at hand.
The progress monitoring system should be formulated and implemented so that it will not negatively affect the efficiency, creativity, innovation, and morale of the project team’s technical personnel. Rather, it must be a facilitative tool that informs the team members of their individual assignments, reminds them of forthcoming events, and warns of significant variances. Additionally, the progress monitoring system will centrally store the data for forecasting and future customization of estimating models.
Unfortunately, in many of the creativity-based and highly specialized projects, the project team might regard progress reporting as cumbersome, intrusive, and a signal that senior management does not trust the project team. Project managers who use progress data for pressuring individual task leaders to deliver products faster often reinforce and perpetuate these sentiments. Further, divisional managers who, with a misguided objective of efficiency and improvement, use progress data to micromanage the project team provide unwitting affirmation of the team’s negative attitude toward progress monitoring measures.
The function of a progress monitoring system is to keep each project team member informed of the progress of his or her own task and apprised of the progress toward attainment of the overall objectives by all of the team members. As such, the progress monitoring system should be regarded as nothing other than a valuable aid.
In other instances, particularly in projects that involve a great deal of creativity and new technology, project team members regard progress monitoring as an affront to creativity. Ironically, a logical progress monitoring system should not impede creativity, but rather should assist the team members in understating the cost and schedule implications of their contributions to the project, thus allowing the project professionals to concentrate on producing superior deliverables. With proper education, the majority of the team members and upper management should adopt a more accurate view of progress monitoring.
If the organization is progressive enough to have a PMO, much of the formalization of the progress reporting process is handled as part of its foundation. Although many organizations do in fact have a project management culture and a commitment to formalized project management, this organizational entity may not be called a PMO. The qualities that are necessary to achieve the desired goals in project management are: organizational commitment to project management principles, a set of consistent procedures, and a battery of operational tools (see Figure 7-1).
Figure 7-1
Implementation Elements
The basic foundation for a project management culture is the firm commitment to principles of project management, such as formal scope definition for every project, extensive use of the major project structures, logical cost management policies, and usable cost reporting procedures (see Figure 7-2). The commitment to these principles should be reinforced by the use of enterprise guidelines and procedures such as those necessary for superior performance in project initiation, approval, mobilization, implementation, and closeout (see Figure 7-3).
Figure 7-2
Project Management Principles
Figure 7-3
Project Management Consistent Procedures
Finally, the project team members must have at their disposal a set of operational tools that facilitate compliance with enterprise project management policies. These tools, which must be updated and expanded regularly to stay at the state of the art, include data capture forms, scheduling methodologies, progress reporting forms, and performance enhancing software packages such as PM software, databases, spreadsheets, and presentation graphics (see Figure 7-4).
The project monitoring policies and tools are not meant to be restrictive, but rather informative and facilitative. To that end, as the organization matures, and as highly competent project teams contribute to designing and conducting the monitoring process, the suitability, applicability, and usability of the project management tools and techniques will continually improve.
DEVELOP A MONITORING PLAN
The project monitoring system must be appropriate to the project and to the environment that hosts it. This appropriateness can be ensured by defining, clarifying, and documenting the unique attributes of the project and the organization. The procedures by which projects are initiated also should include procedures for establishing baselines and for monitoring the project against them.
Figure 7-4
Project Management Operational Tools
Normally, those people at the higher levels of the corporate structure authorize the vision for a new project or a new corporate initiative (see Figure 7-5). Such a vision might emanate either from the upper levels of the organization or, in more enlightened organizations, be developed at the project level and presented to upper management for approval. As the implementation of this initiative is delegated to lower levels of the organization, a more detailed definition of this vision is developed.
The directive that is drafted at the CEO level may be a one-paragraph or even a one-line vision (see Figure 7-6). However, by the time this initiative is developed at the lower levels of the organization, it may involve many pages of descriptive design and many pages of hardware and software specifications. To use WBS terminology here, the Level Zero of the project is specified at the top levels of the organization, and the lower levels are developed, designed, and implemented by the subsequent levels of the organization through the project team members.
Figure 7-5
Project Stakeholders
Figure 7-6
Project Plans
Voluminous and detailed project data are exceptionally useful to the project team members but can be overwhelming to those who are not intimately involved with the project. Likewise, during project implementation and when the progress data are compiled, refined, and tabulated, care should be taken to observe the same level of detail in the refinement or analysis of the data that is contained in the reports that will be distributed.
The best data collection and reporting systems are those that customize the level of detail to the organizational stature, and involvement level, of the person supplying the information for the report and the person receiving the report. Additionally, the data that are collected, and the trends that are reported, must be at a level of detail that allows deviations of the actual value from the baseline project plan to be detected. Finally, the report frequency must be such that the project team can deploy corrective measures in a timely and useful manner if the variances indicate the need for a change in the project’s pace.
Project staff members should get all possible details regarding their own tasks, interdependent tasks, and the project in general. However, at the other end of the spectrum, the CEO probably will get a one- or two-line report on the status of the cost and schedule of the project—maybe not even at the same frequency that the team gets its reports. Naturally, if any of the top executives require additional information for a more detailed review, it can be made available (see Figure 7-7).
Figure 7-7
Data and Report
The same degree of specificity that was used in generating the project definition documents must be applied to defining the contents and distribution pattern of the progress reports. The progress monitoring procedures must specify how often the data capture should be conducted for the progress reports and how often the progress reports should be issued.
When developing data capture procedures, all affected parties must agree on who will collect the data, who will provide it, and what the expected tolerance of the data is (see Figure 7-8). For example, if the item to be measured is the number of programs written or volume of concrete poured, the project charter must specify whether the measurement is to be performed by the technical person doing the work or by an administrative staff person who is in charge of data collection. Beyond that, specifics of the frequency of data collection must be outlined beforehand (e.g., if the data will be collected, daily, weekly, monthly, or quarterly).
Those project stakeholders who receive progress reports should be fully aware of their obligations regarding the contents of the report. Some may receive the report for information only, and no action is required of them. Others may receive the report for review and action. The type of action and the turnaround time must be specified as part of the project charter or the monitoring guidelines (see Figure 7-9). This kind of specificity ultimately will introduce efficiency and expediency in the conduct of the project.
Figure 7-8
Data Capture Projects
Figure 7-9
Report Distribution List
With these precautions in place, the volume of a progress report will not overwhelm the recipients when their involvement in the project is minimal. Further, there will be fewer occasions when someone is not sure why he or she has received a progress report. More to the point, those who need to react to the project events will get the correct and sufficient information to execute their specific duties.
If these steps are implemented in the reporting system, project personnel will know what is expected of them in terms of data to be provided for input into the progress reporting system. Accordingly, the project personnel will have a clear picture of the volume, quality, and frequency of the reports they will be receiving.
To increase the monitoring and reporting system’s utility, the collected data must be compiled and refined as part of each data collection cycle. Then, the refined data and their analysis should be reported to the team in a timely manner, and at the level of detail that is useful to the recipients.
DETAILS OF MONITORING
Examples of progress indicators in construction projects are number of feet of wire pulled, cubic yards of concrete poured, and square feet of carpet installed. Examples of progress indices in systems development projects are number of screens completed, number of lines of code written, and number of machines enabled. For WBS elements that have a series of sequential subtasks, the achieved milestones can be a measure of progress. Examples of task milestones for a server installation project could be receive, place, connect, test, accept, and turnover.
In some organizational environments, lapsed time and cost of labor are considered indications of progress. Although these indicators are useful in measuring the cost incurred, they do not have a direct relationship with progress, and therefore they can be misleading and highly inaccurate for reporting progress.
A more rational set of progress indices would include measurements of what has been delivered and indications of the rate of resource expenditures with respect to each deliverable. The raw progress data for each activity should contain as many of the following pieces of information as possible: actual start date of the activity, volume of deliverables, effort spent so far, and effort needed to finish the activity.
The raw data, by which progress in activities of the project will be recorded, might also include work days spent, worker days spent, total cost of labor, and total cost of materials or equipment (see Figure 7-10). Care must be taken to distinguish between worker days, workdays, and lapsed days when capturing progress data.
Figure 7-10
Progress Reporting
The progress monitoring system provides formalized data capture procedures that will allow development of a set of logical and rational indices to measure the pace of attaining project objectives. The progress is measured in the areas of cost, schedule, and scope. The baseline data might be the original baseline data, although in most cases they are a modified version of the original. To clarify, the purpose of progress monitoring is not to force project progress, and its associated costs, to the figures that were pre-defined as part of the plans and budget, but rather to report accurate values of actual project performance indices, with the hope of developing work-arounds for the significant variances.
The project manager might use the progress data as a basis for making adjustments to the work pace. Alternately, he or she may make an informed determination that the variances are transient or not significant, and that no major changes need to be made. Finally, the project manager might conclude that it is more appropriate to draft a budget modification request.
EARNED VALUE
The general definition of earned value, in the context of project management, is a definitive indication of how much progress has been made in delivering the final project results. In the case of external fixed-price projects, this value translates to the amount of funds that are payable to the contractor.
Calculating earned value has been found to be a very effective tool in measuring the progress of contractors in external projects. Computing earned value can be part of an audit activity, or it can be integrated into the project’s progress monitoring system.
The concept of earned value generally is used in monitoring the progress of fixed-price contracts in which the objective is to calculate the amount of payment that is due to the contractor. The values derived using this concept will highlight the portion of the payment that the contractor has earned by calculating the amount of deliverables produced as of the reporting date. However, to the extent that earned value reflects the magnitude of progress, it also will be useful in internal projects. It can serve as an equally powerful tool in determining the rate of progress of internal projects toward achieving the goals of the project.
For creativity-based tasks, in which the deliverable often defies measurement and in which progress is an illusive and immeasurable concept, guidelines need to be established for measuring the project’s progress. Depending on the organizational culture, project complexity, and the needs of the project, one of several crediting methods can be applied.
For some activities, progress credit can be applied when the task is started, and credit can be applied incrementally as progress is made. Yet, in other organizational environments, a binary system in which credit is applied only when the completed deliverable is received must be used. Under this system, no credit will be applied if the deliverable has not been received, regardless of how much time and money have been spent on the task.
A variety of intermediate crediting methods can be devised to accommodate situations that do not call for either of these two extremes. Figure 7-11 shows a partial list of possible crediting methods. The rationale for developing and using these crediting schemas is to provide project management data as accurately possible with minimal intrusion into the technical facets of a particular task.
Although these crediting guidelines seem imprecise—and they are in fact imprecise at the elemental level—once they are summarized across WBS levels, the overall progress of the higher levels of the WBS can be acceptably accurate. The assigned progress percentages do not have to be exceptionally accurate; in fact, due to the nature of many creativity-based projects, the accuracy of the assigned progress percentages is normally somewhat low. Again, notwithstanding the inaccuracy at the lowest level, once the earned values are rolled up to the project level, the accuracy is acceptable if there are no overt biases in determining the elemental earned value.
Figure 7-11
Progress Reporting for Non-Measurable Activities
The value that is earned for each WBS element can be determined by summing the progress made in each of the tasks that must be performed to deliver the WBS element at hand. Figure 7-12 shows the procedure for establishing an earned value system for a deliverable element. The first step in this process is to formulate a list of values during the planning stages of the project. Then, at each reporting milestone, the progress credited to each of the constituents, using any of the crediting methods described earlier, is determined. Total earned value will be the sum of the products of the value amounts and credited progress.
Figures 7-13 through 7-15 show the development of earned value for a segment of a website development project. Figure 7-13 shows a listing of the values that were defined during the planning stages by the stakeholders for this project. The value list can be a compilation of the distribution of either cost or effort among the activities of the element being evaluated.
Figure 7-13
Sample Earned Value (website development value list)
The team’s progress in achieving the goals of the element in question is indicated by the total earned value. This progress is determined by summing the credits earned by each of the constituent activities, toward the deliverable, as shown in Figure 7-14. Accordingly, Figure 7-15 shows a computation of the value earned for the deliverable element.
Using the earned value technique at any point during the life of the project, the amount of progress can be determined by summarizing the earned value of lower-level components along the WBS structure. The earned value for the project can be computed by determining the percentage of earned value for each of the constituent components at the lower levels of the WBS.
Figure 7-14
Sample Earned Value (website development reported delivery)
Figure 7-15
Sample Earned Value (website development recommended payment)
During the early stages of the project, and for small projects, this process involves only a few elements at the first one or two levels. For fully developed projects, the process would involve a very large set of all of the lower-level components of the project, extending to levels 4, 5, and even lower, of the WBS.
Some project managers choose to use a more extensive schema for earned value. This schema is fundamentally based on four terms. These terms, and the resulting predictive indices, are calculated or refreshed at evaluation milestones of the project.
• PV—What was planned to be done
• AC—What was spent
• EV—What was done
• BAC—Budget at Completion, the amount budgeted for the entire project.
Then, the following series of evaluative and predictive ratios is used to assess the project’s current state and to predict its future direction:
• EV-AC = CV, Cost Variance—the amount of cost overrun or underrun
• EV-PV = SV, Schedule Variance—the schedule overrun or underrun in $
• EV/AC = CPI, Cost Performance Index—normalized cost overrun or underrun
• EV/PV = SPI, Schedule Performance Index—normalized schedule overrun or underrun
• BAC/CPI = EAC, Estimate at Completion—updated estimate of total project cost
• BAC-EAC = VAC, Variance at Completion—amount of overrun or underrun at delivery
• (BAC-PV)/CP I= ETC, Estimate to Complete—funds needed to complete the project.
PRODUCTIVITY
The estimate of the cost of an activity, or a project, is based on average or anticipated attributes of the deliverable. This estimate can be refined and updated once it becomes clear who will perform the tasks and what their skill levels are.
The term “productivity” usually is associated with concepts such as spending less money, taking less time, using less effort, and ultimately creating more output with less input (see Figure 7-16). Client factors, such as the specificity of the project objectives, clarity of project plan, and availability of tools, particularly with respect to individual assignments, also affect the team’s productivity (see Figure 7-17). In addition, productivity is affected by the characteristics of the project team, such as personal pride, attitude, competency, the motivation to learn, and the desire to excel (see Figure 7-18).
Productivity also is affected by the frequency of unexpected and unexplained changes to the project and the presence of a formalized scope change policy. Productivity depends on the environment created by organizational policies and procedures with respect to innovation, efficiency, and reward. Finally, experience has shown that the productivity of the contractor’s team is additionally affected by the type of the contract.
Figure 7-16
Productivity
Figure 7-17
Client Factors That Affect Productivity
Figure 7-18
Team Factors That Affect Productivity
Strategies that improve workforce productivity include assigning the correct specialty and the correct competency level to each task. Proper assignment of labor will greatly enhance team morale, and verification of such assignment should be an integral part of project progress monitoring.
Sometimes, particularly in projects that involve lengthy or highly repeatable tasks, productivity is expressed by a learning curve. The premise in the concept of a learning curve is that if a task is performed repeatedly, it will take less time to perform that particular task the more frequently it is performed. As an example, designing a web page might take 120 minutes for someone who is doing it for the first time. But, as the same person designs similar pages, each repetition will take a little less time, so that the thirtieth page can be done in, perhaps, 100 minutes.
The extent to which this improvement occurs is determined from plotting task time vs. number of repetitions, otherwise known as the learning curve. Because the learning curve usually is plotted on a log-log scale, a line on that scale will characterize the learning curve; it is therefore called the learning curve even though the most common way of visualizing it is in a linear fashion.
Figure 7-19 shows three separate lines (curves) indicating the rate of productivity improvement for three different operations. This figure shows that after 32 repetitions, one operation gains a 10 percent reduction in performance time, while another gains a 30 percent reduction. For lengthy projects that include highly repetitive tasks, the effect of the learning curve on project cost and duration performance should be considered.
Figure 7-19
Learning Curves
