PM Foundations – Project Closure Feedback Survey

When project managers discuss project closure, the primary best practice that they focus on is the lessons learned process. Although I agree that lessons learned represents an integral best practice area performed during project closure, I do not believe it represents the “only” best practice for gathering stakeholder feedback. The project closure feedback survey represents a “safe” vehicle for project stakeholders to provide thoughtful input. People that may not speak up during a lessons learned discussion are more likely to provide valuable feedback on a project closure survey. The project closure feedback also provides the ability to capture project closure metrics (in addition to “free form” comments and ideas). In addition, performing the project closure feedback survey process provides the ability to bring a little more structure to the lessons learned session. Rather than starting from a “blank sheet of paper”, the lessons learned discussion can be organized around the major themes / observations captured in the project closure feedback survey.

Survey Content

The project closure feedback survey should be focused on gathering input from the stakeholders in two areas:

  • Does the product delivered meet the stakeholder’s expectations?
  • Did the processes associated with completing the project work meet the stakeholder’s expectations?

The following represent key topics covered within the survey:

  • Business results – Has the project/product enabled the anticipated business results/benefits?
  • Expectation / requirements – Were the expectations and requirements of the project / product well defined and understood on the project team? Were the requirements effectively implemented? Were the expectations met?
  • Communications – Was communications about the project effective and timely? Were the appropriate communications vehicles utilized? Did communications include the appropriate content?
  • Project Execution – How effective were the process and tools to complete project work? Were the appropriate plans in place to properly guide the project team throughout the project life cycle?
  • Overall – Overall rating of the success of the project (both what was delivered, and how it was delivered).
  • Comments – Blank area for stakeholders to provide feedback about things that were done well on the project, and areas for improvement.

Below is the project closure survey that I frequently utilize to capture feedback from stakeholders.

This sample survey highlights some of the best practices associated with capturing feedback about the project:

  • The survey should include a limited number of questions. If there are too many questions, people will not take the time to complete it.
  • Provide space for comments after each question. This encourages people to provide explanations for their score (particularly for high or low scores).
  • At the end of the survey provide an area to capture general comments. What are the things done well? What are the areas for improvement? These comments often help to identify “themes” for the lessons learned discussions.

Survey Distribution

Feedback should be solicited from key project stakeholders:

  • People that participated in completing the project deliverables (anyone whose name is on the project schedule). You need to decide if the person’s role is significant enough for them to have feedback about the project (error on the side of being inclusive).
  • People that participated in oversight of the project (steering committee, project sponsors)
  • People that provided input from the business areas that are impacted by the project (key end-users or subject matter experts).

If you think feedback may vary based upon the groups completing the survey, you may want to capture some demographics related information (e.g., business vs. IT, management vs. team member). The demographic information is especially relevant if you think it may influence the follow-up actions (e.g., end-users are not happy with the product delivered, IT feels the scope was constantly changing).

Collaboration tools such as SharePoint provide the capability to conduct the survey within the team’s project site. There are also other survey tools that may be available at a client. The easier it is for the stakeholder to open and complete the survey, the more likely they will take the time to do it. Do not underestimate this fact.

Summarizing Survey Results

It is important to give the stakeholders a deadline to complete the survey, and then summarize and provide the results in a timely manner. The information provided in the survey is generally a good starting point for the lessons learned discussions. Therefore the survey deadline, publishing survey results, and scheduling the lessons learned session are best planned and communicated at the same time, when the project closeout process is initiated.

The following activities are included in the process of summarizing survey results:

  • Compute the survey metrics. What is the average score? What is the distribution/deviation from the average score (e.g., number of high or low scores)?
  • Summarize comments for the rating. Highlight/summarize the comments for questions that provide insights in terms of why people feel the way they did when providing the rating.
  • Using demographics to explain results. The demographics data may assist in providing insights around the results (e.g., IT was not happy with the way the work was estimated)?
  • Grouping Comments. You are looking for common themes about things that went well or could be improved. Grouping the comments into the common themes provides potential topics to launch discussions during the lessons learned session. Some guidelines on the defining the themes:

Will the theme be understood by the stakeholders (e.g., not too general)

Look for areas that you are likely to get consensus (not just one person’s opinion)

Is the theme likely to lead to something actionable (capitalizing on something done well, or implementation of improvement)

Stakeholder Feedback Best Practices

In my experience the following are the key best practices associated with capturing project closure feedback, and communicating survey results:

  • Solicit and communicate feedback in a timely manner – Try to complete the project closure feedback process before most people transition out of their role on the project. It is important that the project is “fresh in their minds” when they are providing feedback. In addition, do not wait too long after the survey is conducted to communicate the results.
  • Keep the survey simple – The survey must be easy to access, and not too time consuming to complete.
  • Target the right people – Make sure you distribute the survey to people that were involved enough in the project to provide valuable insights. However, error on the side of being inclusive in the survey process.
  • Does not need to be conducted just at the end of the project – You do not need to wait until the end of the project to capture feedback. It is often helpful to capture feedback at key milestones also. This gives you an opportunity to make “course corrections” for the next phase of the project.
  • Do something with the information captured – Make sure that the appropriate next steps are initiated after the survey is completed. The most common next step for this process is to set up the lessons learned session to elaborate on the feedback, and formalize the action items / assignments.

PM Foundations – Project Assumptions

You have probably heard the saying, “Be careful when you assume something. It will end up making an Ass of U and ME.” From a project management perspective, assumptions are your friend. Assumptions are things that you believe to be true which may not be true. Assumptions help you clarify the thought process behind project plans. They also make it possible to get beyond seemingly impenetrable roadblocks during the planning process. Every project has a certain number of unknowns. If we waited until everything was known, a project would never get started.

 

Examples of Assumptions

  • Benefits associated with the project – When building a business case, you often need to make assumptions about what impact (hopefully positive) the project will have after it is completed. You can gather information (e.g., time studies) to refine the assumptions, but there will still be unknowns until the new processes and systems are in place and fully operational.
  • The way things will work within the product – You do not know exactly how something is going to work until you start to define and build it. This means that during the planning process you probably need to make some assumptions about what “it” is. These assumptions will impact the planned effort and duration of the project.
  • Things you can leverage to develop the product – Often times you are not starting from scratch. There are assets from previous efforts that can be reused, but you may not know exactly to what extent. Another good example of when to create an assumption.
  • Resources you will use to build the product – The number and types of resources will definitely have an impact on the timing and quality of your efforts. At the time you are planning the project you may or may not have all the exact resources in place – this includes the partners that you may hire to help with the effort. The assumptions in this area also include things like: Do I need to include time and costs for training? Do I have the facilities and computers available to support these resources?
  • Dependencies and lead times – What needs to be completed to start working on specific activities? If you wait for all the answers to these questions, you will never complete the project schedule.
  • Cost of developing the product – You may not have all of the exact cost estimates, but you need a project budget. Again, you can gather information (e.g., costs from similar projects) to refine the assumptions, but you may still have some unknowns associated with the cost / pricing for specific components of the effort. Insert an assumption.

When do you make assumptions?

  • Developing the business case – As I mentioned in the examples, during project initiation, when you are developing the justification for the project, there will be a ton of unknowns and assumptions help construct the initial business case for the project.
  • Developing the project plan – Throughout the planning process (defining the product and project scope, creating the project schedule, and developing the project budget) there will be things you will not know until you get to that point in the project.
  • Managing change – As project changes occur you may not know the exact impact of the change on the project or product. This is a good example of why assumptions must be managed throughout the project life cycle.
  • Managing risks – Just by the very nature of a risk, assessing the probability or impact of a risk may require some assumptions (e.g., if this risk occurs it will delay the project by 2 weeks). Try and get your mind wrapped around that one – unknowns related to the unknowns.

Best practices associated with assumptions

  • Do not use assumptions to CYA – be specific, and you must believe them to be true – I hate it when I run across assumptions like: We have enough resources to complete the project. –or- The client will be available to approve the deliverables. These assumptions are either added because of a CYA mentality or because they are believed to be untrue. Assumptions need to be specific and manageable, and most importantly you need to believe they are true at the time you identify them – if not, they are just “noise” in your project plans
  • Make sure they are documented – When you identify an assumption, document it, either in the project management plan or in a separate list of assumptions that are maintained and managed. Some assumptions seem innocent enough, but I have had plenty of times when we have had to revisit the rationale behind the plan because we did not document the assumptions well enough.
  • Assumptions need to be managed throughout the project life cycle – On an on-going basis you need to review and test your assumptions, particularly the ones that are critical to your plan (scope, timing, or cost). Assumptions can be deleted from the list as work is completed and they are OBE (overcome by events).
  • Focus on the key assumptions – Over time you tend to accumulate a lot of assumptions. Make sure that you have established a mechanism to focus on the critical assumptions (based upon the timing of the project activities, and the nature of the assumption).
  • Assumption management is tied to the risk management process – As discussed above, managing assumptions is directly tied to managing risks because they both relate to unknowns. It is a best practice to perform a quick review of key assumptions at the same time you are updating the risks. Think of it in the same way as changing the batteries in your smoke detector when you change your clocks for daylight savings time.