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 – Updating Schedule Progress

It always amazes me that after project managers put so much time and effort into creating a baseline project schedule, they do not always put the same level of energy and discipline into maintaining it during the execution phase of the project. It is extremely important during this phase of the project that the schedule reflects where you are at currently, as well as how the remaining work is planned to be completed.

During the transition from planning to execution the project manager establishes the progress update processes. These processes are both formal (e.g., submitting updates through a tool) and informal (e.g., soliciting input in one-on-one meetings). A productive project manager will ensure that these update processes are linked to other project related activities, such as time reporting, team meetings, and status reporting.

Progress Update Processes

The progress update processes and tools should fit into the way the team works. Try to avoid implementing processes that are disruptive or redundant. You do not want these processes to end up getting in the way of actual work being completed. In addition, these processes should be timely and consistent. The updates should be completed the same time/date during the reporting period (day/week). Team members should KNOW when information is due and when the schedule updates have been completed.

Based upon the organization and work environment, the project manager either establishes formal or informal processes and tools to collect progress updates. These processes and tools can range from weekly conversations with team members, to utilization of a tool for each team member to submit updates.

The key to this process is that it is linked to other project update activities (timeliness of information is dependent update establishing efficient processes):

  • Time reporting – Usually time reporting is at a higher level than required to update schedule activities, but at a minimum this process can be leveraged to trigger schedule update discussions.
  • Team meetings – Information shared at team meetings should be direct inputs for schedule updates (particularly on smaller projects).
  • Status reporting – It is up to the project manager to ensure that the status report is completed after schedule updates have been completed.

Performing Schedule Analysis

After completing progress updates to the schedule, it is a best practice to review the schedule data in a manner that proactively identifies potential issues. This review is utilized to identify areas where additional information and/or adjustments are required.

I will generally utilize the MS Project feature AUTO-FILTER feature to highlight potential project related issues. The approach helps focus in on specific problem areas:

  • Tasks that are NOT completed
  • Tasks that should have been started or finished already (past due), OR tasks that are scheduled to start or finish in the upcoming 1-2 weeks
  • Task assignments for specific resources (identification of resources that may be over or under allocated in the current time period

As the project manager you should be asking yourself the following questions when reviewing schedule related information:

Why are tasks past due? Most likely you will have run across the answer to this question when gathering progress updates from team members. If not, this is a good opportunity to follow-up with team members on the status of specific tasks. The answer generally falls into one of the following categories:

  • The task is taking longer than expected
  • Other tasks took higher priority
  • I could not start the task because I need another task to be completed first

Are actions required? Based upon review of past due tasks, as well as other tasks scheduled for the upcoming 1-2 weeks, you may identify problem areas that require immediate action. This is particularly true if delays (or anticipated delays) in the tasks will impact an upcoming milestone (or the project end date). Based upon discussions with the team, you may decide that one of the following actions must be taken:

  • Change resource assignments
  • Add a risk and initiate mitigation action planning
  • Change task dependencies to reflect new task sequencing
  • Add a task to reflect new work

Are schedule adjustments required? Some follow-up actions drive additional updates to the schedule. The bottom-line is that if the schedule no longer reflects how work will be performed, you should likely make additional updates to the schedule.

Making the Right Adjustments

Based upon completion of on-going schedule analysis, including follow-up research and discussion with team members, you will often identify adjustments that need to be made to one of the planning artifacts (schedule, issue / risk log, project management plan). The following represent considerations when making common adjustments to the schedule:

Resource assignments: Resource assignments may be proactive resource changes to avoid future problems, or reactive changes to respond to slippage in the project schedule. If material in nature, the resource changes should be made in the schedule. After the changes are completed, the project manager should review the resource usage to ensure that the changes solved the resource utilization issues as anticipated.

Duration / work estimates: When material differences in work effort or duration are identified (plan vs. actual progress), you should consider reflecting the difference in the schedule (particularly when there is significant work or time remaining to complete the task).

Tasks & dependencies: As work gets underway, additional tasks or task dependencies are identified that are required to complete the deliverable. These generally represent clarification of the work to be performed (vs. change in the deliverable to be completed). Again, if these changes are material in nature, and have not already been completed, you should consider reflecting these changes in the schedule.

Risks & issues: Review of the schedule based upon completing progress updates will often result in identification of additional risks or issues. This is the appropriate time to capture these risks/issues, and plan the appropriate actions to close or mitigate the risk/issue.

Project impacts: There is often a question around initiating project impacts based upon schedule changes identified. This topic is discussed further in my blog post on Managing Change, but the following represent the guidelines as to whether or not a project impact should be initiated:

  • Does this change have a material impact on the scope, schedule (end date), or cost of the project?
  • Is this a permanent change (or just a timing issue that will be resolved at some future point in the project)?

Updating Schedule Progress Best Practices

In summary, the following represent the primary best practices relating to updating schedule progress:

  • Establish a timely process (and supporting tools) to update schedule progress. The team should be well aware of how and when schedule updates will be captured, and when the schedule updates will be accurately reflected in the project schedule (to ensure team members are looking at the most current information).
  • Ensure that the processes for updating schedule progress are efficient for the project manager, as well as the rest of the team. Where appropriate, leverage existing communication vehicles or tools to capture this information (e.g., team meetings, timesheets, and personal status reports).
  • The process of updating schedule progress should regularly trigger the project manager to review the schedule to identify current or potential problems, and initiate the appropriate corrective actions.

Using SharePoint to Measure the Impact of Change (KPI)

As I discussed in my blog post on Managing Change, it is important to understand the cumulative impact of changes on a project with regards to the scope, schedule, and cost/budget. Throughout the life of a project, there will be changes. The project manager should be able to explain the evolution of the plan from the original baseline to the current baseline, including all approved changes that have been implemented.

Effective use of the change control log (see my blog post on Using SharePoint to Manage Change Requests) provides a tool to track and reconcile changes to the baseline schedule and budget. In addition, use of the Project Status list enables use of SharePoint 2010 Key Performance Indicators to measure and communicate the project team’s ability to manage change at any point in time throughout the project life cycle. In order for the project sponsor and steering committee to make good decisions when approving change requests, they should understand the impact of the changes they have already approved. In addition, project change is one of the key metrics utilized to assess project performance in the project closure process (and identify and implement project improvement opportunities for future product releases / projects).

Creating the Approved Change Request view in the SharePoint list

The first step to establishing the project change metrics in SharePoint is to ensure that you have the appropriate view set-up to support the computation of the metric. The cumulative impact of change on the project represents the total impact of the approved change requests (approved and implemented status) on the project schedule and budget. To support this metric, I create a view in the change request list that is filtered to include only approved and implemented change requests (sample of this list view below).

The screen shot below from the Change Request list view settings illustrates the filters utilized to limit the list to only approved and implemented change requests.

In addition, totals are added to the list view to the Approved Change Request list view to display the sum of the schedule impact (days) and budget impact (dollars). I also added a count of the change requests so you can get a quick feel for the number of change requests that are driving the total change impact. The screen shot below from the Change Request list view settings illustrates setting up the totals that are displayed at the top of the list view.

Creating the Schedule Impact Metric

To create the Schedule Impact metric, select NEW indicator from the Project Status list. Within the indicator set-up, you are prompted for a name of the metric, a brief description of the metric, and comments (I use comments to describe the specifics of the source/calculation). In addition, you are prompted to select the list, and list view (described above) where the change request data is maintained. The screen shot below illustrates the first part of the indicator set-up process.

Then you are prompted to define the schedule impact metric:

  • The metric is calculated using the “Sum” of the “Sched Impact” field in the Approved Change Requests list view.
  • The “lower” the metric value is better.
  • The metric is GREEN when the total schedule impact is X days or lower (in this example I used 10 days)
  • The metric is YELLOW when the total schedule impact is Y days and greater that X days (in this example I used between 11 and 20 days)
  • The metric is RED when the total schedule impact is greater than 20 days.

The screen shot bellow illustrates the definition of the schedule impact metric.

Based upon the information set-up for the Change Request Schedule Impact metric, the screen below illustrates the details displayed for this metric. The biggest challenge is setting up consistent criteria from project to project that effectively defines GREEN/YELLOW/RED for the cumulative schedule impact.

Creating the Cost Impact Metric

The same process is utilized (as described for the Schedule Impact metric) to create the NEW indicator, describe the Cost Impact metric, and select the list/view where the change request data is maintained.

Then you are prompted to define the metric:

  • The metric is calculated using the “Sum” of the “Cost Impact” field in the Approved Change Requests list view.
  • The “lower” the metric value is better.
  • The metric is GREEN when the total cost impact is X dollars ($) or lower (in this example I used $10,000)
  • The metric is YELLOW when the total cost impact is Y dollars and greater that X dollars (in this example I used between $10,000-$25,000)
  • The metric is RED when the total cost impact is greater than $25,000.

The screen shot bellow illustrates the definition of the Cost Impact metric.

Based upon the information set-up for the Change Request Cost Impact metric, the screen below illustrates the details displayed for this metric. Generally the definition of GREEN/YELLOW/RED for this metric is documented within the Cost Management Approach of the Project Management Plan.

%d bloggers like this: