CHAPTER 15: THE CLOSE PHASE

15.1 Purpose

This is the equivalent of the Agile transition phase.

Once all the products have been created, the project team doesn’t simply disband and move to other work. A project must come to a controlled end and be closed down in an organised and structured way. The client and development team must agree that a project has met its objectives before it can close and there must be a check that there are no outstanding problems or requests. The development team must also agree with the client that the end product meets the acceptance criteria.

In summary, the purposes of the Close phase are to:

•Confirm the products meet their acceptance criteria;

•Handover the completed products;

•Create a project closure report;

•Check the post project review plan; and

•Disband the project team.

Final details are recorded by the team of how long the project took from start to close. Resource usage and cost are compared to the estimates created at planning time, so that a report can be sent to the client on the success of the project. Part of this report will show how much of the various tolerances were used by the project, together with any reasons for this usage.

Any useful lessons learned in the project are recorded for the benefit of future projects. A record is made of any risks or issues that were outstanding at the end of the project and which may require attention during the life of the products, such as change requests that were postponed during the project. Both of these records form part of the project closure report.

There should be an agreed plan to judge achievement of the claimed benefits when it is appropriate to do so. The post project review plan (see section 13.7) was created in the Plan phase but may need updating in light of any changes made later in the project.

The completed planning, actual costs and time will go towards a summary of the project performance in the project closure report. The Close phase work may also be sufficient to add towards the total project cost and time. The project closure report also states how much of each of the agreed tolerances has been used.

The total actual costs and time taken by the project may affect the level of benefits that were claimed in the project justification, and this may then affect the post project review plan, i.e. has there been a change to the date when some of the benefits can be measured and will they be at the same value expected in the project justification? Therefore, the post project review plan may need to be updated before being submitted to the client.

The action log is reviewed to ensure that every issue and risk has been closed down or transferred to the project closure report.

Figure 15.1: The Close phase

15.2 APM principles supported

Business need:

The process mainly supports continued business justification. It assesses any benefits already achieved by the project and ensures that there is a reasonable post project review plan to present to the client.

Communicate:

This may be stretching it a little, but the process transfers ownership of the products to the customer and terminates the responsibilities of the client.

15.3 Confirm product acceptance

The product owner must confirm that the project has delivered all the required products to the level of quality defined in the client’s quality criteria and that the work meets all the acceptance criteria.

15.4 Handover products

There must be a controlled handover of the project’s product(s) and documentation to the users, or those who will operate and maintain them. The development team is responsible but must liaise with the client and users to ensure a smooth and complete handover. This includes:

•Checking that a suitable operational and maintenance environment is ready and prepared to accept the handover;

•Checking the handover arrangements to confirm how the project’s products are to be handed over to the operational and maintenance staff;

•Passing the project’s products to the relevant operational and maintenance environment;

•Updating the status and location information in the product version control records (see section 8.5);

•Checking if the product records are to be moved to a new site;

•If so, passing the product records to the maintenance staff; and

•Checking the post project review plan contains measurements for all claimed benefits that cannot be checked until after a period of operational use of the products.

15.5 Create the project closure report

Normally the Close phase will be so short that progress reports will not be needed. In exceptional circumstances, the client may ask for a progress report, which will follow the same structure as those in the other phases.

The client and development team must agree that the project has met its objectives before it can close and there must be a check that there are no outstanding risks or issues.

The project documentation, particularly agreements and approvals, should be preserved for any later audits.

The actions performed by the development team to bring a project to a controlled close are:

•Updating the project justification document with the final costs and times;

•Confirming acceptance of the project’s product from the client and those who will operate and maintain the product during its operational life;

•Checking that any open risks and issues that might affect the products in their operational environment have been transferred to the maintenance staff;

•Recording any useful lessons that were learned;

•Obtaining agreement from the client that project resources can be released;

•Reviewing the original project mandate, the project justification documents and any changes to it to understand what the project was supposed to achieve;

•Reviewing the project’s performance against the project justification in terms of cost and schedule, plus any benefits achieved by the end of the project;

•Assessing the project’s performance in terms of its usage of the tolerances; and

•Creating the project closure report.

15.6 Check the post project review plan

The post project review plan, created in the Plan phase, shows when, how and with what resources the claimed benefits of the end products can be measured (see section 13.7).

The development team is responsible for checking the post project review plan. It should be checked against all actioned issues to see if there has been any impact on the level of claimed benefits or on how and when measurement of the benefits should be done. If there have been any changes, the post project review plan should be brought up to date.

The development team will probably have been reassigned elsewhere by the time that benefits should be measured. Therefore, the client will be responsible for managing the actual measurement of the benefits, so the development team should pass the plan to the client and ensure that the plan is fully understood.

15.7 Disband the project team

At this point all project work should have been completed and the end product handed over. The team lead should confirm the disbandment of the project team with the client after agreeing that the acceptance criteria have been met.