Chapter 13. Closing the Project

13.3 Post Implementation Reviews and Archiving Documents

13.3.1 Lessons Learned

If needed, regular reviews are made during the project in the presence of team members and other stakeholders. 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 important to remember here that the lessons learned process doesn’t start in the close-out phase. As can be recalled from Figure 13.3.1 (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. 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 adds them to the lessons learned register after a thorough discussion and assessment.

The image is a graph depicting the level of effort across the five Project Management Process Groups over time:X-axis: Represents the project timeline from start to finish.  Y-axis: Represents the level of effort, including workforce, resources, and interactions.  The curves indicate the effort required for each process group:  Initiating Process Group (black dashed line): Peaks early in the project, representing initial setup and approvals.  Planning Process Group (green dashed line): Increases after initiation, peaking before execution, as detailed plans are created.  Executing Process Group (blue dotted line): Requires the most effort, peaking during the project's implementation phase.  Monitoring and Controlling Process Group (yellow dashed line): Spans the entire project, with consistent effort, peaking slightly during execution.  Closing Process Group (red dashed line): Peaks near the end of the project, reflecting the finalization of deliverables and administrative tasks.  This graph highlights the dynamic allocation of resources and effort throughout a project's lifecycle.
Figure 13.3.1 Project Management Process Groups (Adapted from PMBOK Guide 6th Edition)

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 to achieve success. Lessons learned meetings are often quite enjoyable when the project is successful.  If the project is unsuccessful, the conversation centers on the causes of failure. Table 13.3.1 provides two lessons from the M-Commerce project.

Table 13.3.1: 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 highly important 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 continual improvement process 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 their approach and expect individuals to learn from the experience, take the experience to their next project, and share what they informally learned with others.

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 could not have been reasonably predicted. The project stakeholder register, change log, issue log, and risk register can help the team with this assessment. Other questions that can be asked in this assessment are:

  • What cues were missed by the team that indicated a problem was emerging?
  • What could the team have done to predict better 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 greatly help the team while making this comparison (see Chapter 11). Events that caused changes to the schedule are reviewed to see how 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 for comparing 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 in conducting this review. The following questions can help the team assess the risk management process during the project:

  1. Did the risks identified in the planning phase occur?
  2. If an identified risk occurred, was the response strategy sufficient to deal with the risk? Was the contingency reserve sufficient?
  3. Did events occur that were unforeseen (e.g., unknown unknowns)?
  4. What cues and triggers may have allowed the team to predict these events?
  5. 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.3.1, “An Example of a Risk Register,” occurred (Table 13.3.2). Systems Analyst 2 (SA2) monitored the risk effectively and checked with Developer 1 to see if they could 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, a 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.3.3). Thus, this contingency reserve was sufficient and didn’t hurt the project. Eventually, this situation is recorded as a lesson learned.

Table 13.3.2: 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 ensure that Developer 1 starts working on project activities. $2,000

Table 13.3.3: 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 the 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 day $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 with the client, they can 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 client’s overall satisfaction.

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 learned that could be useful for future projects.

License

Icon for the Creative Commons Attribution-NonCommercial 4.0 International License

Project Management, 2nd Edition by Abdullah Oguz, Ph.D., PMP® is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License, except where otherwise noted.

Share This Book