End Stage/project procedures 1.0.0

Purpose

This document contains the elements for preparing any end-period (from stage to project) report. The sections are briefly described with the purpose of highlighting the links to the relevant document. This will allow the creation of tables where the original values (set at project’s start) are confronted with the results.

General Purpose

Review of results against baselines.

All these processes are carried through the analysis of the modifications of the baselines; these will be checked with the rules set in the “Management Strategy” documents type.

1. Business Case review
2. Project / Stage Plan outlook
3. Risk Review
4. Project Issue situation

(Team)Performance

These are the main sources:

1. Quality Statistics
2. Completed / Current Stage plan with all the actual approved outputs.
3. EVM results (to be delved in the next version).

Tolerances usage and performance.

Project Manager’s report on any events that affected project/stage performance. Giving the correct importance to any abnormal situations are described, together with the related information describing specifically:

1. Issue and related impact analysis
2. Risks (both from analysis and management viewpoint)
3. Learned Lessons (whether the process has been booked or not) passing on of any lessons that can be usefully applied to other stages/projects.
4. Any available useful documentation or evidence should accompany the follow-on action recommendation(s).

Product Name

These are the main sources

1. Quality Records
2. Discrepancies between Planned vs. Completed
3. Approval Records vs. Off-specifications

Administrative closure

1. Verifying that every allocated resource will be released in accordance with the specific agreements. For the people involved, it is essential to spend a lot of care in dealing with any potential issue involving the HR Department as soon as the closure date has been decided.
2. Every contract has to be closed as dictated by specific agreements. The role of PM mainly consists in checking that all procedures and any pending issue have been properly addressed by relevant departments. Just in case of claiming (e.g. under performances) all documents shall be made available through the “official” channels.

Learned Lessons (Retrospective).

It could be presented as a review of what went well, what went badly, and any recommendations, in view of the targeted audience changes from Sponsor / Project Owner to corporate or programme management consideration. Especially, if the project was prematurely closed, then the reasons should be explained.

Hand-over documentation

Review of performances against targets. How the project performed against its planned targets and tolerances for time, cost, quality, scope, benefits and risk. Review the effectiveness of the project’s strategies and controls)

End Stage specific purposes

To give a summary of progress to date, the overall project situation and sufficient information to ask for a Project Board decision on what to do next with the project.
The Project Board uses the information in the End Stage Report to decide what action to take with the project: approves the next stage, ask for a revised next stage plan, amend the project scope or stop the project.

Lesson Learned (the document is directed to the Project Board.

End Project specific purses

1. At the end of the project, all issues should either be closed or become the subject of a follow-on action recommendation.

1. Building the best possible documentation for the hand-over phase, with the aim of passing on of details of unfinished work, ongoing risks or potential product modifications.
2. Benefits achieved to date that become: “Residual benefits expected” at the end of the project.
3. Lesson Learned

Quality

A specific care should be added to the standard recommendations.

1. Avoiding the problems’ personalization. Whenever a problem is spotted, it is important to be able to present the whole scenario. The scope of the process is the comprehension of the facts to be unbiased related to the person. This is the most difficult phase of the “Lesson Learned” (was the person inability or the circumstances – including the process – that caused the fault?).
2. Profile. Any project is different from others. Therefore, the planning of this document requires the collection of all the documents with a special care for the important modifications (those exceeding the stated allowances). This increase the efficiency of the review, by leaving out those elements that fared within the norm. The process of screening those element considered more useful will be done starting from the “strategy management” as main sources.
3. Priority. Once the profile has been set all options are kept available for further development. Wherever is meaningful, notes are added as example and suggestion.

RACI (who does what)

Operation desc./Roles	Owner	Spr	PM	SME	BA	Stkhd
Receiving (negotiating) the project’s closure	C	C	A	I	C	C
Collecting all necessary documentation (starting from people assignment to involve HR as soon as possible)	I	C	A	R	R	C
Verifying that all necessary information is consistent with the project’s standards.	I	C	A	I	R	C
Assessing the following areas: Performances Quality Risk and pending Issues Products Business review	C	A	R	C	C	C
Planning and the managing the “retrospective” meeting(s). It depends upon the organizational needs.	C	C	A	I	R	C
Checking that the “Hand-over” processes are running with the stakeholder’s (team(s) responsible for implementation and maintenance) are satisfied with them.	I	C	A	I	R	C
Starting the “close-out” procedures	I	C	A	I	R	C
Organizing the project’s celebrations	C	C	A	C	C	C
Preparing and delivering the “final” report	C	C	A	C	C	C

Procedures & documentation

Plans

1. Schedules
2. Resource allocation. Highlighting the relationship between production outputs and costs.
3. Resource skills/turnover

Issues

There are two reasons for including the Issue Management Register structure within this document;

1. Check those are still open. These will be included in the hand-over process. This result will be produced by a very simple query.
2. Tracking the issues that created important (over the established tolerances) deviations in one of the main project’s dimensions (time, costs, and scope/quality). This analysis can be started querying the “Severity” and then check any reference to the “plans”

Risks

1. Still pending risks (e.g. those related to the product’s commercialization). These are queried by the Risk Register.
2. Analysis of the performance. How the Risk Analysis and then the Management fared against the reality of the project.

Quality

Quality Report. This will be used for spotting the area that (hopefully) exceeded the plans or required a special attention for poor faring.

Product

Product Description, where the “Acceptance Criteria” and “Benefit Review” are the leading sections.

Project Product Handover

Confirmation (in the form of acceptance records) by the customer that operations and maintenance functions are ready to receive the project’s product)

Summary of Follow-on Action Recommendations

(Request for Project Board advice about who should receive each recommended action. The recommended actions are related to unfinished work, ongoing issues and risks, and any other activities needed to take the products to the next phase of their life).

Final report

This document (template will be prepared a.s.a.p.) should concisely address the following areas:

1. How much the project has fulfilled the reasons for being undertaken? This could be done through the presentation of the initial aims to be confronted with the results, making explicit references to the applied metrics
2. Praising each person who gave outstanding contributions.
3. Listing the influencing factors, starting from the positive ones.
4. Closing the document with the address of all the relevant documentation.