Unit - PROJECT CLOSURE

ANALYSIS (4)
PROJECT CLOSURE ANALYSIS
• For the project manager, the team, and the organization, the project
does not end until a post-mortem has been done to uncover what
went wrong and why, and what worked and why.
• A project closure analysis, or post-mortem analysis, is a golden
opportunity for process improvement that should not be missed.
• Project closure analysis is the key to learning from the past so as to
provide future improvements.
• To achieve this goal, it must be done carefully in an atmosphere of
safety so that lessons can be captured and used to improve the
process and future projects.
 The Role of Closure Analysis
• The objective of a postmortem or closure analysis is
“to determine what went right, what went wrong,
what worked, what did not, and how it could be
made better the next time.”
• This analysis is also needed to understand the
performance of the process on this project, which in
turn is needed to determine the process capability.
• the data obtained during the closure analysis are
used to populate the process database (PDB).
• After data analysis and extraction of all lessons
learned from the analyses, the results should be
packaged so that they can be used by others
Performing Closure Analysis

• A template for the analysis report has been defined.

• the effort data are available from the weekly activity report database.
• The data are first analyzed by the quality adviser, who develops an
initial interpretation of the results. A meeting is then held among the
quality adviser, the project leader, and other project members
• This meeting yields the basis of the final closure analysis report.
• The final report is submitted to the SEPG and the business manager
of the project and is shared among the project team members
Closure Analysis Report
• The contents of this analysis report form a superset of the data that
are put in the PDB
• General and Process-Related Information
• Risk Management
• Size
• Effort
• Defects
• Causal Analysis
• Process Assets
• The contents of this analysis report form a superset of the data that are put in the PDB.
The PDB contains only those metrics data that are needed often by projects and whose
use is required by the current processes. The analysis report, however, may capture
other data that might shed light on process performance or help to better explain the
process.
General and Process-Related Information
• The closure report first gives general information about the project, the overall
productivity achieved and quality delivered, the process used and process deviations, the
estimated and actual start and end dates, the tools used, and so on.
• This section might also include a brief description of the project's experience with tools.
The information about tools can be used by other projects to decide whether use of the
tool is warranted. It can also be examined to identify tools that have good advantages
and to propagate their use throughout the rest of the organization.
Risk Management
• The risk management section gives the risks initially anticipated for the project along
with the risk mitigation steps planned. In addition, this section lists the top risks as
viewed in the post-project analysis (they are the real risks for the project). This
information can be used by later projects and can be used to update risk management
guidelines. Notes may also be provided on the effectiveness of the mitigation steps
employed.
Size
• Many projects use the bottom-up method for estimation. In this method, the size of the
software is estimated in terms of the number of simple, medium, or complex modules.
Hence, this size is captured along with the criteria used for classification (different
projects may use different criteria). Data on both the estimated size and the actual size
are included.
Effort
• The closure analysis report also contains the total estimated effort and the actual effort
in person-hours. The total estimated effort is obtained from the project management
plan. The total actual effort is the sum of the total effort reported in all WARs submitted
by the project members, including the project leader. If the deviation between the actual
and the estimated values is large, reasons for this variation are recorded.
• For each of the major steps in the process, the total actual effort and estimated effort for
the stage are captured, too. This information can be useful in planning, and it is a key
input in forming the PCB. For each stage, where possible, the effort is separated into the
effort for the task, for the review, and for the rework. The WAR codes described earlier in
the book permit this separation. The distribution of effort in the various phases can then
be computed and recorded. The separation of effort between task, review, and rework
aids in identifying the scope of productivity improvement
Defects
• The defects section of the closure analysis report contains a summary of the
defects found during the project. The defects can be analyzed with respect to
severity (percentage of defects that were major, minor, or cosmetic), stage
detected (percentage of total detected defects detected by which activity), stage
injected (which activity introduced what percentage of total defects), and so on.
Injection rate and defect distribution are also determined
Causal Analysis
• When the project is finished, the performance of the overall process on this
project is known. If the performance is outside the range given in the capability
baseline, there is a good chance that the variability has an assignable cause.
Causal analysis involves looking at large variations and then identifying their
causes, generally through discussion and brainstorming.
Process Assets
• In addition to the metrics data, other project artifacts are potentially useful for
future projects. These process assets are collected at project closure. The
potential entries to the BOK are also identified during closure, although they are
submitted later
Closure Report of the ACIC Project
1. GENERAL INFORMATION
2. PERFORMANCE SUMMARY
3. PROCESS DETAILS
4. TOOLS USED
 5. RISK MANAGEMENT
Notes on Risk Mitigation
• Risk1: Clearly articulating the risk
helped in customer agreeing to
postpone the conversion with
proper budgeting of its impact.
• Risk2: Mitigation strategies of careful
and advance planning and
employing the on-site coordinator
were effective.
• Risk3: Training the team in RUP was
effective. So was keeping the
customer informed.
• Risk 4: Remained as a risk, although
it did not materialize. Impact would
have been minimal because multiple
people were kept informed of each
critical activity.
6. SIZE
7. SCHEDULE
8. EFFORT : Distribution over lifestyle stages
 9. DEFECTS
• Reasons for Deviation
• Defect prevention reduced the
defect injection rate in later
stages, resulting in overall
reduction in the defect injection
rate.
• In the earlier project from which
the estimates were derived,
fewer code reviews were done
and there was a heavier reliance
on UT. In this project, because
code reviews were done more
rigorously and widely, more
defects were found in reviews,
leading to a substantial decrease
in the defects found in unit
testing.
10. CAUSAL ANALYSIS AND LESSONS LEARNED
• There were very few large deviations in the process performance; the actual
performance was close to what was expected. The reasons for the deviations, where
they are large, are given along with the deviation. Some key lessons learned are:
• Incremental or phased development is extremely helpful in achieving higher quality and
productivity because data from the first phase can be used to improve the remaining
phases through defect prevention.
• Defect prevention can substantially reduce the defect injection rate. In terms of effort
also, defect prevention pays off handsomely; by putting in a few hours of effort, up to 5
to 10 times effort savings can be achieved in the form of reduced rework effort.
• If a change request has a major impact, discussion with the customer using a detailed
impact analysis can be very helpful in setting the right expectations and doing a proper
cost-benefit analysis (which may result in postponement of the change, as happened in
this project).
• The defect removal efficiencies of code reviews and unit testing are very low. Processes
for both, and implementation of these processes, need to be reviewed to improve these
numbers. In this project, the system/integration testing compensated for the poor
performance of reviews and unit testing. However, for larger projects, this may not be
possible and poor performance in reviews and unit testing can have adverse effects on
quality.
11. PROCESS ASSETS SUBMITTED
• Project management plan, project schedule, configuration
management plan, Java coding standards, code review checklist,
integration plan review checklist, impact analysis checklist, causal
analysis reports for defect prevention.