This paper examines the consequences of failing to properly close a project, with a focus on two key issues: the failure to document lessons learned and the tendency of project team members to disengage during the closing phase. Using the DRAMA software project as a case study, the paper illustrates how inadequate documentation at project closure can undermine a product's long-term viability. It also identifies common reasons why project managers and team members resist thorough closure, including project failure, eagerness to move on, and financial incentives, and argues that disciplined closure procedures are essential for organizational success.
There are many consequences of not properly closing a project that can affect its success — or the success of an entire program — for years to come. Among the most important aspects of project management is the closing phase, which, when neglected, can undermine work that took considerable time and resources to complete.
One of the most critical components of project closure is documenting lessons learned, especially in organizations that run multiple projects. In many IT projects, for instance, lessons learned throughout the project lifecycle can affect future related projects or other projects with similar objectives. They can also affect the long-term serviceability of the project's deliverable.
If an IT project produces software, for example, future revisions or software updates can be deeply impaired by the failure to document critical aspects of the lessons learned during closure. A software update team may not be able to trace the original steps taken during the project, making it difficult to fix bugs or make future improvements to functionality.
One instructive example is the DRAMA (Design RAtionale MAnagement) project — a commercialization of a university prototype for recording the decision-making process during the design of complex, long-lived artifacts such as nuclear reactors and chemical plants (Successful Software, n.d.). The project experienced a number of failures, and no licenses were ever sold.
One of the key problems was the failure to document some of the software's design features. When the product was later demonstrated or offered for sale, many of its features were unclear to potential users, and people did not know how to operate it effectively. Had the project team documented the more subtle features built into the software — and organized that documentation clearly during the project's closure — the resulting program would have stood a much better chance of being marketable and successful. This case illustrates how lessons learned documentation is not merely a bureaucratic exercise but a practical safeguard for a product's viability.
"Reasons teams avoid thorough project closure"
Despite the natural impulse to skip proper closure steps, it is important that the project team takes the time to properly close a project and follow closing procedures closely. The consequences of neglecting this phase — from undocumented lessons learned to unresolvable software defects — can persist long after the project itself has ended. Disciplined project closure is not the end of the work; it is what gives the work lasting value.
You’re 52% through this paper. Sign up to read the remaining 1 section.
Sign Up Now — Instant Access Already a member? Log inAlways verify citation format against your institution’s current style guide requirements.