minimizing losses on a late project

The following post is the text of a short paper I wrote for a course in Software Systems Development. The writing style is a little formal for a blog, but I wanted to share because I believe the advice is sound, not just in terms of the citations, but based on my real-world experiences as well. Sometimes it's hard for me to believe that I've been working in software for over a decade...

Although software engineering practice focuses on establishing good project plans from the onset, sometimes it becomes necessary to consider what happens when a project becomes late and over budget. In the case where a project is nearing completion (and one has come too far to cancel the project), there are some project management strategies, specifically relating to project monitoring and control, to minimize the lost revenue for the project.

Monitoring and controlling the staffing level in the project is essential for stabilizing the development cost. Personnel shortfalls are common in projects, so common that Boehm (1991) considers it one of the top 10 risks on any software project. However, according to Brooks (1974), one must resist the temptation to add staff to the project or risk it becoming later, and as a result, more expensive. Adding staff generally increases the communication overhead between project team members and it takes time for new staff to familiarize themselves with the project (Brooks, 1974). The only case where adding staff might help accelerate the project towards completion is where new team members are already familiar with the tasks to be performed, thus reducing the learning curve to understand how the project operates (Glass, 1998).

With a stable development staff working on the project, it is also important to monitor and control the project’s requirements. Wallace and Keil (2004) consider “scope and requirements” to be one of four major risk categories on a project. Scope and feature creep needs to be controlled through the customer and controlled within the development team as well. Using a Requirements Traceability Matrix, the project manager should monitor the development team’s effort to ensure everything being done in the design, implementation, and testing activities is traceable to a stated requirement. Tracing work being performed by the development team back to requirements helps to limit any extra work beyond the stated requirements being done (Wallace and Keil, 2004), which would further delay the project and increase the cost. Glass (1998) also suggests reducing the initial project scope if it is possible with the customer – deferring or eliminating some requirements or features to make the task more feasible.

Despite the pressures of a project being late and over budget, the project manager should continue to monitor and control the project processes, particularly quality control. Glass (1998) suggests that projects often fall behind schedule because there was not enough time originally allocated in the schedule and that 85 percent of project managers extend the schedule as a result. Although extending the schedule may result in revenue loss, conducting the remainder of the project according to the planned processes may minimize the revenue loss. Effective quality management reduces the risk of introducing defects, which would adversely affect cost and schedule in terms of effort required to manage and rework the defects.

In a project that is late and over budget, project managers should reexamine what is known through project monitoring and readjust through project control. The project manager must address the fundamental questions in a project: Who is working on the project? What are they working on? How are they working on it? Finding stable answers to these questions will result in the project being completed with a minimal loss in revenue.

References
Boehm, B. (1991). Software Risk Management: Principles and Practices. IEEE Software, 8(1), pp. 32-41.

Brooks, F. P. (1974). The Mythical Man-Month. Datamation, December, 1974. pp. 44-52.

Glass, R. L. (1998). Short-Term and Long-Term Remedies for Runaway Projects. Communications of the ACM, 41(7), pp. 13-15.

Wallace, L. & Keil, M. (2004). Software Project Risks and their Effect On Outcomes. Communications of the ACM, 47(4), pp. 68-73.