You as a project manager have successfully completed a project and are already into the next project where the project charter has been signed and you have been appointed as the project manager. The project is authorised to kick off. Meetings with stakeholders have begun. The existing team has been released and already assigned to new projects… some are part of this new project. You are looking forward towards this new project.
As the project is in the initiation and a bit of planning has already begun, you realise that the experiences from the previous project would be very useful. So much so that the tailored processes and tools of your previous project would do much good and you already have an edge over the situation.
But you don’t have all the documents with you ready. You look into the project archives and realise some are not even documented. And there, you find similar problems related to stakeholder analysis, communication, resource allocation where the team is burning its fingers, only because you did not have lessons learned documented.
To top it all, the customer of your previous project is calling you back and again to resolve teething problems. Your previous project has started torturing you like a haunted nightmare.
This is a general situation with well, almost any project manager. What was missing in this situation was handling the project closure in the right perspective. There are certain basic and key steps to take while closing a project as iterated in the PMBOK 4th edition. Here we re-look at those tips.
1) Obtain acceptance by the customer or sponsor on the completion of the project. Also, ensure that the project is handed over to the customer or to the operations team. One needs to make sure that the operations team understand the project well and can manage to resolve the technical and functional problems. If necessary, do a proper knowledge transfer and probably do a parallel maintenance for atleast a short duration till the operations team feels hands on. Ensure proper training to the customer as to how to use the product or service delivered as an end rsult to the project. Provide approrpiate communication and escalation matrix to the customer in case they want to resolve any problems they encounter while using the product or service.
2) Conduct post – project review. This should not be used as a blame game but an honest feedback and reviews of all that has been delivered. If necessary, involve all stakeholders such as customers, operations and maintenance team, your own project team and document what has been delivered and where all future improvisations is necessary either through future enhancements or maintenance.
3) Record impacts of tailoring to any process. There are many changes that happen to processes applied in a particular project scenario, since each project is unique. Still, there are various similar situations in other projects where the impact of tailoring any process could be useful.
4) Document lessons learnt. This is of utmost importance and is almost neglected by most of the project managers during closure phase. Ensure that lessons learnt (both good and bad) are documented. This is actually the best time to let honest feedbacks creep in since everyone is either released or in the verge of getting released. The project manager should create an environment to let constructive criticism come in as feedback to help future projects to be implemented in a better way.
5) Apply appropriate updates to Organisational process assets. You update the cost related assumptions, the scope document formats help in better RTM, the assumptions in scheduling etc. How can other project managers in existing and future projects including your own self take advantage of the updates you did based on the latest market conditions or methodologies? This is why it is important to keep organisational process assets up to date. In fact, if the processes and document management in the organisation is being maintained well, this should not be a pain during the project closure. As a matter of fact, if the organisational process updates are not being done properly, this can be a lesson learnt documented during project closure and improved sincerely in future projects.
6) Archive all relevant project documents in the project management information system (PMIS) to be used as a historical data. First of all, ensure that there IS a PMIS, and then doubly ensure that it is maintained with all historical information. This will be useful not only for other project managers, but also by your own self when you move to other similar projects or different projects with similar situations/ environments.
You must be logged in to post a comment.