PM-Foundations – That Will Leave a Mark

When working at clients the immediate goal is to meet or exceed the expectations of the engagement. As a project manager this is accomplished by effectively leading projects to successful project outcomes. While being recognized as a team for doing a good job is satisfying unto itself, the ultimate goal is to deliver and perform in a manner that leaves a lasting impression on the project management organization. This lasting impression is reflected in the consistency and effectiveness of the practices routinely used across projects, the ability to measure and report on project performance, and the quality and relevancy of project management processes and supporting project artifacts. In the context of managing projects, there are things you can do that to leave the project organization in a better place than when you arrived – leaving a mark that lives well beyond your time spent at the client.

5 Ways to Leave a Mark on the Project Office

Below are the 5 ways that I focus my energy and efforts during a project management engagement in an attempt to leave a lasting impression on the client’s Project Office/PM competency. Obviously, the level of impact/influence in some of these areas is highly dependent on the scope, length and visibility of your engagement.

1. Become Productive – Clients are often amazed at how quickly a project manager can ramp-up and productively contribute to a project. Quickly becoming productive on a project can be accomplished with limited or no domain knowledge associated with an industry, client, business process or technology. The time to ramp up on a project is largely dependent on the project manager’s experience / expertise, as well as their command of the core capabilities of a project manager. Effective project managers instinctively know how to approach a new project, and where to begin in terms of ramping up and starting to lead the team. Project offices that develop project managers that can ramp up and become productive quickly realize gains in time to market, as well as increase flexibility in terms of moving project managers from project to project. My first job at the assignment is to demonstrate this capability, and then work with the client to make it a core competency.

2. Model Best Practices – My company’s project management services are built around the idea that project management is a very mature competency with many available sources of knowledge, and yet companies still struggle with challenged or failed projects. We firmly believe that the implementation and consistent application of project management best practices is what differentiates successful projects from challenged projects. The more ingrained these best practices are in the project management culture, the lower the dependency on the talents and heroic efforts of individual team members. There are a “critical few” best practices areas that if performed well will significantly improve the team’s performance, as well as the project outcomes (identifying key stakeholders, facilitating the development of the WBS, creating a strong schedule and budget, managing change, and measuring performance to name a few). Throughout the project life cycle, I diligently perform / model these best practices as part of “doing my job” leading the project team. Just when you think nobody is watching, someone will surprise you and comment on how you handled a certain situation. It is in these moments that you know you are leaving a lasting impression on the client based upon the way you are modeling the effective application of the “critical few” best practices.

3. Proactively Mentor / Coach – Part of improving the overall project management competency within an organization is building a project management team that has the capability and desire to effectively apply the best practices in the context of completing “real” project work. I find that having a core of experienced and skilled project managers is a requirement to a strong best practice centric project management culture. Less experienced project managers can “lean on” the core of experienced project managers for professional development counseling, and advice on specific project situations. One of the most enjoyable aspects of consulting engagements is providing “free advice” to other project managers on how I have handled specific situations on other projects (again relying on the effective use of the “critical few” best practice areas). These mentoring opportunities help improve project results associated with the specific situation, and also influence the way that the project manager will handle situations in the future. Effective coaching and mentoring is often represented as “intangible”, but it is surprising the overall impact it can have on the project management competency within an organization.

4. Properly Close Projects – I spend a lot of time on my blog talking about effectively closing a project. The reason I am so passionate about this topic is that project closure is the point in time for project managers to identify / highlight the things done well or poorly during the project, and initiate the appropriate actions to ensure that these lessons learned are reflected in future project efforts. At the end of a project, many project managers are busy preparing for their next project or client, and miss this prime opportunity to leave a lasting impact on the client organization. Project closure starts with effectively shutting down project activities, validating all product deliverables are complete and key product issues closed, and smoothly transitioning resources to new roles. The second aspect of this best practice area is preparing the project closure report (also referred to as the post-project assessment). Creating the project closure report includes gathering input from key stakeholders, and identifying improvement actions to be implemented either as part of the closeout process or for future projects. These improvement actions can have a significant impact on the effectiveness of the processes and tools regularly practiced within the project office.

5. Implement Continuous Improvement – As processes and tools are improved in the context of leading a project, the impact of the improvement is limited to a single project if it is not captured as a “standard” within the project office. Improvements may represent “filling a gap” in the project management processes, or an enhancement to an existing tool. In either case, it is important to ensure that the project office regularly captures and roll-outs these improvements across all projects. As a consultant it is usually pretty easy to introduce this practice, however it takes on-going demonstration and re-enforcement of the practice to “make it stick” – creating a culture of continuous improvement does not happen overnight.

Your comments are appreciated. How have you “left a mark” on the project management organization?

PM-Foundations – What Makes Projects FUN?

If you have read several of my blogs, hopefully you have picked up on the fact that I am sincerely passionate about project delivery. I am always energized and motivated when a project delivers tangible benefits to an organization. I like project work so much that it spills over into my personal life. It is personally satisfying to evaluate the “before” and “after” on a home project – even if it is something as simple as planting a garden, painting a room, or cutting the grass. So what is it about projects that people enjoy? There must be something there, because people actually volunteer and/or seek out opportunities to be assigned to a project team.

The intent of this post is to prompt some thoughts on the positive aspects of project work, and what you as the project manager can do to enhance team members’ experiences on a project.

What is fun about projects?

These are several of the aspects of project work that is inherently fun and rewarding for project team members.

  • Sense of accomplishment – There is a definite sense of accomplishment when a deliverable is completed, a milestone is achieved, or project is closed. When a project is closed you can observe benefits realized by the organization as a result of the team’s efforts. When a milestone is achieved you move on to a new phase in the project. In contrast, when you complete operational work, there is another “stack” of the same type of work right behind it, with no apparent end in sight.
  • Something Different – Projects provide opportunities for team members to be exposed to new technologies, business processes, and problems to solve. Exposure to new areas represents huge opportunities for team members to learn and develop both personally and professionally. For those of us that thrive on continuous learning, there is nothing better than being assigned to a new client or project.
  • Involves People – Small projects can be delivered by an individual, but the vast majority of projects involve a team of people assigned to accomplish a common goal. The people assigned to the project bring with them a diverse range of talents, experiences and perspectives/ideas. It is this diversity that ensures that the team’s unified efforts are much greater than the sum of its individual contributions. Assembling a diverse group of people as a new project team can be challenging (forming and storming) but it is ultimately very rewarding as the team starts to work well together (norming and performing). I personally find the broad spectrum of people I meet and work with during projects to be the most amazing element of being a project leader.
  • Recognition – All projects have a certain amount of visibility in the organization, otherwise the resources would not be assigned to it. With visibility comes recognition and potentially rewards when milestones are achieved and projects are successfully completed. Visibility can also result in negative consequences when projects are challenged or fail. Based upon my experiences there is far more upside potential associated with positive project outcomes, than risk of negative consequences associated with challenges or failures.
  • Projects End – By definition projects have a beginning and end. Admittedly, some projects are not as enjoyable as others, but at some point they all will come to an end (some more naturally than others). With the knowledge that the project will end, even the worst of projects can have their moments.

6 Ways Project Managers Can Make Projects More Fun

As a project manager, there are a number of things that you can do to establish a positive project environment – one that team members actually enjoy being a part of. These 6 tips are a combination of applying effective leadership skills, and implementing practical techniques to enhance the project environment. My experience has led me to the conclusion that in most cases creating a positive project environment translates into building a more productive and effective project team.

1. Focus on Teamwork – I spend a lot of time making sure the project team understands they are a team working towards a common objective, and not a bunch of individuals assigned to a project. Establishing a group that works as a team starts with making sure the team understands what we are trying to accomplish, and what success looks like. It also includes ensuring that everyone has internalized what their role is on the team, and how their role connects with the success of the overall project. There are things you can do to make sure the group feels like a team. Schedule regular team interactions (team meetings), provide meaningful project updates, and promote collaboration / interaction. Unless this group has worked together before, it takes some real work and focus on your part to make the group feel and interact like a team. Do not be discourage or give up as the team traverses through the forming and storming phases of creating a team. Your leadership can make a significant difference in terms of how the team works together.

2. Be Enthusiastic – Assuming you are like me, and really enjoy project work, make sure the team knows it. You need to consistently model the attitude and enthusiasm you want the team to feel throughout the project. If the project manager does not believe the team can be successful, who does? It is amazing how quickly the team will get discouraged when you display negative vibes about the project either verbally or non-verbally. The easiest way for me to model a positive and enthusiastic attitude during team interactions is to make sure I really do feel that way. When faced with difficult tasks or people, I remind myself what I enjoy about the challenge the project is providing, the team I am working with, and the opportunity to learn something new. This is a critical tip – do not ignore it.

3. Track & Communicate Priorities – This one sounds pretty straightforward, but it is amazing how quickly team members can get “lost in the weeds” or “in a funk” without timely and relevant information about the project. Team members must understand the team’s top priorities, and how these priorities tie to their individual work assignments. Priorities include upcoming milestones, task assignments, action items from team meetings, as well as high impact issues and risks. I try to keep this information simple and easy to consume / internalize – What did we accomplish last week? Where should we focus next week? What roadblocks need to be removed?

4. “Stretch” the Talent – As the team is forming, it is important to get to know the individual team members. Not only do you need to understand their strengths and weaknesses, but also what are the things that motivate and energize them. If you have insights into team member’s professional development path, you can help align work with the areas where they have talents, are excited about, and/or desire to learn. Aligning work and responsibilities in a manner that gives people a chance to “step up” on the team goes on a long ways towards building a highly motivated team that delivers positive results. The opportunities on the team can be both in the form of specific work assignments, as well as roles (e.g., facilitation of team meetings, coordination of team events).

5. Purposeful Recognition – It is extremely important to recognize people’s contributions on the team. There are two categories of contributions that I recognize on the team – (1) efforts that help the team achieve its goals, and (2) efforts that demonstrate or promote teamwork. As the project manager, you are recognizing contributions that helped drive positive project outcomes based upon either the work that was performed, or the way in which it was performed. A significant amount of positive energy can be created on the team by recognizing the right efforts at the right time. The recognition does not need to be elaborate, but it must be sincere, and a bit of creativity helps generate a fun atmosphere on the team. When given the choice of recognizing an individual or a group effort, I generally opt for recognition of the group (sends the right message as a team, and ensures you do not unintentionally leave someone “off the list”).

6. Close the Project – When you have come this far with the team, do not forget to bring appropriate closure to the effort. Effectively facilitating the lessons learned process helps the team reflect on what was accomplished, how it was accomplished, and what would the team do differently on the next project. This is the opportunity for the team to have a real impact on how projects are completed within your organization in the form of implementing continuous improvement actions. The other important element of project closure is celebrating success. Facilitate a project celebration that helps team members feel good about was accomplished before they rush off to their next assignment.

PM Foundations – The Project Closure Report

I used to have a boss who at the end of a project would always say “Let’s put a bow on this thing”. Even though this is kind of corny statement, the project closure report represents the proverbial “bow” on the project. The project closure report summarizes the product delivered, metrics associated with the effectiveness of the project delivery process, and the feedback captured from project stakeholders (including recommended next steps for future projects). This document is utilized to communicate a final summary of the project for project stakeholders, as well as create a reference document filed in the project archives (generally maintained by the project office). The communication to the project stakeholders is focused on confirming that the project is “done”, and assessing the project delivery process. The information maintained for purposes of the project archives focuses on creating a permanent record for reference by future project teams.

Because a large number of the readers will be looking for key take-aways about the project, I always include an Executive Summary that provides an overview of the project, highlights key project performance metrics, and summarizes the lessons learned and next steps. After the Executive Summary, the next section of the project closure report summarizes what was delivered with the project (from the product validation process). This summary compares what was delivered vs. the baseline expectations of the scope of the project and product. A listing of the outstanding issues and defects (with a brief description of the issue) is also included in this section. The primary purpose of the Product Validation Summary is to describe why the project is considered to be done.

Project Results

The next section details the key project performance metrics, including an assessment (rating) for each type of performance metric (cost, schedule, change, and quality), and a brief explanation of the team’s performance associated with the metric. The discussion in this section is generally organized based upon the type of performance metric.

Budget Performance

Budget performance metrics describe how effectively the team was able to manage to the baseline project budget. Budget performance metrics include:

  • Final Cost – What was the final actual cost of the project?
  • Breakdown by Component – Breakdown of the final cost by cost category (same costs categories that have been tracked and reported throughout the project life cycle). It is helpful to provide the breakdown with both total cost by category, as well as % of total.
  • Budget Variances – What is the difference between the baseline budgeted costs and the actual cost? This should be detailed in dollars and as a percent of the project budget. Detailing the variance by cost category clarifies the source of the cost variances.
  • Budget Performance Rating – Based upon the % budget variance, assign a Green/Yellow/Red rating to budget performance for the project. The budget rating is best defined at the beginning of the project in the cost management section of the project management plan (e.g., Green <10%, Yellow 11-20%, Red>20%).
  • Explanations for Key Variances – Represents a descriptive narrative explaining the key budget variances. I find it beneficial in the variance description to quantify how much each variance source accounts for the total variance (in dollars or as a percent).

Schedule Performance

Schedule performance metrics describe how effectively the team was able to manage to the baseline project schedule. Schedule performance metrics include:

  • Total Duration – What was the actual duration of the project (from the start date to the end date)? Even though people may be close to the project, it is surprising how many do not know the day it started, or how long they have been working on it.
  • Schedule Variances – What is the difference (in days) between the baseline end date and the actual end date? This should be detailed in days and as a percent of the total project duration. To provide clarification of the cause of the variance it is also helpful to provide the variances (days and percent) for each of the project phases/milestones.
  • Schedule Performance Rating – Based upon the % schedule variance, assign a Green/Yellow/Red rating to schedule performance for the project. The schedule rating is best defined at the beginning of the project in the schedule management section of the project management plan (e.g., Green <10%, Yellow 11-20%, Red>20%).
  • Explanations for Key Variances – Represents a descriptive narrative of the schedule variance explanations. Again, I find it beneficial in the variance description to quantify how much each variance source accounts for the total variance (in days or as a percent).

Change Management

Change management metrics highlight the team’s ability to manage change throughout the project life cycle. Key change metrics include:

  • Total number of changes – Breakdown of the total number of change requests submitted, and the number that were approved and implemented. In addition, it is often helpful to provide a breakdown of the approved/implemented requests in terms of the number that impacted scope, schedule and cost.
  • Impact of the change – Sum of the impact of the approved/implemented change request on the project schedule (days) and budget (cost). This represents the cumulative impact of change on the project.
  • Highlight of key changes – A detailed description of the key changes that were implemented. In this section it may also be appropriate to highlight changes that were not approved, particularly if they are intended to be deferred to future product releases.
  • Approved change vs. Total variance – A comparison of the total impact of change on the project vs. the total project variances (schedule and budget) provides a good indication of how much change accounts for the total project variances. In other words, were project variances managed in a proactive manner (via the change management process) or reactive manner (via after the fact variance explanations) throughout the project.

Other Metrics

There are often other metrics of interest about the project that may not have been within the scope of the normal performance reporting by the project manager. Some examples include:

  • Duration / Effort by Phase – One of the questions that is often asked about projects is what was the breakdown of time and/or effort in each of the project phases? Although each project is going to be a little different, this is information that will be useful for assessing the reasonableness of plans for future projects. Another interesting measure is the percent of the total effort for specific functions (e.g., project management, requirements definition, coding, testing, and training). This type of metric can be used for estimating high level resource requirements for future projects.
  • Benefits Realized to-date – What benefits have been realized to-date as a result of the project? How do the results compare to the expected benefits identified in the project charter? Because the project closure is likely happening soon after the product is implemented, these may represent “preliminary” results (with an explanation of when more conclusive results will be communicated).
  • Benchmark comparisons – How did the performance on this project compare to other projects (within the project office, company, or compared with industry data)? What were some of the differentiators for this project compared to that data (either positive or negative)?
  • QA Metrics – What were the number / percentage of defects reported within each project phase? Test cycle? What was the closure vs. discovery rate for defects? What conclusions can be drawn from the QA metrics?

Feedback & Next Steps

The final section of the Project Closure summarizes the process and results of gathering stakeholder feedback.

  • Process – Summary of the feedback survey and lessons learned processes. Who was solicited for feedback? What was the response (# of surveys, # of participants)? How was the lessons learned discussion organized and facilitated?
  • Rating Metrics – What was the average score for each question? What was the number of very high or very low scores for specific questions? I often include commentary as to why the score is the way it is (if you received comments that help explain some of the scoring).
  • Key Themes – What were some of the common themes from comments on the survey or during the lessons learned session?
  • Opportunities – What are the high priority opportunities (those opportunities to improve, or leverage what was done well for future projects / product releases)?
  • Next Steps – What are the action items to ensure that the opportunities are moved forward in the right direction? Where possible, include owner assignments and target dates in this section of the document.

4 Elements of an Effective Project Closure Reporting Process

  1. Limited Original Work – If the project execution and closure activities (product performance reporting, product validation, and stakeholder feedback/lessons learned) have been effectively performed, the project closure report represents a summarization related effort, versus an effort involving a significant amount of original work.
  2. Executive Summary – Many of the stakeholders consuming the Project Closure Report are looking for high points about what was delivered, how effectively was it delivered, and what have we learned from it. Make sure you include an Executive Summary section in the beginning of the report that effectively communicates the information these Stakeholders are looking for.
  3. Variance Explanations – Ensure that variance explanations are fact based, and describe the impact the source of the variance had on the performance metric (e.g., the specific source accounts for x% of the total variance).
  4. Next Steps – The Project Closure Report clearly links the project performance to the lessons learned and the continuous improvement related next steps. Stakeholders will be “scratching their heads” if the lessons learned and next steps are not related to the project performance (cost, schedule, change, or quality).

Note: I have added the Project Closure Summary template that I use to my Templates page.

PM Foundations – An Effective Lessons Learned Process

In my experience, the best practice area that is most often minimized or entirely overlooked is project closure. At the end of a project, project teams are hurriedly preparing to move onto their next assignment, and miss a prime opportunity to leave a lasting impact on the client organization. Implementation of a consistent continuous improvement practice (aka, the lessons learned process) enables the ability to enhance the organization’s project delivery capabilities with the initiation of each project. The overall purpose of the lessons learned process is to identify improvement opportunities (things done well, or areas for improvement), and to initiate actionable next steps. In the context of this discussion, improvement opportunities can relate to both the product that was delivered, as well as how the project was planned and executed.

The lessons learned process should have consistent structure and organization from project to project. The following represents the primary steps in the lessons learned process:

  • Kick-off – The process is initiated with a brief discussion of the purpose of the lessons learned process. Information captured in the project closure survey is helpful to determine the best flow for the initial lessons learned discussion.
  • Capture Ideas – Ideas are generated for each of the project areas (e.g., project phase, functional group, or product category). Again, these ideas represent things done particularly well on the project, or areas for improvement. The facilitated discussion includes a review of ideas captured throughout the project (primarily by the project manager) and from the project closure survey, as well as brainstorming new ideas during the lessons learned meeting.
  • Group into Opportunities – Organize the ideas into groups based upon the type of improvement opportunity.
  • Prioritize – Identify the high priority opportunities, based upon impact of the opportunity (to the product or future projects).
  • Identify & Assign Actions – For the selected opportunities (high priority), identify actions that represent the next step(s) associated with implementing the opportunity. In addition, assign ownership for the opportunity to someone on the team who is responsible for seeing that the next steps are initiated.

Capturing Ideas

There are 3 primary sources of ideas around lesson learned opportunities:

  • Opportunities captured throughout the project. As improvement opportunities are identified throughout the project, they should be captured in a central repository. Particularly for longer projects, these ideas may get lost by the time you get to the end of the project.
  • The themes from the Project Closure Survey represent direct input for capturing ideas about lessons learned opportunities.
  • Through the review of opportunities that have been captured previously, the facilitator prompts the participants to brainstorm additional improvement related ideas.

It is a best practice to attempt to “guide” the discussion through the various aspects of the project in an organized manner. This could be based upon project phases, work streams, product categories, or functional areas. As with any well facilitated brainstorming session, the facilitator discourages passing judgment on ideas at this point in the process. You are trying to encourage participation in the process from all participants. In addition, using techniques such as having participants write new ideas on post-it notes helps get everyone involved in the process.

Grouping & Prioritizing Ideas

After completing the “brainstorming” process, the facilitator helps the team organize the ideas in groupings of related opportunities. It makes it easier to organize the ideas if they are grouped / organized based upon the type of opportunity (or opportunities that can be addressed with a common set next steps).

During this process it represents a best practice to physically organize the ideas into the related categories. This is either accomplished by re-organizing the post-it notes (posting the ideas on the wall in the groupings), or resorting the ideas captured by a software tool (displaying the ideas in the groupings using tools such as a Excel, Visio or MindMapper).

Once the ideas are grouped, the team works together to identify the high priority opportunities based upon the potential impact associated with each opportunity. This impact could be related to an improvement to the product, or an improvement to the project delivery process (across all projects). The opportunities can either by rated as High, Medium, Low, or ranked from High to Low.

At the end of this process the facilitator is attempting to get people to agree that the “right” opportunities have been identified, and prioritized appropriately.

Many times this point in the process is a good break for the first lessons learned session. The break provides participants time to review and elaborate on the improvement ideas before identifying the next steps.

Identifying & Assigning Actions

After the ideas have been organized and prioritized, the facilitator helps the team identify the appropriate next steps for the high priority opportunities. The next steps identified generally represent actions required to get the improvement opportunities moving in the right direction (vs. the exact steps to solve/implement the improvement). The facilitator should steer the team away from getting into a detailed discussion on how to solve the problem.

At this point in the process the team is also looking for people that can “own” the problem, or at least take ownership for the problem to the point that the next steps are initiated. The “owner” is generally somebody that either has accountabilities tied to the opportunity, or the passion/desire to help move the opportunity forward.

Managing Action Items

The single biggest complaint or “pitfall” associated with the lessons learned process is that nothing happens with the feedback that is captured after the project is closed and the team members return to their “regular” jobs. Sometimes this happens because the action items generated out of the process are not “actionable” enough to be implemented, but more often than not it is because there is not a group or process that is responsible for making sure there is the appropriate follow-through for the continuous improvement ideas and actions..

Part of creating a culture of continuous improvement is ensuring that there is the appropriate hand-off between the project team that identified the opportunity and the team that is responsible for implementing it. In a best case scenario, someone from the project team that is passionate about the opportunity can be part of solving the problem, but this is not always the case. Some practical ideas on where to go with the opportunities / action items from the project team:

  • Continuous Improvement Initiatives – If the opportunity is large or strategic in nature, a continuous improvement initiative may be launched to implement the action item(s). Like any other initiative, it will require adequate sponsorship and resources to be successful.
  • Project Operations – A client may have organizations that are responsible for taking learnings from initiatives and implementing continuous improvement ideas/actions (e.g., project office). The hand-off in this case is generally a presentation of the high priority opportunities and proposed next steps from the project team, and agreement on initiatives the project office should include in the future plans for their area.
  • Product Releases – Many times the improvement opportunities are associated with the product. In this case the opportunities and justification would be presented to members of the team that is leading the next product releases (or managing the on-going support of the product). This is the scenario where it is most likely that a member of the current project team would be part of the implementation of the continuous improvement opportunities.

Upon completion of the feedback process, and hand-off of the recommended next steps, it is the project manager’s responsibility to ensure that the process and supporting documentation is documented and stored in the project files. A summary of the process and recommended next steps will become part of the final project report. The supporting details should become part of the documents archived in the project files. This becomes a valuable asset for use by members of the project office or future project teams.

7 Lessons Learned Best Practices

  1. Timing – The lessons learned session can be performed at the end of the project, or at the end of major milestones/project phases (retrospective at the end of each sprint in the Agile world).
  2. Guided Discussion – Attempt to “guide” the discussion through the various aspects of the project in an organized manner. This could be based upon project phases, product categories, or functional areas. Generally if the discussion is “guided” (vs. randomly generated), the discussion is more organized and more likely to cover all aspects of the project.
  3. Organizing Improvement Ideas – Using a tool or physical representation on the wall, re-organize the improvement ideas into groupings. The re-organization process helps the team better visualize the appropriate next steps required to implement improvement ideas.
  4. Accountability – Someone is assigned accountability and responsibility for ensuring that something happens with the next steps recommended by the project teams. This accountability generally resides in the Project Office (project delivery opportunities) or the Product Maintenance teams (product improvement opportunities).
  5. Impartial Facilitation – To be an effective facilitator, engaging the group and guiding the discussion, it is best to have not been intimately involved in the project. As the project manager it seems natural to facilitate the lessons learned discussions, however that limits your ability to contribute as a participant. Consider engaging an experienced facilitator that has not been actively involved in the project to facilitate the meeting. The facilitator should be provided some level of background on the project (e.g., summary of project closure surveys) to help them better guide the discussion.
  6. Targeted Discussions – Often times it makes sense to break the groups into multiple sessions to focus on specific topics (e.g., components/phase of the project). One caution with this approach is to make sure the discussions are not so focused that you lose the overall cross-functional nature of the lessons learned process.
  7. Meeting Length – Lessons learned meetings that are too long tend to lose energy and focus by the end of the session. Therefore, you have high quality feedback around improvement opportunities and limited direction in terms of what to do about it (action items and assignments). To address this issue it is often helpful to break the lessons learned into two meetings: Meeting #1 = Capture, group & prioritize improvement ideas, and Meeting #2 = Identify & assign action items.

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 Closure

Here a few thoughts about a best practice area that is often minimized or entirely overlooked – project closure. At the end of a project, many project managers are hurriedly preparing for their next project or client, and miss a prime opportunity to leave a lasting impact on the client organization.

Project closure starts with effectively shutting down project activities, validating all product deliverables are complete & key product issues closed, and smoothly transitioning resources to new roles (onto new projects, or within operational functions). The PMBOK refers to this process as contract closure.

The second best practice area is gathering customer input about the project, and facilitating lessons learned. There are a lot of good resources available for gathering customer feedback for project work, and the easiest way to evaluate the quality of this data is to ask two questions of yourself and the project team:

  • Is this information actionable?
  • How likely will the organization do something with this information?

Although I place a high value on customer input and recommended next steps, the true sign of a well run project is demonstrated in the final project performance report (also referred to as the Post Project Assessment):

  • How well can you reconcile actual delivery dates to original baseline dates?
  • How well are budget variances explained through approved corrective actions?
  • Are project quality metrics well articulated?

The critical success factors of a solid project performance close-out are creating a strong and well understood project baseline, and diligently managing to the baseline throughout the project life cycle. Assuming these processes are performed properly, the final project performance report represents a summarization vs. data compilation & analysis effort.

%d bloggers like this: