Project Closure & Lessons Learned

Last week, we put an open call out to the #PMChat community for contributions to either guest blog, join the Pre-Game Show, submit topic ideas or all of the above.  Rob and I are excited to announce that Michael Greer will be joining us this Friday on the #PMChat Pre-Game Show to discuss this week’s topic, Project Closure and Lessons Learned.  We are also grateful that Michael has provided the following blog as pre-cursor to this week’s #PMChat acitivity.  We know you will enjoy this….

 

Project Closure & Lessons Learned (Adapted from The Project Management Minimalist, 2nd Edition, © copyright 2011, Michael Greer)

 

Projects, by definition, are temporary endeavors. They must eventually come to an end. So they are necessarily limited in the time and effort that can be consumed, as well as the resources that can be used. For this reason, one of the most important things (possibly the single most important thing) that a project manager can do is to drive the project toward completion. But how do you know when the project is completed?

 

Project completion, at minimum, depends on two key activities:

  • Formal close out of phases (as indicated by written approval, or sign-off, of the sponsor and/or official hand-off of deliverables as they are evolving in increments)
  • Formal close out of the entire project (as indicated by written approval, or sign-off, of the sponsor and/or official hand-off of finished deliverables) 

 

In addition, depending on your project, close out activities could involve several other important chores such as:

  • Closing out vendor contracts
  • Creating a project archive containing all project documentation
  • Conducting a project “post mortem” and determining lessons learned
  • Formally handing off project deliverables to end users
  • Conducting training sessions to teach end users how to get the most out of the deliverables your project team has created
  • Writing performance evaluations or letters of thanks for team members to place in their personnel files (and to help assure they want to work with you again!)

 

 

Results

In a nutshell, here are the results you need to achieve:

  • Sponsor sign-off and approval of incrementally-evolving project deliverables and phases as they are completed
  • Sponsor sign-off and approval of all finished project deliverables and the overall completed project
  • Completion of any of the project-specific follow-up activities named above (Project Archive, Post Mortem, Lessons Learned, hand-off/training, performance evaluations, etc.)

 

Process

Successful project closure requires that you be thorough and systematic. It’s not all that complicated, but you do need to make sure you dot all the “I”s and cross all the “T”s! In general, you should follow these steps:

  1. Review your Project Scope Statement, your WBS or list of deliverables, and any Scope Change Orders that were approved during the project and determine whether everything has been completed and approved. (If there are any items not completed, discuss with your stakeholders and sponsor how you will deal with these.)
  2. Conduct any formal evaluations or acceptance tests and create reports of the results.
  3. Close out vendor contracts and make sure all related paperwork (formal approval of work products, tax info, etc.) has been submitted.
  4. Submit any internal paperwork indicating the close of the project.
  5. Assemble all relevant project documentation into a Project Archive (binder or disk-based)
  6. Hand off deliverables to the sponsor and/or end users, providing any training or special instructions for use.
  7. Conduct a Project “Post Mortem” and create a list of Lessons Learned. This typically involves these sub-steps:
    1. Create a list of questions you’d like your project team, stakeholders, or other key project players to answer. (It’s okay to cut & paste or use boilerplate stuff here… just be sure to edit carefully to assure the questions make sense in the context of your project.)
    2. Decide on a strategy for getting feedback. (Face-to-face meeting, email only, etc.)
    3. Present your questions & collect your answers.
    4. Summarize results, creating a list of “Lessons Learned.” (Optional: Work as a team to do this, possibly circulating several iterations of the document.)
    5. Archive the Lessons Learned and make them available to help in planning future projects. (Optional: Present these formally to project planners throughout your organization to help improve overall PM “IQ.”)
    6. For more suggestions for managing your Post Mortem discussion & sample questions, see Project “Post Mortem” Review Questions, below – or at this URL: http://michaelgreer.biz/?p=161
  8. Obtain formal approval, in the form of a written sign-off, for the entire project.
    1. Meaningful project approval typically includes:
      1. Specific name of each deliverable approved
      2. List of exceptions (deliverables not approved) and agreed-upon follow up actions to handle these
      3. Acknowledgement that any “loose ends” or unnamed changes will require more money, resources, and/or time
      4. Written signature on all the above of person authorized to approve
    2. See Sample Project Sign-off Form, below. – or at this URL: http://michaelgreer.biz/greers-sample-project-sign-off-form.pdf
  9. Find out from all stakeholders, particularly core team members, what kinds of documentation they would like to have created that formally recognizes their work on the project. (This might include formal performance review input for their personnel files, Thank You letters, etc.) Then create this documentation for each project team member.

 

Conclusion: Quick & Dirty Project Closure Is a Rookie Mistake

 

Toward the end of a project or project phase people often become weary and eager to “get it over with.” It’s tempting for those who created the deliverables or provided the services to simply hand them over and leave. What’s more, many of the professionals who make up the project team have already booked their next project and have begun work elsewhere.

 

For all these reasons, new project managers sometimes make the mistake of whizzing through this final project effort in a “quick and dirty” fashion. Seasoned veterans, however, have learned to fight that urge. They’ve learned from painful experience that any loose ends that are ignored here can come back to haunt them weeks, months, or even years down the road. And then, after the project details have faded into a dim and distant memory, it’s almost impossible to reconstruct exactly what happened or find that lost piece of documentation.

 

Since projects nearly always involve a legal obligation (a contract of some sort and a written proposal), it’s essential that formal close-out procedures be followed carefully.

So take the time to do it right. As the project manager you need to make sure that everyone delivers what they promised and that the sponsor formally approves the results. In this way, you can be sure that your project is really complete and there are no loose ends for you to tie up after everyone else has moved on.

 

 

Worksheet: Sign-Off Form [For a Project Phase]

Project Name: XYZ System Upgrade

 

I have reviewed the following deliverables as of the date identified below:

 

  •  
  •  
  •  

 

I have found these deliverables to meet with my approval, with the following exceptions:

  •  
  •  
  •  

 

I hereby give my approval to proceed with the evolution of these deliverables to the next stage of development in order to meet the project objectives in a timely fashion.

 

I understand that any changes (additions, deletions, or modifications) to the fundamental structure, underlying design, or the specific features of these deliverables might result in:

  • Slippage of the completion date for these deliverables
  • Additional resource requirements
  • Additional costs

 [Signature]:

John Doe, V.P., Corporate Cosmic Vision

(Date:)

[This tool is  from The Project Manager’s Partner, 2nd Edition, © Copyright 2001, Michael Greer/HRD Press]

 

 

Worksheet: Project Sign-Off Form [For an Entire Project]

 

Project Name: XYZ System Upgrade

 

I have reviewed the following finished deliverables as of the date identified below:

  •  [insert names of specific deliverables to be approved here]
  •  
  •  

 

I have found these finished deliverables to meet with my approval, with the following exceptions:

  • [insert names of specific deliverables that are not approved here]
  •  
  •  

For each of the deliverables that are named above as exceptions, we will proceed as follows with the following remedies within the time frames specified:

 

  • [Describe remedies to be taken to correct the deliverables and deadlines for achieving the remedies.]
  •  
  •  

 

[Signature]:

John Doe, V.P.
Corporate Cosmic Vision

(Date:)

[This tool is  from The Project Manager’s Partner, 2nd Edition, © Copyright 2001, Michael Greer/HRD Press]

Project “Post Mortem” Review Questions

It’s important for project managers and team members to take stock at the end of a project and develop a list of lessons learned so that they don’t repeat their mistakes in the next project. Typically such reviews are called post-project reviews or “post mortems.”

 

We recommend a two-step process for conducting these reviews:

  • First, prepare and circulate a whole bunch of specific questions about the project and give team members time to think about them and prepare their responses individually.
  • Next, hold a meeting and discuss the team’s responses to the questions. The result of this discussion is often a list of “Lessons Learned.”

The benefit of the first step, done individually by team members, is that it allows the quieter, more analytical people to develop their responses to the questions without being interrupted by the more outgoing, vocal people who might otherwise dominate in the face-to-face meeting. Also, it allows everyone the time to create more thoughtful responses.

 

So what would be on the list of questions? We’ve provided some of our favorites below…

 

General Questions

1. Are you proud of our finished deliverables (project work products)? If yes, what’s so good about them? If no, what’s wrong with them?

2. What was the single most frustrating part of our project?

3. How would you do things differently next time to avoid this frustration?

4. What was the most gratifying or professionally satisfying part of the project?

5. Which of our methods or processes worked particularly well?

6. Which of our methods or processes were difficult or frustrating to use?

7. If you could wave a magic wand and change anything about the project, what would you change?

8. Did our stakeholders, senior managers, customers, and sponsor(s) participate effectively? If not, how could we improve their participation?

 

Phase-Specific Questions
(These will differ from project to project, depending on the project’s life cycle/phases. The phases identified below are fully explained in the discussion of our Generic Project Life Cycle from Part I of The Project Manager’s Partner, 2nd Edition.)

 

Phase I: Determine Need and Feasibility

1. Did our needs/market analysis or feasibility study identify all the project deliverables that we eventually had to build? If not, what did we miss and how can we be sure our future analyses don’t miss such items?

2. Did our needs/market analysis or feasibility study identify unnecessary deliverables? If so, how can we be sure our future analyses don’t make this mistake?

3. How could we have improved our need-feasibility or analysis phase?

Phase II: Create Project Plan

1. How accurate were our original estimates of the size and effort of our project? What did we over or under estimate? (Consider deliverables, work effort, materials required, etc.)

2. How could we have improved our estimate of size and effort so that it was more accurate?

3. Did we have the right people assigned to all project roles? (Consider subject matter expertise, technical contributions, management, review and approval, and other key roles) If no, how can we make sure that we get the right people next time?

4. Describe any early warning signs of problems that occurred later in the project? How should we have reacted to these signs? How can we be sure to notice these early warning signs next time?

5. Could we have completed this project without one or more of our vendors/contractors? If so, how?

6. Were our constraints, limitations, and requirements made clear to all vendors/contractors from the beginning? If not, how could we have improved our RFP or statement of need?

7. Were there any difficulties negotiating the vendor contract? How could these have been avoided?

8. Were there any difficulties setting up vendor paperwork (purchase orders, contracts, etc.) or getting the vendor started? How could these have been avoided?

9. List team members or stakeholders who were missing from the kickoff meeting or who were not involved early enough in our project. How can we avoid these oversights in the future?

10. Were all team/stakeholder roles and responsibilities clearly delineated and communicated? If not, how could we have improved these?

11. Were the deliverables specifications, milestones, and specific schedule elements/dates clearly communicated? If not, how could we improve this?

Phase III: Create Specifications for Deliverables

1. Were you proud of our blueprints or other detailed design specifications? If not, how could we have improved these?

2. Did all the important project players have creative input into the creation of the design specifications? If not, who were we missing and how can we assure their involvement next time?

3. Did those who reviewed the design specifications provide timely and meaningful input? If not, how could we have improved their involvement and the quality of their contributions?

4. How could we have improved our work process for creating deliverables specifications?

[Insert your own, deliverables-specific questions here.]

Phase IV: Create Deliverables

1. Were you proud of our deliverables? If not, how could we have improved these?

2. Did all the important project players have creative input into the creation of the deliverables? If not, who were we missing and how can we assure their involvement next time?

3. Did those who reviewed the deliverables provide timely and meaningful input? If not, how could we have improved their involvement and the quality of their contributions?

4. How could we have improved our work process for creating deliverables?

[Insert your own, deliverables-specific questions here.]

Phase V: Test and Implement Deliverables

1. Were the members of our test audience truly representative of our target audience? If not, how could we assure better representation in the future?

2. Did the test facilities, equipment, materials, and support people help to make the test an accurate representation of how the deliverables will be used in the “real world?” If not, how could we have improved on these items?

3. Did we get timely, high-quality feedback about how we might improve our deliverables? If not, how could we get better feedabck in the future?

4. Was our implementation strategy accurate and effective? How could we improve this strategy?

5. Did our hand-off of deliverables to the user/customer/sponsor represent a smooth and easy transition? If not, how could we have improved this process?

[Insert your own, deliverables-specific questions here.]

 

[This tool is  from The Project Manager’s Partner, 2nd Edition, © Copyright 2001, Michael Greer/HRD Press]

 

 

Michael Greer is a Project Management (PM) author and trainer whose mission is to help new project managers become more effective. Through books, workshops, and public speaking appearances, seeks to demystify the field of project management (PM) and make it accessible to newcomers. Spent many years as an instructional designer developing custom training and performance support solutions for all sorts of clients and content areas (sales, mgt, technical). 
* Michael Greer’s Project Mgt. Resources
* Inspired Project Teams (blog)
* Facebook Page

     


<script type="text/javascript"><!– google_ad_client = "ca-pub-8334046383696150"; /* PMChat Header */ google_ad_slot = "8203916761"; //–> </script> <script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script>

No comments

Trackbacks/Pingbacks

  1. Project Closure & Lessons Learned « Sumu’s Web Link Collection – […] Project Closure & Lessons Learned Share this:TwitterFacebookLike this:LikeBe the first to like this post.   Leave …