4.3 Final delivery stage
As a project is a temporary undertaking, during the final stage (once the project manager has gained approval for all of the project’s products) it is time to decommission the project. The project board needs to be satisfied that the recipients of the project’s products are in a position to own and use them on an ongoing basis. Should this be the case, the products can be transitioned into operational use and the project can close. The project documentation should be tidied up and archived, the project should be assessed for performance against its original plan and the resources assigned to the project need to be released. The closure activities include planning post-project benefits reviews to take place for those benefits that can only be assessed after the products have been in use (and therefore after the project has closed). The activities to decommission a project are covered by the Closing a Project process.
4.3.1 How the final delivery stage would typically look when using agile
18.104.22.168 Plan, monitor and control
When formal checks are made against the project baseline defined in the PID, the key aspects that are assessed include the amount that was delivered, what extra was delivered and what was removed. This will have been happening continually throughout the project as the teams work iteratively and respond to feedback.
- Some of the products that the project intended to deliver may not have been created and may have been replaced by others that were not part of the original plan. This will have been communicated throughout the project and will not come as a surprise to the project board when they authorize project closure.
- The customer is already in ownership of several products that have transitioned into operational use and is now realizing benefits.
- Tidying up and archiving is a routine task by this point, as it has been taking place regularly throughout the project; its value is known to everyone and it is not seen as simply a bureaucratic task.
- Closing and decommissioning a project is not a significant event as it is a case of ‘tidying up’ and finishing off many activities to do with lessons, archiving and handover which have already been started because by this point several releases have taken place.
A regular event that looks at how the process of doing work can be improved. In keeping with the agile concept of ‘inspect and adapt’ these events help teams to continually improve their working practices, little by little, over time.
- Project closure involves (or is held as) a retrospective.
- There is an assessment of how appropriate the use of agile turned out to be to help with guidance on the use of agile for future projects.
- Outstanding work still exists on backlogs of some kind (e.g. a release backlog), and this is then moved to other backlogs (e.g. an existing BAU backlog), discarded or archived.
Lessons may be handed to project support informally, or project support may have been included in retrospectives if the teams were happy for them to be in attendance.
A list of new features for a product. The list may be made up of user stories which are structured in a way that describes who wants the features and why. It is also a generic term that can be defined in terms of releases, sprints and products.