The goal of this artifact is to provide a quick overview of lesson 6 of PMI Authorized PMP Exam Prep- Close Project/phase. The purpose of this document is to provide opportunity to the course participants and enable learning anywhere anytime. The idea is to provide content that reinforces all the topics covered in the class on Saturday as part of the PMP course at Education Edge.
Close Project/Phase
The purpose of this lesson is to learn how to close phases or projects and ensure the customer, business or organization is poised to reap the benefits and value they planned for. This lesson also provides a list of good practices in project management closure processes.
Topic A: Project/Phase Closure
Topic B: Benefits Realization
Topic C: Knowledge Transfer
Topic A: Project/Phase Closure
Topic B: Benefits Realization
Topic C: Knowledge Transfer
Close Project/Phase- Topic A: Project/Phase Closure
Whether it’s closure of an entire project, or an individual phase, specific activities are required. Let’s start with the various reasons for closure of a phase or a project before moving on to discussing appropriate activities for the closing process.
A predictive project uses a closeout process, while teams using adaptive approaches complete work and “release” the result to the customer and then continue to the next release.
Acceptance of Deliverables (Predictive)
Acceptance of the deliverables according to the acceptance criteria often is part of the organization’s OPAs, meaning they meet the criteria set for quality, compliance, and so on in that organization.
The acceptance of deliverables may include partial acceptance as part of the individual demonstrations or review, with final acceptance covering the integration of individual requirements.
In some cases, this milestone is called “sign-off.”
The requirements traceability matrix is often key to ensuring that all requirements for specified deliverables have been completed and approved.
Acceptance Criteria –
A set of conditions that is required to be met before deliverables are accepted.Acceptance of Deliverables (Adaptive)-
In adaptive and hybrid projects, teams may use the similar “definition of done” to express the required state of completion.Definition of Done (DOD) –
A team’s checklist of all the criteria required to be met so that a deliverable can be considered ready for customer use.Premature or forced Closure
Whether a phase or project comes to a successful end with completion, or an abrupt end, you must complete closing activities. So, let’s begin with why projects or phases close.
Examples of forced or premature closure of projects or phases include:
- The first reason includes changes in requirements or needs—for example a change to the business case or the organization no longer wants the project.
- The second reason is for impediments-–some issue or significant risk can stop a project—for example, the cost of a project exceeds any expected benefit
- Starvation of Funds
- Misalignment with the vision
Close Project or Phase activities
- Acceptance of deliverables or product by customer
- Transition of deliverables or product to customer
- Notify enterprise and organizational functions; update OPAs
- Prepare final report
- Conclude external obligations, including legal, regulatory, contractual — e.g., transfer of liability, closure of all accounts in financial system
- Gather Lesson Learned and add them to the lesson learned repository
- Archive project information
- Release resources (human, financial and physical assets)
What is a Final Report?
A summary of the project’s information on performance, scope, schedule, quality, cost, and risks.
Transitions or Handovers
For effective handover, handoff, or transition of work in a project or phase, we need to think about the activities required to transition the result to the customer or end-user.
- Some organizations and teams create a transition plan or rollout plan. This is not a named subsidiary plan of the project management plan.
- Even though the transition plan is not a recognized project management plan, it is recognized by both business analysis and program management. It identifies how transition requirements, which are temporary and only required for completion of the project or release, will be delivered.
Transition Readiness
Before transitioning the project result to the customer, they must be ready to receive it. Releasing, delivering, and deploying the project’s work into an environment that is not ready may diminish or negate its value – including the organization’s acceptance of changes.
- Verify readiness before beginning the final transition or closing.
- All parties need to be “ready.” This includes end users, the business, the project team, and support staff.
- This final readiness check is often defined as part of the OPAs.
Close Project/Phase-Topic B: Benefits Realization
While adaptive life cycles are designed to deliver incremental value as soon as possible, it may be years after a predictive project closes for benefits to be realized and value delivered. It all depends on the nature of the work, the type of project, and the desired outcomes.
- Project types in which value is delivered very early: agile software development delivers incremental value-–end users can start using a prototype and give feedback on improvements
- Project types in which value is delivered months or years after transition: digitization of library archives – early value example is efficiency for end users and long-term value is more widespread accessibility and use of the materials
Benefits Transition and sustainment
- In any kind of project, the project team hands over the product or service that will provide benefits and value to the customer or receiving organization. Let’s look at the responsibilities of both delivering and receiving parties in predictive and adaptive scenarios.
- The project team hands over the product or service that will provide benefits and value to the customer or receiving organization, after reviewing the expectations included in the benefits management plan.
- In a predictive project, any ongoing activities beyond the project or iteration related to the delivered product or service are carried out by the receiving organization to ensure continued generation of benefits delivered by the project.
- In adaptive projects, Improvements or modifications to delivered benefits are proposed as work for the next or future iteration and placed or reprioritized on the backlog.
- Hybrid scenarios will mix the approaches, tailored to ensure efficient and effective delivery of benefits and planning for continued benefits creation. Organizations and teams create tailored solutions for benefits realization and sustainment — e.g., post-implementation support (aka “DevOps” or “hypercare”).
Benefits Management Plan
- The documented explanation defining the processes for creating, maximizing, and sustaining the benefits provided by a project or program. It also describes how and when the benefits of a project will be derived and measured. Both the business case and the benefits management plan are developed with the benefits owner prior to the project being initiated. Additionally, both documents are referenced after the project has been completed. Therefore, they are considered business documents rather than project documents or components of the project management plan.
DevOps
- A collection of practices for creating a smooth flow of delivery by improving collaboration between development and operations staff.
Benefit Owner
The benefits owner helps ensure that the benefits are transitioned and that the monitoring is in place to determine if the benefits are being realized. This work begins as soon as benefits are delivered and continues after the project—often for many years.
Benefit Realization
In hybrid and adaptive projects, product owners or project managers facilitate frequent reporting on benefits realization.
- Required content for the reports and frequency are often determined by the type of benefit (tangible vs intangible) and the potential impact on the organization.
Q: In a predictive project, once the transition is complete, who is responsible for verifying that benefits are realized?
A: In predictive projects, after the product or service is delivered, the transition and sustainment plan identifies the metrics and the organization/individual who will be responsible for the ongoing measuring of whether the benefits have been realized.
Close Project/Phase- Topic C: Knowledge Transfer
Knowledge transfer occurs between team members and stakeholders during the project, but it also becomes an asset to the organization and future projects as part of the historical project information.
This includes both the archiving of project artifacts per the OPAs as well as consolidating the individual lessons learned captured throughout the project into the organization’s lessons learned repository.
Knowledge Management During Closing
Knowledge Management is a discipline that includes a mixture of experience, values and beliefs, contextual information, intuition and insights that people use to make sense of new experiences and information.
Knowledge is captured throughout the project and then consolidated at the end to provide historical information for future projects.
- Conduct retrospectives or final meetings to discuss lessons learned from the project
- Archive all project information
- Finalize the lessons learned register, which is compiled throughout the project life cycle
- Add the lessons learned to the knowledge management/lessons learned repository
- Transition required knowledge from the project team to the organization — e.g., technical documentation and skills training
Lessons Learned Register
A project document used to record knowledge gained during a project. The knowledge attained can be used in the current project and entered into the lessons-learned repository for subsequent use.
Lessons Learned Repository
- A central store of historical lessons learned information from various projects across jurisdictions.
Finalize Lesson Learned
Lessons learned are valuable knowledge assets for an organization and, therefore, you should be thorough and conscientious in your approach to reviewing and finalizing these documents. Content is similar to what you include in the final report to the organization and stakeholders, but the purpose of the lessons learned is to archive and share knowledge with the organization and future project teams.
Lessons learned should include:
- Scope changes – Any major impact based on scope changes and the source and handling of those changes
- Schedule impacts – Any relevant scheduling problems or issues and how these were dealt with, especially concerning resource constraints
- Risks and Issues– Any issues that arose, including those within the team or between the team and customers. Include documentation of the nature and source of the issue and the impact on the project. Note whether issues had been previously identified as a risk. Capture notes about whether the appropriate reserves were identified, and whether they were required to be used.
- Stakeholder relationships – Make a note of significant stakeholder relationships, including preferences, specialties, or anything unique to their interaction
- Vendor relationships – If a vendor or customer is excessively litigious or unreasonable to work with, that information should be conveyed to the sales and legal departments and documented in the lessons learned repository. If the customer or vendor experience is positive, then capture the potential for future sales or working together.
- Artifacts – Can any of the project’s artifacts become part of the OPAs or templates to get more done with the same resources and deliver work sooner?
- Recommendations – Focus on developing recommendations, reviewing recommendations with others, developing appropriate implementation plans, and implementing those plans
