Want to Avoid a Retrospective Scramble at the End of a Project? Create a Continuous Process for Documentation
BY NOVID PARSI
1 Seek Feedback Sooner Than Later
Regardless of a team's delivery approach, gathering feedback for closure needs to happen well in advance of project closure activities. For teams that use agile approaches, getting feedback early and often is a natural occurrence. During each iterative sprint or periodically during a waterfall project phase, the team should reflect on what's going well and not so well and what can be improved, says Jeff Amster, PMP, director of program management, AETEA Information Technology, Washington, D.C., USA.
“After a few cycles, you get into a good cadence of having a retrospective at the end of every sprint,” Mr. Amster says. Project managers then gather each sprint's feedback for the closing documentation.
It can take more rigor for waterfall projects, which lack a built-in, continuous review process. It's up to project managers to create mid-project retrospectives and to document them. “It is important to plan them as milestones within the overall project schedule,” Mr. Amster says.
On his waterfall projects, Mr. Amster creates a shared document and emails periodic reminders to his team to input their thoughts. That way, at delivery, team members don't have to try to remember what happened months earlier.
Even with agile projects, teams might need reminders to assess how the project's going. In his calendar invites for each sprint meeting, Mr. Amster asks his teams to reflect before the meeting and to add their insights to the shared document prior to the meeting to empower the team to dedicate the majority of the time to collaboration.
“People providing feedback spontaneously typically miss out on the opportunity to recognize longer-term successes or problem areas to provide the most valuable solutions for the team,” he says. With teams’ insights all in one shared document, project managers can quickly detect patterns and trends.
2 Show Appreciation for Candid Insights
Keeping the door open to all types of feedback will help establish a culture of honesty and encourage team members to share. Such an environment ensures both positive and negative developments will be documented during the project close. Mr. Hallberg says nurturing such expectations begins at kickoff meetings, where he lets teams know that everyone should look out for both small and large opportunities for improvement and report them to the project manager—without fear of repercussion.
“If you close the door to any feedback, nothing comes through it,” Mr. Hallberg says.
—Mattias Hallberg, PMP
He shows appreciation by thanking team members and assuring them he will look into the issue they've raised. On sensitive matters, he'll guarantee confidentiality if necessary. But he doesn't stop there. Mr. Hallberg follows up with the team members and lets them know the outcome—how their information was put to use.
“During a project's execution, I try to be genuinely grateful for any information provided, good or bad, as it might bring to light something I had very little knowledge about,” he says.
3 Be Discerning About What's Gathered
Determining the most helpful feedback for retrospectives—and which stakeholders are most likely to provide it—needs to happen at the start, with adjustments made throughout as necessary.
“First, target your audience. Determine who will participate in the retrospective process,” Mr. Amster says. A stakeholder who shows up at the kickoff meeting but doesn't have an active role during the project probably won't provide the most valuable insights. But a subject matter expert, or a stakeholder whose buy-in the project manager had to work hard to secure, could have valuable insights to share.
The list of feedback generators isn't fixed, however. Stakeholders who provide valuable feedback on one phase of the project might not be as helpful for another phase. And the stakeholders on the feedback list could change over time. “A stakeholder who wasn't initially on the retrospective list might turn out to be extremely active and engaged,” Mr. Amster says.
Similarly, not all feedback is equally valuable. Mr. Amster doesn't want his teams to ramble in the shared retrospective document. Instead, he asks them to list two things that are going well in each sprint as well as the top two opportunities for improvement. If they don't have time to contribute the four items or if the list of participants in the meeting is large, limiting the number of contributions is fine.
Such categorization of requests helps his teams organize their thoughts beforehand. Then, at the meeting, project managers can direct the participants to identify the top two discussion items, quickly scan the document's two columns (the good and the not-so-good) and hit the highlights of each.
“You have only so much time in a retrospective [meeting], so you want it to be focused—to celebrate the successes and target the pain points,” he says.
PHOTO BY JONATHAN TIMMES
—Jeff Amster, PMP, AETEA Information Technology, Washington, D.C., USA
4 Tailor the Structure to the Team
There's no one-size-fits-all approach to getting retrospective feedback, so project managers must tailor their communication methods and gathering formats. Asking people to speak up in retrospective meetings works well for the most forthcoming team members. But more reluctant team members might require formal online surveys to pry valuable insights from them. Knowing how to customize the approach for each stakeholder ensures that project managers will get optimum feedback from the start.
“There are always people at meetings who don't speak up, and in videoconferences you sometimes can't see the entire team,” Mr. Hallberg says. “Text-based feedback makes sure no one is overlooked.”
Mr. Hallberg also gleans insights by going through his daily project-related emails with project closure in mind. He copies any emails with potentially helpful insights into a labeled folder so he can assess that information later.
Surveys and meetings can't do all the retrospective work, however. Mr. De finds that team members can be reluctant to reply to formal questionnaires, which they might see as busywork. “People tend to ignore the request to reply to emails and fill out forms,” he says. So he supplements formal surveys with informal group and individual discussions at his weekly team meetings and in more casual settings. That helps him to identify team members who are motivated and those who aren't—and it is imperative to convert the latter to the former. “This is the leadership part of project management,” he says. PM
—Soumen De, PMP, General Motors Technical Center, Bengaluru, India
From the start,
Soumen De, PMP, thinks about the end of the project. That's why he's always prepared for the retrospective—even when other team members aren't.
Take, for example, the matrixed team members on a construction project he managed last year. To expedite things, they repeatedly contacted the external contractor whenever scope changes occurred. Aware that this could lead to a documentation disaster at project closure—with competing claims of whether the changes were necessary—Mr. De implemented a robust scope-change control process. Before each request was accepted and documented, all concerned stakeholders had to agree the change was needed and its effect on budget and schedule was acceptable.
“We had a clear assessment of the project's final costs and timeline during the project retrospective, since every scope change and its impact on time and cost was documented,” says Mr. De, executive general manager, operational excellence, General Motors Technical Center, Bengaluru, India.
Project managers must be willing to go above and beyond to stay on top of what's needed for project closing during all phases. By the time the project wraps up, many team members have already moved on—which can leave project managers scrambling to gather feedback and tie up documentation. Taking a proactive approach to gathering retrospective documentation can mitigate that risk and ensure project and program managers generate a more relevant and comprehensive final report.
“Project closure is often something people forget, but running a project is like flying an airplane—you need to plan the landing before it happens. Teams need to understand that a project is not complete until the retrospective [is done],” says Mattias Hallberg, PMP, CIO, Wahl and Case, a recruitment and human resources technology organization based in Tokyo, Japan.
—Mattias Hallberg, PMP, Wahl and Case, Tokyo, Japan
Here are four ways project professionals can prepare for project closure, long before the end arrives:
Here are two ways building a culture of proactive retrospectives can benefit organizations, according to Jeff Amster, PMP, director of program management, AETEA Information Technology, Washington, D.C., USA.
A WIDER LENS
Staying ahead of the game on retrospectives can uncover strategic insights that benefit the entire portfolio. That's why organizations should develop a standardized process for project managers to share feedback from each project closure across the enterprise.
“I've learned that simply collecting retrospectives across multiple projects over a long period of time isn't going to give organizations the value they want out of retrospectives,” Mr. Amster says.
Whether it's via a project management office or another governance authority, organizations should bring together project managers to review a set of retrospectives, highlight the most impactful lessons documented and then synthesize them into a set of enterprise-wide recommendations or best practices for the future. “So any new project can leverage those learnings,” he says.
THE HERE AND NOW
Taking a proactive approach to the retrospective can deliver real-time benefits throughout the project.
Last year, Mr. Amster led an agile project to automate and centralize a manual data-entry system. The system improved a global magazine's process for vetting publication pitches. Mr. Amster conducted a retrospective at each sprint and, after the first few, noticed a trend: Code development bugs, such as broken features, were appearing not during the early development phase but later, during user-acceptance testing.
So he introduced more rigorous testing earlier in each sprint. “That way, we had a more efficient, higher-quality product when we reached user-acceptance testing where our stakeholders would review the finished deliverables,” he says. That information and insight went into the closing documentation—and it allowed his team to course-correct mid-project.
Respond to Resistance
Building buy-in for proactive project retrospectives isn't easy when team members already are occupied with following myriad project processes. Ordering the team to build in time during each phase or sprint to complete closure-related tasks can backfire when teams are overburdened. One solution: Consider eliminating other processes so team members have more time to enthusiastically contribute to the retrospective throughout the project.
When he worked at Rakuten, a Japanese internet services company, Mattias Hallberg, PMP, led teams of up to 160 people who worked on monthly releases and were tasked with an abundance of processes. So the team continuously monitored whether new processes should be continued. “The rule was: Before adding a new process, try to remove two old ones,” he says.
For example, during a retrospective, the organization decided that requirements written by a less-experienced team member would undergo a review by a more senior colleague. But once the junior project professional had mastered that task, the additional layer of oversight wasn't needed. With that process eliminated, team members had more time for other tasks.