Connecting Project Lessons Learned to your IT Strategy with Project Retrospectives

A general term for a review conducted after major project milestones is lessons learned. Company culture influences the review structure and amount of formality that stakeholders use to evaluate project outcomes and reflect on experiences. Lessons learned can range from quick, highly subjective opinions about “how things went” to detailed examinations of performance compared to project goals and objectives. A productive lessons learned process should also generate inputs that support a cycle of continual improvement throughout the organization.

The implication is that participants internalize lessons learned, transforming these experiences into wisdom that will be applied later. On a singular project level, with experienced team members, and a relatively low rate of change, this may be adequate. In larger, more complex organizations, with new projects and new team members, there are tremendous learning opportunities associated with transferring the lessons learned out of the source project and sharing them across the organization. For IT organizations challenged with growth and increasing project complexity, one way to enable information flow from project stakeholders to IT leadership is a project retrospective.

A project retrospective[1] is a formal method for evaluating project success against processes and outcomes. The three related process criteria include Time, Cost, and Product (attributes). The three related outcome criteria include Use, Learning, and Value. A comprehensive retrospective includes all major stakeholder groups and a facilitator who has subject matter expertise, but was not part of the project itself.

The retrospective process involves three key steps:

1. Collecting project data.
2. Evaluating lessons learned.
3. Evaluating the project against the six success criteria.

Collecting Project Data

Project data needed for an effective retrospective include a project description, stakeholder analysis, and timeline. The project description is comprised of relevant details. This may include:

• Development methodology used (e.g., Commercial Off The Shelf, or new development)
• Lifecycle used (e.g., Agile or Waterfall)
• Technical approaches (e.g., architecture, hardware, software, toolsets)
• Size (e.g., function points, team size, budget)

Performing the stakeholder analysis and constructing the project timeline are key differences in a retrospective compared to basic lessons learned. Stakeholder power, control of resources, level of interest, and degree of support/resistance all shape the understanding of the timeline and changes in project momentum. Detailed stakeholder analysis is critical to revealing the motivation behind project decisions.

Evaluating Lessons Learned

The evaluation of the lessons learned looks at where the project went wrong, e.g., went over budget, began to fall behind schedule, or encountered technical challenges. In the retrospective sense, a lesson learned should include a root cause analysis to push past observed symptoms. Careful examination of root causes will reveal preventive measures for future projects. These measures may be simple action items or large-scale process improvements. Implementation of these improvements can increase process capability and strengthen organizational assets. For example, as the organization matures and gains experience with retrospectives, creating a common mistakes checklist is another way for the organization to strengthen project reviews and startups.

Evaluating the Project Against the Six Success Criteria

The retrospective team evaluates the project against each of the six criteria separately. For example, was the project delivered with the expected level of quality? Next, identify the relationships between the criteria. For example, what impact did the project being over budget have on quality? Instead of simply evaluating a project as a high-level success or failure, questions that reveal the inner workings of the organization are easier to ask. For example:

• What effect did stakeholder power and influence have on project decisions?
• What discrete events affected project ability to stay on schedule?
• Were root causes found to be common issues or unique to this project?
• Was rigorous adherence to standard processes an unnecessary burden to the project?
• What changes are needed at the organizational level to remove common mistakes?

Without the context of a project retrospective, the lessons learned and associated causes might be conveyed in a highly subjective manner that is only valuable to the source project. Adding stakeholder analysis, root cause analysis, and evaluation of project performance against process and outcome criteria adds detail that allows the organization to evaluate the project in a larger context.

Obtaining different results requires a different approach. To uncover insights about your organization, take existing reviews and lessons learned a level deeper with project retrospectives. Regular examinations of process and outcome criteria will provide quantifiable insight into organizational weaknesses and strengths. Use this information in your next strategic planning cycle to drive your process improvement activities and adjust your resources and capabilities accordingly to meet performance goals or set new standards.