Chapter 13. Closing the Project
13.3 Post Implementation Reviews and Archiving Documents
13.3.1 Lessons Learned
Regular reviews are made during the project in the presence of team members and other stakeholders if needed. These reviews help the project manager and the team review the current situation, determine if there is a need to revise the project documents and plans, and take timely actions to prevent any problems that may occur later in the project. After the implementation of project activities is finalized and the deliverables are inspected and accepted by the client, the project team reviews all the documents and meets to discuss what went well and wrong during the project, and what could have been done to avoid the problems that occurred. It is of great importance to remember here that the lesson learned process doesn’t start in the close-out phase. As can be recalled from Figure 13.4 (also see Chapter 1), the closing process starts before the closing phase of the project life cycle starts. The project team has already produced many documents, reports, logs, and registers, and they have been edited and numerous new records have been added in parallel with project activities in the implementation phase. Therefore, some aspects of the closing process such as keeping the lessons learned register can start during the implementation when the project team learns from their experience and add them into the lessons learned register after a thorough discussion and assessment.
If the project is considered a success, the discussion can center on why the project was successful and the challenges that had to be overcome in order to achieve success. Lessons learned meetings are often quite enjoyable when the project was successful. If the project was unsuccessful, the conversation centers on the causes of failure. Table 13.3 provides two lessons from the M-Commerce project.
Table 13.3: Lessons Learned Register for M-Commerce Project
| Lessons Learned | Recommendation for Future Projects |
| Although our Risk Register identified a risk stating that “Cost estimates may be exceeded considering the factors of inflation and foreign exchange currency rates.” the risk trigger was indicated as “If the CPI (cost performance index) drops below 0.90, we will need to seek additional funding from management.”, the Systems Analyst 1 did not notify the project manager and the team of the problem when CPI decreased to 85%. An unexpected spike in the inflation rate in the USA increased the activity costs. | In future projects, it is of high importance to determine the risk owner as the project manager, not another member. Besides, a second person can be assigned to assist the project manager. |
| Our mobile app had serious issues regarding the bugs, and the app stores notified us of the deficiencies in the field of privacy. The developers and testers didn’t respond on time. | In future projects, in the recruitment process, the developers and testers should be asked to include their experience in previous mobile app projects in detail in their job applications. A minimum of three years of experience should be required. Besides, they should explain how they solved problems. |
Many project leaders request external facilitation in this situation so they can fully participate in the discussions. In addition, an external facilitator can help ensure the conversations remain objective and avoid tones of blame. A common approach is to identify, all in the context of the project’s objectives, what should be continued, what should be started, and what should be stopped. This is often referred to as the start/stop/continue approach.
Quality management is a process of continual improvement that includes learning from past projects and making changes to improve the next project. This process is documented as evidence that quality management practices are in use. Some organizations have formal procedures for changing work processes and integrating the lessons learned from the project so future projects can benefit. Some organizations are less formal in the approach and expect individuals to learn from the experience, take the experience to their next project, and share what they learned with others in an informal way.
13.3.2 Trust and Alignment Effectiveness
The project leadership reviews the effect of trust—or lack of trust—on the project and the effectiveness of alignment meetings in building trust. The team determines which problems might have been foreseen and mitigated and which ones could not have been reasonably predicted. Project stakeholder register, change log, issue log, and risk register can help the team in this assessment. Other questions that can be asked in this assessment are:
- What were the cues that were missed by the team that indicated a problem was emerging?
- What could the team have done to better predict and prevent trust issues?
13.3.3 Schedule and Budget Management
The original schedule of activities and the network diagram is compared to the actual schedule of events. Earned Value Management (EVM) tools can help the team a lot while making this comparison (see Chapter 11). Events that caused changes to the schedule are reviewed to see how the use of contingency reserves and slacks (floats) mitigated the disruption caused by those events. The original estimates of contingency time are reviewed to determine if they were adequate and if the estimates of duration and float were accurate. These activities are necessary for the project team to develop expertise in estimating schedule elements in future projects—they are not used to place blame. As discussed in Chapter 7, this can be significantly helpful in analogous estimating of activity durations in future projects. Besides, a review of budget estimates for the cost of work scheduled is compared to the actual costs. If the estimates are frequently different from the actual costs, the choice of estimating method is reviewed. In a similar vein, the results of the budget review would be an important input to future projects through analogous estimating (see Chapter 9). In this analysis, EVM is again an effective tool to compare the earned value to the actual cost.
13.3.4 Risk Response Strategies
After the project is finished, the estimates of risk can be reviewed and compared to the events that actually took place. The risk register, qualitative and quantitative risk assessment tools, risk response strategies, issue log, and stakeholder register will be of significant help to the project team to conduct this review. The following questions can help the team assess the risk management process during the project:
- Did the risks identified in the planning phase occur?
- If an identified risk occurred, was the response strategy sufficient to deal with the risk? Was the contingency reserve sufficient?
- Did events occur that were unforeseen (e.g., unknown unknowns)?
- What cues and triggers existed that may have allowed the team to predict these events?
- Was the management reserve sufficient to cover unforeseen risks?
Let’s assume that, in our M-Commerce Project, the second risk with the ID number 2.2 in Table 10.2 “An Example of a Risk Register” occurred (Table 13.4). Systems Analyst 2 (SA2) monitored the risk effectively, and checked with Developer 1 if they can work on the five activities under “2. Analysis/App Requirements”. Developer 1 notified SA2 of their absence. Therefore, SA2 asked Developer 2 to attend the activities. While the hourly rate of Developer 1 was $35, Developer 2 asked for $45. This caused an additional cost of $1,840. However, as can be recalled from Chapter 9 and the second question above, contingency reserve can be allocated in the budget within the cost baseline if the response strategy requires additional funds to deal with the risks. In this case, let’s consider that the project team included a $2,000 contingency reserve to cover the absence of Developer 1 (Table 13.5). Thus, this contingency reserve was sufficient, and it didn’t hurt the project. Eventually, this situation is recorded as a lesson learned.
Table 13.4: Risk 2.2 of M-Commerce Project
| ID | Related WBS Activity | Description | Risk Owner | Risk Trigger | Contingency Reserve |
|
2.2 |
2.1
2.2 2.3 2.4 2.5 |
The demand for developers increased recently since the demand for online games and mobile apps has been on a sharp rise after the emergence of the COVID-19 pandemic. We may experience a shortage of developers in the market. | Systems Analyst 2 | Ten days before the “Analysis/App Requirements” component starts, we must assure that Developer 1 starts working on project activities. | $2,000 |
Table 13.5: Costs of “Analysis/App Requirements” Stage of M-Commerce Project
| WBS | Activity Name | Duration | Cost |
| 2 | Analysis/App Requirements | 29 days | $31,960.00 |
| 2.1 | Review needs analysis based on the business case | 3 days | $2,760.00 |
| 2.2 | Elicit requirements from stakeholders | 10 days | $10,000.00 |
| 2.3 | Draft preliminary stakeholder specifications | 5 days | $5,000.00 |
| 2.4 | Review specifications with team and stakeholders | 5 days | $8,600.00 |
| 2.5 | Incorporate feedback on the specifications | 3 days | $2,160.00 |
| 2.6 | Develop a preliminary budget and delivery timeline | 2 days | $1,440.00 |
| 2.7 | Obtain approvals to proceed (concept, timeline, budget, resources) | 1 days | $0.00 |
| 2.8 | Analysis complete (Milestone) | 0 days | $0.00 |
| Contingency Reserve | $2,000 |
13.3.5 Client and Stakeholder Satisfaction
Relationships with the client are reviewed by the team and the relevant internal stakeholders such as the project sponsor, project steering committee, and functional departments. In the meetings held with the client, they are given the opportunity to express satisfaction and identify areas in which project communication and other factors could be improved. Often a senior manager from the organization interviews the client to develop feedback on the project team’s performance. An internal or external audit also helps the team and the organization evaluate the relationships with the client and stakeholders, and assess the overall satisfaction of the client.
A general report that provides an overview of the project is created to provide stakeholders with a summary of the project. The report includes the original goals and objectives and statements that show how the project met those goals and objectives. Performance on the schedule and budget are summarized and an assessment of client satisfaction is provided.
This report is also submitted to the senior management as an executive summary containing all the information provided to the stakeholders. The report identifies practices and processes that could be improved or lessons that were learned that could be useful for future projects.
