DIk_MVmNY7

hybridtek
DOK7.pdf

Module Seven: Project Closure

Module 7: Project Closure

Closure is an essential aspect of every project—it ensures that records are collected and archived, contracts are formally closed, and stakeholders are informed and updated on project successes and failures. Furthermore, closing a project ensures that lessons learned on the project are not forgotten and that best practices are recorded and used to improve performance on future projects.

Learning Outcomes

After completing this module, you should be able to:

1. Administratively close out a project 2. Host retrospectives and gather lessons learned 3. Transition project results to their final owner 4. Disband the project team and address outstanding stakeholder concerns

7-1 Module Seven Pre-test

Module Seven Pre-test

Click "Next" to access the Module Seven Pre-test

7-2 Administrative Closure

Administrative Closure

Depending on its size and complexity, a simple meeting may be all that a project manager needs to close a project formally. But for larger or more complex projects, the project manager may need to spend a little more time to ensure that their project is closed appropriately.

The Closing Checklist

The tasks needed to close a project are not always the same from project to project, so the project manager may want to consider using a checklist to ensure that projects are closed appropriately. The checklist should describe all of the major steps in project closeout, so the project manager can see which activities need to be quickly implemented to wrap up their project.

The following checklist shows a few basic activities, but the length of the checklist that the project manager uses will depend upon the level of detail and complexity of their particular project.

Copyright © 2022 MindEdge Inc. All rights reserved. Duplication prohibited.

At the end of a project, the project manager will have likely several "loose ends" to tie up before they can close it out completely. To close a project effectively, they'll need to consider each of the activities below and develop plans to ensure they are completed:

Click on each of the arrows below for more information.

Reassigning personnel: Often, individuals on project teams face a certain amount of stress and anxiety toward the end of their projects. These feelings may be caused by the uncertainty about future work or from their pending separation and return to normal work activities. As a project manager, it is important to consider the psyche of team members because it can affect the ability to swiftly close the project. Team members who are reluctant to leave the project may draw out final project work or start work packages that were not assigned to them, so it is important to continue to monitor and control progress in the late stages of the project to ensure that work is completed. The project manager may also consider taking an active role in

helping team members integrate back into organizational roles or transition into new roles.

Closing contracts: Because the project manager is the person most familiar with the project and its contractual obligations, they are in a unique position to review existing contracts and to ensure that all obligations have been satisfied.

Creating support documents and product materials: The project manager may be tasked with providing the support material for the product they created. This may include user guides, owner's manuals, marketing material, or any other documents needed to support the project in subsequent phases of its life cycle.

Communicating the completion of late-stage tasks and results to stakeholders: The project manager may have to show stakeholders that several late-stage activities have been completed. It is especially important to communicate any changes or modifications that were incorporated late in the project to prevent surprises when the product is launched. The project manager may also want to ensure that the plan to transition project results to their next phase is clearly documented and explained to all parties.

Completing a final report on the project: Lastly, the project manager may be required to create a final report that summarizes project activities and project results for the organization and key stakeholders. This documentation may include lessons learned on the project, but the project leader may choose to keep lessons learned information in a separate document for easier reference on future projects.

7-3 Closing the Project

Closing the Project

Formal closure is an important project stage that many practitioners ignore or overlook. They feel that once a project's deliverables are handed over to the appropriate parties, their work is done, and the project is complete. But this view leaves many actions unfinished, which may affect future projects and endeavors for the organization.

We have compiled several tips and best practices for project managers to consider as they close their projects. These tips will provide helpful hints for enhancing work and avoiding the pitfalls that may delay project closure.

Click on each of the headings below for more information.

Start thinking about closing the project very early in the project life cycle. Early in the project—in the Initiation, Planning, and Execution stages—picture what a successful project would look like and then work toward that vision. Visualize what the project's end stage should be and think about all of the things that would make the Closing stage simpler and easier to complete.

Copyright © 2022 MindEdge Inc. All rights reserved. Duplication prohibited.

Remember that Closing is more than just handing off the product. Transitioning the project to its final state is about handing the end result to the customer or production department, but it is also about considering the sustainability of the project results. As a project manager hands off the project, they should consider how they can enhance the project's sustainability throughout its entire life cycle. The manager should picture what the project's final deliverable will look like a few years in the future and try to predict any issues or problems that may occur, then work to proactively reduce the probability and impact of those issues.

In retrospective meetings, remember what went right, too. It is very easy to get caught up in review meetings discussing the bad things that happened on projects, but it is important to remember that many things must have worked well for the project to reach the Closure stage. By remembering to include achievements and positive results, the project manager will ensure that future projects will benefit from their experience and run with fewer problems and difficulties.

Have an outside facilitator run your lessons learned/project retrospective meeting. By asking someone from outside the project team to facilitate this meeting, the team can allow everyone on the project—including the project manager—to join the discussion and contribute to conversations.

Make sure that lessons learned are more than just a "gut feeling." While emotions are important to consider when discussing the positive and negative aspects of the project, including facts and data whenever possible will add details that will help future project participants understand and embrace suggestions as they plan their work. Saying that "we didn't work well together as a team" is less helpful than explaining why the team had difficulty interacting.

By incorporating these hints into their Closing processes, project managers not only make their completion of this stage easier, they will also enhance the work of future project managers who are running similar projects.

Additional Factors

In addition to the information presented above, it is important to remember several key factors to ensure that formal project closure is not neglected or disregarded, such as:

1. Closing ensures that all project activities are finished.

When a team closes their project they will need to ensure that all of the project activities that are expected to be completed have actually been completed. This may involve, among other things, ensuring that all milestones were met, that all project expenses are paid for, and that all tasks related to the project's scope are complete. It is also important to ensure that any contracts used on the project are formally closed. This means that all parts of the contract have been satisfied to the agreement of both parties, all necessary signatures have been obtained, and that all payments have been disbursed.

Closing ensures that stakeholders are satisfied that the project has met its objectives.

To affirm that the project is completed, the members of the organization who were granted authority by the project plan or charter to declare that the project has met its objectives must agree that it has indeed met them. Formal signatures from these parties may be necessary to complete the project, as stated in project documentation.

Closing ensures that the project's results are formally transitioned to subsequent stages and/or the project's end user.

Arrangements must be made by the project team to transfer deliverables to those responsible for them in operations or the next stage of the project life cycle. At the end of a project, the team must ensure that project deliverables have been approved in scope, and that the final product, service, result has been formally accepted.

Closing ensures that experiences and learning from the project are discussed and recorded for future use.

While some valuable project elements such as evaluations, audits, and support documentation are necessary to transfer the product to subsequent phases, these elements should also be collected and deposited into the organization's store of institutional knowledge. Information about techniques that worked well and new knowledge gained is valuable to the success of future projects; similarly, if a project failed or was canceled, details about that project and any formal paperwork that accompanies its closure are especially useful as lessons learned.

Closing also creates a formal space to celebrate and acknowledge those who did the project work.

The Closure stage provides an ideal place to reflect on the team's accomplishments and to congratulate them on their hard work. Finally, a project should be closed as soon as it has achieved its goals (or when it is agreed there is no hope for success). If a project is not closed in a timely way, it will continue to consume organizational resources and increase project costs.

7-4 Releasing the Product or Service

Releasing the Product or Service

The decision to release a product to stakeholders is a big responsibility that must incorporate the judgment, beliefs, and opinions of the project manager, project team, stakeholders, and organizational management. This group must take into account any defects, discrepancies, and the need for the solution (among other factors) before making a determination. Not all releases will look the same— solutions may be released as a whole product or in parts over time. It is important to consider all the prep work and assessments that have gone into business analysis, planning, and project work before making the final decision to release.

Click on each of the steps below for more information.

Copyright © 2022 MindEdge Inc. All rights reserved. Duplication prohibited.

Making the Call

Project teams can use the following techniques when deciding how to release a product, service, or deliverable:

Click on each of the headings below for more information.

Facilitated workshops At this point, facilitated workshops can gather key stakeholders in a room along with those that evaluated the project against acceptance criteria so that everyone can share their rationale and a decision can be made whether and how to release the product to the accepting operational team.

Group decision-making techniques To make final decisions and address any outstanding issues, key stakeholders can utilize decision-making approaches (such as voting, assessment matrices, prioritization/ranking, etc.) determined during stakeholder engagement to come to a consensus.

The resulting output from deciding how to release results to users is known as the release decision. This final release decision method needs to be documented and communicated to all impacted parties —what the team decides here will be followed by the appropriate parties to ensure a smooth transition and a successful roll-out of the product.

Ongoing Maintenance and Operations

Just because a project is in the Closing stage does not mean that all the work is done. There are many dimensions of closing a project—releasing resources, administration and contracts, transition and acceptance of deliverables, and hosting a project retrospective. Yet, even after all this, project work might still not be finished. Closing schedules should be closely monitored, and transition plans should also describe what happens next.

Certain deliverables will require ongoing maintenance and operations after project transition. This means that while the project might inherently be completed (in terms of accepted deliverables), members of the team may be assigned to assist, train, troubleshoot, or repair the product once it is in the hands of the new customer or department. Activities might include training sessions, writing user documentation, or manufacturing new components or parts when and if they fail. These activities will generally take place outside of the project life cycle, after it has been formally closed and deliverables accepted.

Post-transition work shouldn't be considered a surprise or out-of-scope. If the team or certain team members do hold post-release responsibilities, they should be clearly spelled out and communicated long before the services are of need. Typically, these steps will be dictated in early project documents alongside project acceptance criteria, meaning that transition will have been planned to some degree since the onset of a project. The type of commitment required can vary from pre-planned operations to informal, ad hoc meetings about concerns. It can be helpful to keep the issue log running or create a specific post-release issue log so that continuing customer needs can be met.

Those individuals working with the customer after project end may also be required to perform quality control. Quality management is an integral part of project management, so, ideally, it has been monitored over the course of the project life cycle. Implementing best practices in quality management early on can help prevent missteps after release.

7-5 Releasing Project Resources

Releasing Project Resources

Releasing project resources is an important—and often overlooked—component of closing out a project. This involves releasing both people (human resources) and any other types of resources such as equipment, office space, and research materials (among other things) that were used to complete project work.

Proactively managing and releasing resources will save an organization time, money, and headaches. For example, the team may have held a daily stand-up in a certain meeting space every day, and each team member was given a laptop with special computing abilities. The equipment should be returned to IT, and the project manager should be sure that the meeting space is no longer booked. These actions may seem negligible because equipment and office space allocation may be managed above the project level, but it does not mean that expenses are not being incurred by the organization somewhere down the line or that the resources aren't required elsewhere. The project manager should be prudent to cut back any costs or resource waste.

Depending on the type of project and the schedule for deliverable release, the release of human (and other) resources may start before the total closure of the project effort. It may not be necessary for each contributing team member to be working on a project for its entire duration. Additionally, an employees' next project placement may not always be so straightforward. As always, project managers should be communicating expediently with their team members, functional managers, and the PMO or senior management.

The team should gather all relevant documentation and stakeholder information pertinent to the solution release, such as the evaluation of acceptance criteria, business value, transition plan, and any risks or information.

Collaborating with stakeholders, the team must determine if the organization can handle a whole release or not. A whole release is a large effort, and the organization must have the capacity to handle the challenge. If it is determined that the customer cannot handle a whole release, the team may have to decide which areas will be implemented first, second, and so on.

Depending on what has been decided, practitioners will have to document the process, communicate with stakeholders, and (if appropriate) begin to execute the release according to plan.

Copyright © 2022 MindEdge Inc. All rights reserved. Duplication prohibited.

Organizations can work together to schedule efficient releases and optimize the utilization of resources across their portfolios. It can be helpful for both a project manager and team members to have an idea of what type of work is on the horizon for them.

Closing Contracts

While much of release comes down to communication and planning, there are also contractual matters to consider. Legal or human resources paperwork may be required to properly release a resource. Failure to file paperwork or settle contractual matters may cause a delay or even derail the project's success. The project manager should work with the procurement team, if necessary, to close any contracts.

Projects hold legal and financial liability, and the project manager should remember that the project work may be audited at any time in the future. The project manager should ensure that all documents are up to date and filed properly according to organizational and legal guidelines. Most project documentation can be stored using either physical or digital means. Many organizations provide guidelines and indices for record management and storing project materials so that they can be easily accessed at a later date.

Celebrating Project Success

Project closure should be treated similarly to a kick-off meeting. It is very important to gather information about project progress, but it is also important to celebrate a job well done—by the team as a whole and individually. Remember that team members are people. They have dedicated weeks, months, or years of their time to a project, despite other professional obligations and busy personal lives. Team members should be appreciated and recognized for their efforts.

These celebrations can involve a quick in-office celebration, but, in some cases, they may even be held off-site or after work hours, depending on the scale of the project and the practices of the organization. Sometimes, the celebrations are included as part of a retrospective meeting. Moving on to a new assignment can understandably cause stress, so project managers should take the time to celebrate and provide support and guidance while a project's success is still fresh and team bonds are strong. Not only will this validate employees, but it can help put them at ease as they transition, reeling on success and excited for what comes next.

7-6 Lessons Learned

Lessons Learned

Before handing a project over to a customer or to a production or operations department, effective teams conduct one final retrospective meeting to discuss lessons learned and to close the project officially. This final meeting allows the team to review the project as a whole and helps team members resolve any remaining issues before moving on to new assignments.

Video: Project Retrospectives

Project Retrospectives

Project retrospectives are meetings held during the Closing stage of a project to discuss what went well and what didn't over the course of a project life cycle. These meetings are also known as lessons learned or project wrap-up meetings.

Here are ten tips a project manager should follow to ensure that they are hosting effective retrospective meetings-

Be sure to invite everyone who contributed to the project. Schedule the review and invite contributors as early in the project as you can, so they can set aside time in their schedule to attend.

Start with a project overview to reacquaint everyone with the project's intended objectives.

Review the project's purpose and intended customer(s). Describe the initial design plans, the estimated budget, the scheduled start and finish dates, and other relevant information.

Record the project details. Include a final project description and list any problems or defects you encountered. Document the final budget and final release dates. List the development tools and processes you used and describe any innovations or process modifications you may have implemented.

Describe the project failures and successes. Have project participants review their project journals to remind themselves of their experiences on the project.

Take time to evaluate individual and team performance.

Record your impressions of teamwork, individual contributions, and newly acquired individual and team skills while they are still fresh in your mind, in case you are asked to assist in performance assessments and reviews.

Evaluate project risk management activities. Document the risks you took, record how they turned out, and make suggestions about how you would change your approach on future projects.

Develop conclusions and make suggestions. Describe what you think you should start doing, what you should keep doing, and what you should stop doing on future projects.

Don't release team members until you have completed all project closure activities. Make sure the team is available to complete any last minute items, clarify inconsistencies, and discuss lessons learned.

Start to think about future projects. Develop a plan of action for your own future projects. Decide how you will incorporate the lessons you learned from this project into your upcoming projects.

Record the results of the final project review and make them available to other teams. Document all contributions in writing and consider ways to make lessons learned accessible across your organization. This way, other project teams won't fall into the same pitfalls, and they will be able to work from your success

Project retrospectives are an effective way to wrap-up a project, elicit information from participating stakeholders, and to help prepare the project team for disbanding and moving on to the next endeavor.

Most importantly, a project manager has to ensure that final project reviews are not just meetings to rehash material that the team has already covered. Unless attendees see actions and results from these meetings, they will consider final reviews to be unproductive and may stop attending. Final reviews should be constructive meetings that collect information but also provide plans for putting that information into action on future projects.

Review Checkpoint

To test your understanding of the content presented in this assignment, please click on the Questions icon below. Click your selected response to see feedback displayed below it. If you have trouble answering, you are always free to return to this or any assignment to re-read the material.

1. Which of the following is not part of the three-part questionnaire you should ask project contributors to fill out?

a. a rating of their experience on a scale of 1–10

Incorrect. Try again.

b. targeted questions to capture specific feedback

Incorrect. Try again.

c. a comments section for qualitative feedback

Incorrect. Try again.

d. a numerical system for ranking the work of their teammates

Copyright © 2022 MindEdge Inc. All rights reserved. Duplication prohibited.

Correct. The three-part questionnaire would not ask participants to rank their teammates' work.

2. True or False?

In project retrospective meetings, you should describe what you should start doing, what you should keep doing, and what you should stop doing on future projects.

a. True

Correct. Project retrospectives are a good time to reflect on what activities you should start doing, keep doing, and stop doing on upcoming projects.

b. False

Incorrect. Try again.

7-7 Exercise: Managing Through the Project Life Cycle

Exercise: Managing Through the Project Life Cycle

Module Feedback

Module Feedback

[feedback|module]

Copyright © 2022 MindEdge Inc. All rights reserved. Duplication prohibited.

  • Module Seven: Project Closure
    • Module 7: Project Closure
    • Learning Outcomes
  • 7-1 Module Seven Pre-test
    • Module Seven Pre-test
  • 7-2 Administrative Closure
    • Administrative Closure
      • The Closing Checklist
  • 7-3 Closing the Project
    • Closing the Project
      • Additional Factors
  • 7-4 Releasing the Product or Service
    • Releasing the Product or Service
      • Making the Call
    • Ongoing Maintenance and Operations
  • 7-5 Releasing Project Resources
    • Releasing Project Resources
      • Closing Contracts
      • Celebrating Project Success
  • 7-6 Lessons Learned
    • Lessons Learned
    • Video: Project Retrospectives
    • Review Checkpoint
  • 7-7 Exercise: Managing Through the Project Life Cycle
    • Exercise: Managing Through the Project Life Cycle
  • Module Feedback
    • Module Feedback