On this page:

• Complying with the “Definition of Done”
• Monitoring Quality, Budget, and Schedule Performance
• Effective Project Change Control and Risk Management
• Ensuring Smooth Transition to Maintenance and Operations

Agile practitioners who use the Scrum project management methodology are familiar with the the “definition of done”. Basically, every piece added to the product or service during the project has to conform to a well-defined set of acceptance criteria. In this way, nothing gets added into the final deliverable without conforming to the definition of done. As we saw in our last article on checking if the execution of the project is complete, getting customer acceptance of our deliverables is crucial. It is impossible to close out the project if what we have produced is not acceptable.

Complying with the “Definition of Done”

We also need to demonstrate that the product, service or result delivered meets the quality goals we set out during our planning work. Similarly, we need to compare the baseline budget with the actual spend and explain the differences, if any. While some cost differences might reflect poor estimation or unforeseen expenditure, others may have been due to change requests approved during the project. These changes should have caused the budget to be re-baselined.

The other major project planning artefact is the schedule. How does the actual time taken compare to the planned, baseline schedule? Were the differences due to poor estimation or due to approved change requests? Also, it is interesting (both for the schedule and the cost baselines) to note how often these have been updated during the project. A lot of re-baselining due to approved change requests suggests that scope planning on the project was weak; re-baselining due to project milestones being missed reflects on the original estimating process. Certainly, the answers to these questions will contribute to vital lessons learned.

Monitoring Quality, Budget, and Schedule Performance

Another area to examine is the whole project change control process. Was this done properly? Often, change control is not taken seriously and changes are added to the project scope without factoring in schedule and budget impacts. Similarly, the risks associated with the changes often do not appear on the project risk register. Every change request should appear in the project change log and its status noted. If it is approved, then its impact needs to be recorded as well. Review the change log: did these steps take place?

Effective Project Change Control and Risk Management

The goal of any project is to create something new. However, once it is created, it needs to be transitioned to a maintenance or operations group. This needs to be planned and work is involved to ensure a successful handover – it does not happen miraculously! Documentation needs to be put in place and the maintenance people need to be trained up in how the product, service or result works. Being in-house personnel, they can receive inside information on known weaknesses with the deliverables and given techniques to overcome them. The maintenance group needs to be factored into the project plans and given as much information as possible as soon as possible. Involving maintenance people in the project design phase can also influence the way the deliverable will work. Sometimes a simple design change can more than pay for itself in simpler maintenance down the line.

Ensuring Smooth Transition to Maintenance and Operations

What resources have we used on the project? Have we freed these up? Because of issues with customer acceptance, we might want to hang on to some people to complete outstanding tasks. This needs to be negotiated with line managers. Similarly, equipment and materials need to be returned to the company’s resource pool. Make sure you shut down any cost codes associated with the project.

What documentation was expected from the project? Has this been archived properly? We should have planned this out in our project communications plan. In certain industries, the certified destruction of classified material is a requirement, while others demand that records be kept for a minimum amount of time. If there are any records involving people, then be aware of your responsibilities under the Data Protection Acts.

Always hold a post-mortem meeting and use it as an opportunity to review the project and reflect on how it went. What was done well? What was done badly? What should be done differently next time? It might be useful to hold several of these. It might be more revealing to have a session with the immediate project team before introducing other departments and end customers. The important thing is to create an environment where people can be frank about the issues. If people are afraid to own up to mistakes, there is little opportunity to learn from them. Of course, make sure that the project team and the project stakeholders are available to contribute to these.

Velopi has put these points into a checklist and will send this onto any project manager who is interested. Simply contact us by e-mail and we will send one straight back to you.