Chapter 11. Project Monitoring and Control

A project plan, no matter how carefully prepared, is still only a piece of paper. During project execution, Dr. Project Manager must carefully monitor the health of his project-patient and give the right doses of corrective-action medicines when necessary. If the right doses are given at the right times, the patient survives. But failing to read the symptoms properly and failing to give the bitter pills on time can lead to further complications and possibly the death of the patient. The following two mini-cases illustrate this point.

Case A: Shiva was the project manager in charge of developing a secure transaction system for a large mutual fund company. His team, consisting of many dedicated but junior people, had little experience in computer security. The unit testing for the first few modules found a large number of defects much more than expected. Upon analysis, Shiva concluded that because of the difficulty of the programs and the inexperience of the programmers, the code being produced had more defects. Consequently, he felt, more defects would reach the integration and system testing stage, and unless something was done, more defects would be delivered. The corrective and preventive action Shiva took was to create a separate test team headed by a person who had a knack for detail and the right temperament for testing. Through discussion with the customer, he was able to expand the system testing phase by 15 days. Finally, even though there was a delay of 15 days, the delivered system exceeded its quality goal by showing fewer than expected defects during acceptance testing.

Case B: After the detailed design phase, the milestone analysis in Bala's project showed that even though there was no schedule slippage, there was an effort overrun of 40%. Because the schedule had not slipped, no action was taken. At the next milestone a month later, however, the project showed a delay of one week, which Bala explained as the result of special circumstances. Eventually, the development was finished one month late. To top it off, the number of defects found in acceptance testing was many times Bala's quality goal. In the end, his project failed on all three dimensions: effort, schedule, and quality. Later analysis showed that he had misunderstood the scope of the system and consequently had grossly underestimated the effort. If the scope or the schedule had been renegotiated when problems first appeared after the design milestone, the final outcome would have been entirely different.

These mini-cases bring out the two key aspects of project monitoring. First, project managers must have visibility into the true status of the project, for which the best approach is to quantitatively measure the key parameters.¹^,² For project managers, the main use of software metrics is to provide this visibility.³ Second, the visibility by itself does not solve any problem. Project managers must properly interpret the data, and if they find that the project is not moving along the planned path, they must apply proper corrective actions to bring it back on track. This collection of data to provide feedback about the current state and any needed corrective actions forms a fundamental paradigm of project management. Figure 11.1 illustrates this control cycle.⁴

Figure 11.1. The project monitoring and control cycle

graphics/11fig01.gif

This chapter describes how the monitoring and control cycle is applied at Infosys. This is the longest chapter in the book and covers a range of monitoring activities, including status reporting, milestone analysis, event-level control through SPC, process audits, and analysis for defect prevention.