Closing, not completing!
There is a world of difference between closing a project and completing a project. It is quite possible to close a project even if it is not complete, i.e. you have not delivered everything you said you would but need to shut down the temporary project organisation.
Theoretically the project cannot be closed until you have delivered all of the agreed scope and that is the standard way of closing a project. However, the sponsor or customer may feel that getting their hands on 80% of what they want right now is better than waiting to get the total 100%.
The key to closing a project (whether or not it is actually complete) lies in getting agreement between you and your sponsor that he/she is happy with the outcome. You stand a better chance of getting this agreement if:
You have a clear definition describing what you were aiming at.
You have managed the sponsor’s expectations that maybe you will not be able to deliver everything by the delivery date, by focusing on the business benefits.
You have a simple process in place that has captured any outstanding issues (so you all know what is left over)
You have identified a way of dealing with the outstanding issues and agreed this with all concerned (the sponsor and any users or customers that might be disappointed by not getting all that they had hoped for)
If the sponsor can see that nothing has been lost and that you will be clearing up the odds and ends then he/she may agree to close the project.
The advantages of closing the project are as follows:
You have a clean start with any outstanding issues (new method of approach, maybe, to sort out the last few items).
You can review the project, and start to improve your project management performance.
And most importantly, the sponsor can start to use whatever it is that you have delivered and start to create some business benefit with it.
This final point may swing the argument with the sponsor.
Dealing with the outstanding issues
Of course, there are several ways of dealing with the outstanding issues:
Make them into a new small project, with a simple definition; maybe you will be the project manager, maybe not.
Clear them up piecemeal, under the heading of maintenance or operational work.
Just scrap them; don’t ever do them. It may be that, on reflection, the sponsor realises that the main business benefits have been achieved, and the extra work required to finish off the last few items is not really justified.
In all cases you must discuss the options with the sponsor, and reach agreement as to the way forward. It may be that a mixture of all of these strategies is required.
The project team members
Don’t just let your project team members drift back to their day jobs without some sort of acknowledgement of their contribution to your project. This may range from a full-blown party to something much simpler but even if you feel that such an event will be inappropriate or outside the corporate budget then at least say thankyou to each team member.
It is also worth thanking their line managers for allocating them to your project. Remember, you may need to ask again for help, and you can ease that process by making sure you acknowledge the efforts and contributions this time.
Some line managers may place a high value on having their team member assigned to your project. Maybe the team member will pick up new skills or knowledge that will be useful to the line manager. So at the end of the project ask each team member to document a ‘record of achievement’ for themselves.
This is a simple list of:
- Their duties on the project, and how well they performed them.
- Any new skills or knowledge they have picked up whilst working on the project.
- Any formal training they may have received on the project.
- Any training needs that have emerged as a result of working on the project.
Ask the team member to talk it through with you. Endorse the record, and send the team member back with something of value to themselves and to their line manager. This little job will not cost you very much personally, but might just help when you go to the line manager for help with your next project.
The final documentation
It is really important to get some written evidence that your sponsor and/or customer are satisfied with your project outcome. This is not just for your own personal glow of achievement (although you should revel in this while it lasts) but this final acceptance closes the file on what we all hope has been a successful project.
If some of the work has been undertaken by resources outside your company then you need to get a written acceptance form someone internally to say that they are happy with your contracted resource’s performance.
The sponsor should also share in this feeling of achievement (after all, your project may have been risky for the sponsor), so make sure that he/she knows that the project is closed, and ask for a signature on the project definition form.
Too many projects drag on because we get confused between closure and completion. It is much better to close a project and then start another clearly defined activity to tidy up than to let the project run on, seemingly forever.
A signed-off project definition closes the project life cycle, and is an achievement worth celebrating.
Capture all sign-offs and file them
For all deliverables where someone has accepted the quality of the output
Agree on a process for dealing with outstanding issues
Balance business benefits now against a ‘perfect’ project result in the future.
Document and agree the team members’ performance
Send each person back to their line manager with a record of their achievement on your project.
Close the files
Store the project files in a central library of useful information, to make future projects easier to run.
And tell other people about it.
Thanks to Mike Watson of Obsideo for providing this book