Section 12.2. Closing Out Project Activities

12.2. Closing Out Project Activities

There are a number of project activities that require finalization or close-out once project work is completed. These include closing out the project issues log, addressing lingering change requests or work orders, and dealing with bug reports.

12.2.1. Issues Log

Despite your best efforts, it's likely there will be issues on your issues log that are pending or still open. The first question you should ask is: Is the project really complete? In some cases, an issue left open means that one or more deliverables might be incomplete or not up to quality standards. However, in most cases, leftover issues (whether pending or open) can indicate issues that were indirectly related to the tasks such as an ongoing issue with a tracking system or with a vendor. These issues may not ultimately impact the scope, time, cost, or quality of the project, but at the time they were raised, someone believed the issue was important enough to track it.

Hold a final issues log review meeting and look through all issues that are either pending or open (that is, all issues not closed). As a team, decide what to do with each issue. Some issues simply may not have been updated, while other issues may have resolved themselves. Other issues may require follow up and some issues may simply be irrelevant at this point. Don't just assume that the items on the issues list are irrelevant because you've determined the project is complete. Go through each line item and make a definitive decision about the issue. If it is no longer relevant, close it as unresolved with brief comments to note that no action was taken but that you are closing the issue. Your issues log should end up with no open issues at the end of this session. Any issues that the team feels should remain open should be transferred to some other tracking system so the issues log can be finalized and documented. The reason for this is simpleno one, including you, is likely to look at the issues log for a project that is complete. Rather than losing important issues that may still need to be addressed (a vendor issue, a corporate accounting issue, etcetera), transfer it to a more appropriate venue for resolution now that the project is winding down.

12.2.2. Change Requests/ Work Orders

It would be odd to find open change requests or work orders when your project work is complete, but it does happen. Review any open change requests or work orders to determine if your project work truly is complete or not. As with the issues log, review all open orders and determine why they're open. Some may be open only because the documentation hasn't caught up yet and the issue is resolved. Others may cause you to look more closely at project deliverables to make sure everything is in order. As with the issues log, don't just leave these items hanging. Close them with a notation as to why they were not addressed in the project. In some cases, these items may cause charge backs to the project (the client reducing the fee they'll pay you because some portion of work was not included in the final deliverable).

12.2.3. Bug Reports

Bug reports are like the issues log with one major exception. The development team may choose to defer fixing some bugs to later versions or releases. Therefore, it is critical that all open or pending bugs be updated (where applicable) and transferred to the bug tracking system for safekeeping. When the next round of development fires up, these bugs should be readily available so the functional and technical specifications can be written to address the most urgent (or desirable) bug fixes.