Dina Garfinkel PMPProject Manager| Horn Group IncNew York, Ny, United States
Does anyone have a good template for a project closeout meeting to be held with the client? We have been holding our own internal closeout meetings and using a decent template (which I think we found here), but I wanted to know if anyone has suggestions for specific things to bring up with the client closeout meeting that might not come up with the internal closeout meeting.
This is the first closeout meeting we're holding with our client, so we want to make sure to be as prepared as possible. I was planning on bringing a copy of the notes from the internal closeout meeting and reviewing those, and then posing the same questions from the internal meeting to our client. Those questions are essentially:
- what went well
- what did not go well, what needs improvement
- what lessons did we learn
Anyway, I'd love some input from anyone who has more experience in this area. Thanks!
-dina garfinkel Saving Changes...
Sort By:
Hans RobbersSenior Director| SalesforceVlissingen, Netherlands
Dina
I think it is a good idea to ask the same questiosn as you used during your internal meeting. It will allow you to see if the view of the project team and the customer are/were aligned. I am not sure if I would take the notes of the internal meeting with me before you know you are discussing the differences instead of hearing what the customer is saying.
Furthermore I would adress the following, most liely already embedded in your questions:
- Did the project deliver on time?
What is the perception of the customer on this topic?
_ Your project charter defined a number of objectives. Did you meet the objectives set in the project charter? The customer will measure against theobjectives to determine if the project was a success unless the sponsor has changed.
- Finally during the project you must have picked the preferences of your customer during the steerco's and 1-2-1 meetings. What does she/he consider important, e.g. budget, scope, quality, timely delivery, stabilility and predictability of the apps, , communication, expectation management etc. Based on these observations I would also formulate a number of questions.
We require a few documents to ensure that all was delivered...
1. Project Lessons Learned. The purpose is self explanatory. Depending on the project’s size, we update the document using one of the below or a combination:
a. Questionnaires
b. Meetings that can be facilitated
The lessons learned cover “What Went Well?”, “What Didn’t Go As Planned”, “What Needs Improvement?”, and “Recommendations” for all the project’s phases. Because people do not stay in the project team until the very end of the project, but they are released as soon as their contributions are accepted, we are collecting their feedback and evaluating it during the lessons learned sessions.
Lessons learned are collected from the sponsor and critical stakeholders too.
2. Project closure document. The purpose is to formalize the acceptance of all projects artifacts as well as the completion of all administrative activities (financial records closed, all invoices paid, all team evaluations sent, all outstanding issues closed). The document lists:
a. The planned deliverables, indicating what was approved in the change management sessions vs. what was in the original scope. For each deliverables it is stated if it was met completely (sometime it does happen that the change board approves a partial delivery or cancels a deliverable).
b. The original timeline and the actual dates for the milestones
c. Location of all the project’s artifacts and documents.
The document lists all the supporting documentation and its location. It is a good idea to have an execution phase exit checklist that can be one of the supporting documents for the project closure document.
This is a document that requires sign-off at least from the sponsor and the PM.
Sorin
...
1 reply by Rachel Miller-Bradshaw
May 20, 2020 5:39 PM
Rachel Miller-Bradshaw
...
Hello Sorin,
Although this thread is over a decade ago I do appreciate the info you provided. I used this info in a meeting today and will help in shaping the post mortem process I am apart of developing.
Saving Changes...
David MorganProject Manager| Experian PLCGrantham, United Kingdom
If any of the 'lessons learned' differ from the customers perspective to the internal teams, things can get tricky in terms of representing these on the closure document.
I have found that by asking the regular questions (What went well, What could be improved etc) but stating up-front that the lessons learned section will not focus on individual issues but rather will act as a set of recommendations for future similar projects, and the questions asked will feed into these recommendations - can often diffuse any silly arguments and avoid putting peoples noses out of joint.
But every situation is different I guess! Saving Changes...
I liked Sorin's answer -- first, confirm that the client agrees that the project is done and that everything is delivered.
I have seen some PMs try to launch into a lessons learned exercise before the client agreed that the project is done. It lead to nasty arguments and disagreements between the PM and the client. If the client feels that you are trying to shut down the project prematurely, you need to address that issue first.
I have also had some clients that have no interest in lessons learned. If you are a contractor, then it is their right to just hire you, get the work done, and walk away. I encourage anyone who has a long-term relationship with me to provide some lessons learned, but I never walk into a client meeting assuming that they will share that information with me. Obviously this issue will depend on your situation. I worked in many environments where lessons learned were not collected.
All the suggestions below for gathering lessons learned are excellent ones. Once you have agreement that the project is closed, you can launch into the lessons learned.
I have also sometimes done a lessons learned meeting before the very end of a project. I have a meeting to just discuss what could have been done better. You might find the client more willing to open up and talk if you separate the two meetings. A "closure" meeting is a high-pressure meeting, and may involve some final negotiations. A client might not want to share lessons learned immediately after finishing a negotiation with you. Giving them time to resolve the negotiations first and then asking, "Can we meet again to talk about how to improve?" might result in a better meeting.
Many of these suggestions depend on your relationship with your client, the formality of the project close, and the overall atmosphere on your project. It is tough to give definitive answers! Saving Changes...
Linda HillProgram Manager| MicrosoftRenton, Wa, United States
I know this is an old thread and am wondering if anyone has developed a Project Closeout template that would be available. Saving Changes...
There is actually quite a bit more in Project Headway. Here's one of the key Prepare Completion Report Subtasks
Task 040 - Summarize Project Results
Description
After the project is complete, you may wish to go through a post implementation review (PIR) or post mortem exercise. It is a learning opportunity to review the outcomes of the project. A PIR is different than the lessons learned exercise as it captures the scope of the project in its entirety, not merely its successes and failures. A proper PIR will cover some of the following areas:
Project overview
Intended outcomes of the project
Attained results
Project performance
Success & challenges
Recommendations for future projects
Include members of the project team, project sponsor, steering committee, customer and other key stakeholders in the review to make sure it is complete.
Tips and Tricks
When summarizing the results of the project, keep the following in mind:
Template. As with many project documents, use a formal template for this exercise. It makes it easier to prepare and easier for readers to understand the contents.
Be brief. At this stage of the project, be as brief as possible. If people are looking for more information, you have extensive project files that they can delve into.
Be organized. Regardless of the format you choose, ensure it is organized, easy to read and makes sense.
Questions
When trying to summarize the project results, consider the following questions:
Who should be involved in the post implementation review exercise?
Does your sponsor approve of conducting a Post Implementation Review (PIR)?
What is the intent of the PIR?
What do you or the organization hope to achieve?
Have you reviewed the business case?
Do you have the necessary metrics in place to conduct a PIR?
Has enough time passed from the end of the project until now to adequately determine the level of success of the project?
How will the results from this exercise be communicated?
Ask your project sponsor or your key project team members the same questions.
We require a few documents to ensure that all was delivered...
1. Project Lessons Learned. The purpose is self explanatory. Depending on the project’s size, we update the document using one of the below or a combination:
a. Questionnaires
b. Meetings that can be facilitated
The lessons learned cover “What Went Well?”, “What Didn’t Go As Planned”, “What Needs Improvement?”, and “Recommendations” for all the project’s phases. Because people do not stay in the project team until the very end of the project, but they are released as soon as their contributions are accepted, we are collecting their feedback and evaluating it during the lessons learned sessions.
Lessons learned are collected from the sponsor and critical stakeholders too.
2. Project closure document. The purpose is to formalize the acceptance of all projects artifacts as well as the completion of all administrative activities (financial records closed, all invoices paid, all team evaluations sent, all outstanding issues closed). The document lists:
a. The planned deliverables, indicating what was approved in the change management sessions vs. what was in the original scope. For each deliverables it is stated if it was met completely (sometime it does happen that the change board approves a partial delivery or cancels a deliverable).
b. The original timeline and the actual dates for the milestones
c. Location of all the project’s artifacts and documents.
The document lists all the supporting documentation and its location. It is a good idea to have an execution phase exit checklist that can be one of the supporting documents for the project closure document.
This is a document that requires sign-off at least from the sponsor and the PM.
Sorin
Hello Sorin,
Although this thread is over a decade ago I do appreciate the info you provided. I used this info in a meeting today and will help in shaping the post mortem process I am apart of developing. Saving Changes...
PMI Team Member
