0% found this document useful (0 votes)
2 views

SPM lecture 26-

The document outlines the project closure phase in Software Project Management, emphasizing its importance for reviewing successes and failures to enhance future projects. Key activities include identifying reusable code, documenting best practices and lessons learned, conducting project postmortems, and formally releasing the team and contracts. Effective project closure can significantly improve productivity and customer satisfaction in subsequent projects.

Uploaded by

mediasales345
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
2 views

SPM lecture 26-

The document outlines the project closure phase in Software Project Management, emphasizing its importance for reviewing successes and failures to enhance future projects. Key activities include identifying reusable code, documenting best practices and lessons learned, conducting project postmortems, and formally releasing the team and contracts. Effective project closure can significantly improve productivity and customer satisfaction in subsequent projects.

Uploaded by

mediasales345
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 4

1|Page

Course Name: Software Project Management

Course Code: SESM-470

Semester: [BSCS-7] Credit hours: [3+0]

Presented by: Hina Mehjabeen

Week 16: Project closure (best practices, lessons learnt, project post martum,
releasing the team, releasing the contracts)

Project Closure in Software Project


Management
Project closure is a crucial phase in project management where attention is directed
towards reviewing the project's successes and failures. It involves drawing valuable
insights and lessons for future projects. Unlike project initiation, which draws on
existing knowledge, project closure enhances the knowledge repository by adding
lessons learned and best practices from the completed project.

Effective closure can reduce defect rates, improve future productivity, and enhance
customer satisfaction, contributing to the success of subsequent software projects.
However, it is often one of the most overlooked areas in software development.

When Does a Project Really Close?

The closure of a project is not always straightforward, especially when there are post-
delivery activities like warranty support or maintenance:

 After Warranty Support: If warranty support is not assigned to the same


organization, the project can close after this phase.
 When Maintenance is Separate: If maintenance is treated as a separate
project, the development project closes once the software is delivered and the
project artifacts are handed over to the new maintenance team.
 Hybrid Closure: When maintenance is assigned to the same team, the project
may remain open as long as maintenance is ongoing.
2|Page

Key Activities in Project Closure:


1. Identifying Reusable Code: Code components and documentation are
archived for reuse in future projects.
2. Documenting Best Practices: Key processes or activities that led to success
are documented and stored.
3. Lessons Learned: The team reviews what went right and wrong, with a focus
on both positive and negative lessons to improve future performance.
4. Final Project Metrics: Metrics like time, budget, and quality are compiled and
stored for future reference.

1.Best Practices Documentation


Best practices are the practices that significantly contributed to the success of the
project. These include methodologies, tools, and techniques that were particularly
effective. Some examples of best practices include:

 Use of a new or modified software engineering methodology that increased


efficiency.
 A new algorithm or tool that solved a major problem.
 An innovative approach to work allocation or quality assurance that reduced
efforts and improved quality.
 Any new checklists, procedures, or processes that streamlined project activities
and ensured better outcomes.

The SPM (Software Project Manager) is responsible for preparing and reviewing
these documents, which are then archived in the organizational knowledge repository
for future use.

2.Lessons Learned
Lessons learned come from both successes and challenges during the project.
Documenting lessons is vital to avoiding repeating mistakes in the future. Typical
lessons learned areas include:

 Communication Issues: How effectively the team communicated internally


and with clients.
 Work Allocation: How tasks were distributed and managed within the team.
 Defect Resolution: How defects were handled and resolved.
3|Page

 Change Requests: The management of scope changes and how they impacted
the project.
 Technology and Platform Issues: Challenges with the development platform
or tools.

These lessons are documented and stored in the knowledge repository, serving as
valuable insights for future projects.

3.Project Postmortem
The project postmortem is similar to a medical postmortem, where the project's
"cause of death" is analyzed. It's conducted to gain knowledge about what went
wrong and why, and it is intended to prevent future mistakes.

This process involves:

 Investigative Audit: An audit reviews variances in the project to understand


the causes of failure or success.
 Root Cause Analysis: The findings from the audit are dissected to identify the
root causes of project issues.
 Knowledge Sharing: The project postmortem may be followed by a
knowledge-sharing meeting where findings are discussed with peer SPMs to
promote learning.

The postmortem results are documented and added to the knowledge repository for
future reference. This meeting can be held separately or in conjunction with a
knowledge-sharing meeting, though both serve different purposes.

4.Releasing the Team


Once the project is complete and all deliverables have been approved, the team
should be formally released.

This involves:

o Officially disbanding the team or reassigning members to new


projects.
o Offering feedback and recognition for their work during the project.
o Conducting exit interviews to understand the team members’
experience, gather feedback, and provide support for their transition.
4|Page

o Acknowledging individual and team contributions to maintain morale


and motivation for future projects.

5.Releasing the Contracts


Releasing the contracts involves ensuring that all contractual obligations, both
internal and external, are met.

This can include:

o Contract closure with vendors or third parties, ensuring all deliverables


and payments have been completed.
o Final payments made to contractors, suppliers, or consultants.
o Contract documentation is finalized and archived for future reference
or audits.
o Any warranties or service agreements that need to be in place for
ongoing support after the project closure.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy