Congratulations! You’ve made it to the end of your project. The critical path is nearly completed, your team is happy but exhausted, and management is all smiles. You’ve been sampling the project as you move along through production for quality and scope verification, and you can reminisce about events that tried to shove your project off schedule and how you and the team recovered and pushed it back on track.

Already there’s a buzz of excitement among the end users of the technology. As you walk through the halls of the company, you feel a couple of inches taller, and it’s hard not to smile like a big, goofy kid.

But hold off on putting that cocktail umbrella in your favorite frosty drink. There’s still plenty of work that must be completed to get the project out the door and to finalize the entire process. In this final chapter, you’ll learn not only how to finish the project, but also how to formalize the project closure. It’s okay to smile and feel a sense of pride at this point of the project—just don’t let it get in the way of finalizing a job well done.

Whether you are working on a short-term project that lasted just a few months or a large, complex implementation that has taken over a year, the principles behind completing the project are the same: to complete any project, you and your team have to continue the momentum and supply the final surge to get the project to the finish line.

Completing the Final Tasks

When you begin to see the final tasks coming into focus, it is not a signal to ease off of the project team and the project. Some project managers make the costly mistake of allowing the project to finish under the guidance of a team leader or having too much faith in the project team to complete the tasks. These project managers allow themselves to relax, begin looking for new projects to lead, or begin their efforts to prove that Microsoft’s FreeCell game 11982 can be won. Agile project managers must continue to follow the rules, ceremonies, and servant leadership to ensure the development team continues to work as planned and finish the remaining items in the project.

The problem with relaxing as the project is nearly completed is that the project team will follow your lead and relax as well. Project managers have ownership of the project that sometimes leads them to believe they are superior to the project team and have permission to put their feet up. As the project team sees the project manager ease out of meetings, out of sight, and out of focus, they’ll follow suit and do the same, as Figure 12-1 demonstrates.

Figure 12-1  The project team will follow the project manager’s actions.

In the final stages of a project, a project manager must actually do more to motivate and communicate with the project team. The project manager must attend every meeting as has been done throughout the project. They need to get into the trenches and work with the team members to help them complete the work and keep them moving to complete the project on time. A project manager needs to discuss any final issues with the team, with the client, and with management. A project manager’s presence is obviously required throughout the project, but even more than usual during the final chunk of the implementation.

In an adaptive project, the project manager meets with the product owner and the development team as planned. The agile project manager continues to ensure that everyone is following the project guidelines, work is being completed according to requirements, and the final features of the project are created, tested, corrected as needed, and demonstrated in the sprint review. Nothing changes just because you’re almost done.

Going the Distance

What is, unfortunately, more typical of project managers than easing off of an on-track project is working in a frenzy to complete a project that’s gone awry. For example, consider a predictive project that has had six months to complete the implementation of a new e-mail client, develop workflow forms, and convert the existing e-mail servers. In this scenario, the final tasks are the most critical in the entire project. All of the prep work, research, and design has led the project team to this moment. The switch from old to new is when the curtain comes up, and everyone in the organization will see your work, your design, and your implementation. As Figure 12-2 demonstrates, these tasks, close to the finish, reveal your ability as a project manager.

Figure 12-2  The final tasks in a project require the project manager’s full attention.

That fact becomes quite evident when the project team and the project manager realize they are not prepared to complete the project on schedule. Now the project manager looks for ways to speed up the process to complete the job on time. This usually means additional hours, nights, and weekends. Be prepared to work the hardest in the final days of a project’s implementation if the project is off schedule, even by just a few days.

The secret is to control your emotions, the project team, and any other parties who have volunteered to help with the final tasks. If the folks looking to you to complete the work see you losing control, getting angry, and cutting corners, they’ll do the same. Cool heads always prevail.

When you find yourself with a huge amount of work to complete in just a few hours, here are a few guidelines for being successful:

•   Remain cool, calm, and collected. Set the example for your team; think clearly, but quickly.

•   Get organized and treat the final work as a mini-project. Analyze the work to be completed, break down the tasks, and implement the plan. Create a map of the final implementation in a central war room and color-code the completed tasks.

•   Communicate with the team members, but don’t get in the way of their completing tasks.

•   If you’re visiting multiple workstations, organize a method to represent the completed work visually. For example, if a workstation has been prepped for a new installation, put a red sticky note on the monitor. Once the workstation has been completed, put a green sticky note on the monitor. At a glance, anyone can see the status.

•   Check for quality. Periodically take a sampling of the work to confirm that what you are attempting to deliver on time is the quality you and the end user will expect.

•   Work in shifts. If your team must work around the clock, which is not unheard of, break up the team in shifts so that the team can get some rest and be refreshed. It’s tempting to have the entire team working on the final phases of an implementation, but as the entire team wears down, the quality of the work suffers.

Examining the Critical Path

As the project begins to wind down, take a close look at the critical path to determine that the tasks to completion are in order, and confirm that the team members who are assigned to the tasks are still motivated. In your team meetings, review the upcoming final tasks to reinforce the importance of their completion. Team members will likely be as excited to complete the project as you, so offer a little urging to continue the momentum to finish.

Within the network diagram, trace the history of the successor paths and determine if there is a history of tasks being late or lagging. If there is, address this issue to the project team and challenge them to complete the remaining tasks on schedule. You must do all you can to ensure that the project team is committed, moving, and excited to complete the project.

A source of motivation can be a review of all the work the project team has completed. You can show the team the number of hours committed to the project and how healthy the project is. Also, remind the team members of the rewards awaiting them once the project has been completed.

At the end of the critical path should be the management reserve. Recall that management reserve is a percentage of the total time allotted for all work within a project, usually 10 to 15 percent. Examine the management reserve to see how much time is still left for slippage. For example, a six-month project would likely have 14 to 20 days in management reserve for tasks that are lagging. In the final stages of the project, examine the balance of time in the management reserve; if things have gone well, you should have a few days left in reserve. If there have been serious mistakes in the project, then all of the available days in the reserve have been used. Figure 12-3 demonstrates the application of management reserve to early tasks in the critical path, which can impact any delays in the final task of a project.

Figure 12-3  A depleted management reserve can impact final tasks.

The point is, an examination of the management reserve will give you an idea of the overall health of the project and will predict how much time you truly have to complete the work. Hopefully, you’ve got a sliver of time left over to complete the project and allotted for any unforeseen troubles. In some instances, management reserve doesn’t matter—for example, when a network switch must take place over one weekend. A management reserve with two extra days won’t help at all if the network has to be switched when the production is not in place.

98 Percent Done Is Not Complete

When dealing with third parties that will complete the implementation phase of your project, you really need to convey to them that 98 percent done is not complete. Far too often, integrators begin a project with gusto but lag in the final implementation. Vendors sometimes need to be reminded that a project is not complete until it is 100 percent done. You can motivate these folks with these techniques:

•   Hold the final payment until the project is completed.

•   Specify the project deliverables as 105 percent to get them to aim for 100 percent completion.

•   Commit them to specific times and dates to work on the project in the final phases of the implementation.

•   Assign a task in the critical path that is a walk-through and sampling of the work they have completed. The critical path is not complete until you approve their work.

Conducting the Project Postmortem

The final task has been completed, and there’s a collective sigh of relief from all of the parties. But, sorry, you’ve still got a touch of work left to go on the project. Once all of the implementation tasks in the critical path have been completed, a project manager and the project team must do a few chores to inspect their own work. This time should be worked into the PND and shouldn’t take very long at all, maybe 1 to 3 percent of the total project time. This analysis is important not just because you need to review the project work, but also you need to review how the project deliverables affect your organization’s local and global environment. As you move the project into operations, there should also be a conversation confirming the understanding of the effect the project will have on the organization, the customers, and how the project will conform with laws or regulations.

Reviewing for Quality

The primary task that you personally must be involved with is to inspect the quality of the project. Of course, throughout the implementation, you will be sampling the project and confirming the quality, but at completion, you need to experience or test the project deliverables and confirm that they are the required deliverables to complete the project. You want to perform a final inspection before the project customer sees the deliverables. The point of this inspection is to correct any mistakes that may be present before the customer sees the deliverables during the scope verification process.

This final quality control activity should review the deliverables and benefits from the viewpoint of the project customer. To do this, re-create the experience that a typical user would have when using the deliverables. If your project produced an application, use it. If the project was to implement a network, log in to a workstation and test connections, print to a few printers, and access some network resources. Evaluate the product from the end user’s point of view and review the results to determine if the project deliverables are acceptable, as shown in Figure 12-4.

Figure 12-4  The process must be in place to test the quality of the project deliverables.

If you encounter problems, address them immediately so that the responsible parties can react to them and find a solution. At this point of the project, if you’ve done your job, there shouldn’t be any major surprises. You may encounter a quirk that can be quickly addressed and solved, but overall, things should be smooth and the customer should be happy.

Assessing the Project Deliverables

Once you’ve completed the final inspection and the quality of the work is acceptable and in alignment with the expected project deliverables, you can enjoy the sense of satisfaction that comes from the success of completing a project. There is a wonderful feeling that comes with taking a project from start to finish. The project is now part of the organization’s life, and you helped get it there.

Examining the Project’s Worth

Now that the project is complete, you may want to calculate the worth of the project. This activity involves a bit of math magic, but it allows you to predict the overall usefulness and profitability of your implementation. You calculate the time saved, the new sales earned, and the productivity gained to create a gross value of the project. The expense of the project—the total cost of the implementation—is subtracted from the gross value of the project to learn the project’s net value. From here you can create formulas to predict the value of the project over the next six months, the next year, or beyond.

Don’t get too excited by the math, however, because eventually, the infrastructure processes of the organization will absorb your deliverables as a matter of doing business. What happens is that your project’s deliverables, the wonderful things that they are, will fall victim to the law of diminishing returns. In other words, the 20 minutes you take out of a process will be consumed by some other activity.

The law of diminishing returns, sometimes called the law of variable proportions, is a rule of economics that grew from Thomas Malthus’s An Essay on the Principle of Population, published in 1798. The law states that if one factor of production is increased while other factors remain constant, the overall returns will eventually decrease after a certain point, as demonstrated in Figure 12-5. When that point is reached is difficult to say without serious analysis given to the process of a company.

Figure 12-5  The law of diminishing returns prevents exponential productivity.

Another way of viewing the law of diminishing returns is to imagine a cornfield that needs to be harvested. If you were to continue to add workers to the field, each new worker you add would have less to do than the worker added previously because there is less and less corn to harvest as additional labor is added.

To apply this law to a technical implementation, imagine a new application that allows workers to be more productive when entering human resource forms and typical paperwork. Before the application, the workers had to manually enter the forms into Microsoft Excel, save the file, and e-mail it to the human resources department. The wonderful folks in human resources would open the e-mail, open the file, and merge it into some master file.

Your application streamlines the process through a web page and pumps the information into a database. Now when users within the company need to complete insurance forms, request days off work, request new ID badges, or deal with any other HR-related issue, they can complete the process through your company’s intranet.

The productivity of this application allows the processes to be faster, better, and easier to complete. However, this level of productivity will not affect other areas of the workers’ roles in the organization exponentially. It will allow for additional time to complete other work, but the additional time gained does not continue to grow on, and on, and on. Eventually, productivity reaches a plateau, and the law of diminishing returns reigns.

Third-Party Review

You can also have a third party analyze the before-and-after processes of an organization. For example, imagine an implementation of a special mobile phone app in a manufacturing environment. The goal of this project is to shorten the process a forklift operator must use to deliver a pallet of product to a delivery truck.

In this example, workers pick up pallets of the goods the company manufactures and then move the pallets to the trucks that will deliver the product to the stores and merchandisers. The problem this project resolves is that workers, after dropping off their pallets in the delivery trucks, have to drive the forklift back to a central base to get their next assignment of the product to be loaded on the trucks.

The project created an app that sends a message to the forklift operator on the floor with instructions on the next product to pick up and deliver to a specific truck. The process has been improved; the worker does not have to return to the central base. Additionally, the pallets, which are wrapped in plastic, have a quick response (QR) code that the worker can scan from the forklift to log the goods that are actually placed onto the delivery truck. All steps within the process are logged and can be analyzed from the start of the process to the end of a work shift.

A third party could evaluate the productivity before and after the implementation. The process analysis would allow the consultants to track the amount of product moved per work shift to predict the average amount of productivity before and after the implementation. That information can then be analyzed and tweaked, and the original project deliverables can be adjusted in a new project to streamline the process again.

To complete the project, the information gathered by the completed process would be analyzed and reviewed internally or externally. The review would allow the company to see a true ROI and productivity gained on the implementation.

Far too often, organizations don’t invest in the time to validate the promised benefits of the project. The verification of the benefits is needed not only to show the ROI for the current project, but to afford success in future projects.

Obtaining Final Sign-Off

Once you’re satisfied with the project deliverables, you will need to move on to the transfer of ownership of the project. You, the owner of the project, will release it to the organization so that the deliverables may go into production.

Using a Project Transition Plan

Some organizations rely on a project transition plan to help ease the transfer of the project deliverables from the project manager to the operations of the organization. This plan defines several things for both the project manager and the organization:

•   Transition dates  There must be either a defined date for the deliverables to be transferred to the organization or a description of the conditions for the deliverables to be moved from the management of the project to the management of operations.

•   Ownership  Projects are temporary endeavors that must eventually come to a close. When the project is completed, and a set of deliverables has been created, someone must now be responsible for the management of the deliverables. The transition plan defines who owns the project deliverables and who is responsible for the maintenance and upkeep on the deliverables.

•   Training  For IT projects, it’s typical for there to be some training between the project team and the support team of the deliverable. The project team should train the recipients of the deliverable how to use and maintain the product. This can be done through training manuals, train-the-trainer sessions, hands-on exercises, or a combination of knowledge transfer events. Training can also include training the end users through traditional instructor-led training, web-based training, or one-on-one coaching.

•   Service-level agreement  A service-level agreement (SLA) is a contract for support and service of the solution a vendor provides to the customer. Depending on the type of project and deliverable, the vendor may offer an SLA. The extended support usually requires that the project team and the operations team work together as the new technology is implemented so that the operations team can learn from the project team about the project deliverables and implementation. The terms of the SLA can be negotiated as part of the project contract or through a separate contract and negotiation activity.

•   Warranties  If the project was completed by a vendor for a client, there may be some warranty information about the project deliverables. The warranty should be detailed in the project contract and discussed during the operation transfer. It’s ideal to discuss what the warranty will and will not provide early in the project so that there are no surprises when the client needs to enact the warranty.

Your organization may have other details of the transition plan, such as what’s to happen to the project team members or other resources on the project—such as equipment and software. The project transition plan can be updated based on changes within the project, but unlike other project management plans, this plan requires both the project manager and the recipients of the deliverables to be in agreement with what the plan promises.

Obtaining Client Approval

The client, whether that be the end user on a workstation or an administrator in a behind-the-scenes release such as a new server installation, will accept the project using one of two methods: informal or formal. You need validation of the deliverables, ideally through a formal process, but there needs to be a signal of acceptance of what’s been created for the project customers to allow the project to formally close.

Informal Acceptance

The informal acceptance does not include a sign-off of the completion or even the acknowledgment of the deliverables. An example of the informal acceptance is a project that ends on deadline whether or not the deliverables are finished—for example, a project to organize and build an application for a tradeshow demo. The tradeshow will happen regardless of the completion of the project.

Another example is a project that creates a deliverable that doesn’t require additional testing to prove the implementation. Imagine a short-term project to replace all of the printers in the organization with newer models. The implementation of the new printers is obvious. You’ve configured a script to install the printer driver on all of the workstations in the network to automate the end-user installation. All of the print jobs are controlled through a central printer server, so the end users experience little impact from the implementation other than their print jobs come out of a new print device.

Formal Acceptance

The formal acceptance of a project’s deliverables is a process completed by the client of the project and the appropriate members of the project team. This is the preferred method of client acceptance. These acceptances are contingent on a project acceptance agreement. The project acceptance agreement is typically written very early in the project timeline and in alignment with the defined project deliverables. The document clearly explains what qualifies for an acceptance of the deliverables. Project acceptance agreements are typical of application development projects and often consist of a checklist of the required features of the project.

The client and the team members will test the deliverables against the acceptance agreement to confirm that the deliverables exist. The sidebar “Sample Application Development Acceptance Agreement” shows an example.

Shutting It Down

When the project work is done and the customer has accepted the project deliverables, it’s time to shut it all down. This means you’ll need to decommission any project hardware, software, and other tools the project utilized. You’ll need to confirm that security permissions and access to resources have been revoked as needed, and you’ll release the team from the project according to the project management plan or the resource management plan.

Shutting it all down, especially in a predictive project, likely includes getting feedback from stakeholders, archiving project documentation for future usage, and generating a final project report. Agile projects may have some documentation to archive, but recall that agile projects don’t document as extensively as predictive projects do. Agile projects need to release the project team and secure resources.

Post-Project Audit

At the conclusion of the project and before the final project report is submitted, a project manager should complete an audit of the success of the project. The purpose of the audit is to analyze the completed project, the effectiveness of the project team, the success of the project, the value of the deliverables, and the overall approval from the clients. The audit can become part of your lessons learned documentation. This audit can be financial and provide budget reconciliation, and it may lead to creation of a final project report on the project’s overall success.

This audit must answer the following questions:

•   Was the project vision achieved? Remember when you first created the vision of the project? That vision may have changed as the project evolved. The first question should answer if the project accomplished what its original intent was. If the project did not, explain why. Projects have a tendency to change and develop from the concept to the creation—sometimes for the better.

•   Was the project on track from start to finish? Hopefully, the project was able to stay on plan, on time, and within the allotted budget. If the project wasn’t able to stay within the bounds of any of these areas, explain why. Sometimes the scope changed, the resources flexed, or the expenses of the project were not predicted as accurately as they should have been. This should be an honest reflection of each side of the project triangle (scope, time, and budget).

•   Did the project create a recognizable business value? The deliverable of the project should be to make an organization more profitable in its streamlined process, attract more sales, or gain productivity. This business value needs to be identified and proven to show the ROI of the project.

•   Can you share the knowledge? Some organizations have a project management system in place that requires project managers to report on their methodology and how it worked for them, or what they may have done during the project to improve the process. These adjustments that you make during the implementation need to be shared so that other project managers within the organization may benefit from your insights.

The post-project audit is an activity that far too many project managers skip. Don’t ever skip it. It is an extremely valuable process that will help you become a better project manager. In addition, it is an excellent method for reporting on the work you’ve completed and the value you’ve added to an organization. You may choose to use this report as leverage in negotiations for future projects.

Creating the Project Closeout Report

As with every other phase of the predictive project, documentation is required. The good news is that the final documentation of the project does not have to be an in-depth novel of all of the work completed. If you have completed cumulative progress reports throughout the project, consider the final report one last cumulative record with a few extra ingredients. The collection of all of the cumulative reports may serve as a final record of each phase’s work with a few extra parts. You will need the following:

•   The project vision statement that introduced the project

•   The project proposal that you may have used to sell management on the idea of the technical implementation—or the supporting information for the project that was assigned to you

•   The scope statement

•   The statement of work

•   The project schedule

•   The WBS and the PND

•   Any Project Change Request forms that were approved (some project managers may choose to include the denied Project Change Request forms to verify why the request was not included in the deliverables)

•   Variance reports

•   All communication relevant to the project deliverables (some project managers include all memos, letters, and e-mail in the report)

•   Total cost of the project and the calculated value of the implementation

•   Scope verification agreement

•   Post-project audit report

Evaluating Team Members’ Performance

In many organizations, a project manager is called upon to review the work of the team members who were involved with the project. This evaluation is a serious process that may impact their salaries, their jobs, or their opportunities to advance within the organization. Your organization may have you complete a form on your own, conduct an interview with each team member and the immediate manager, or hold a private meeting with the team member’s immediate manager to discuss the work.

Whatever method is invoked, use caution to be accurate, fair, and professional. This is another reason why the project manager requires the amount of documentation they do throughout the project. The evaluation process, formal or informal, accomplishes three goals, as shown in Figure 12-6. The evaluation includes the team member’s contribution to the project, their ability to work with the team, and their commitment to quality.

Figure 12-6  Team member evaluations are serious reviews of their contributions.

Declaring Victory

At the end of the project, you’ll have a fairly good idea of whether the project is a victory or a failure. A project is a victory if you have completed the project on time, on scope, and within budget and the project has resulted in the quality deliverable that was expected. A project manager and the project team should take measures throughout the project to ensure that the vision of the project is being worked toward and achieved. Think of any skyscraper. It didn’t start out as a two-story building and then get switched midway through construction to a high-rise instead. The same is true in your project management skills: by knowing and recognizing the vision of the project, you constantly check that the work being completed is moving closer to the desired results.

Declaring Failure

No one likes to fail. Unfortunately, some projects can make the project manager, the project team, and all associated parties feel like failures. How many projects are started, stopped, and rearranged, only to complete the cycle again and again without ever getting anywhere near the projected deliverables?

For a project to be a success, it must include these things:

•   A vision of the project’s deliverables

•   Adequate skills by the project manager

•   Adequate skills by the project team

•   Enough finances to provide for the resources to complete the implementation

•   Time to complete the work to produce the deliverables

•   Change management to protect the project scope

•   Commitment from the project manager, project sponsor, the project team, and management

Without these elements, a project will have a very tough, if not impossible, time succeeding. At some point in a doomed project, the team, the project manager, and management may become so disgusted by the lack of progress that the project needs to be written off and put out of its misery.

In these instances, the project ceases to exist. The attempted implementation is a failure, and it’s a general unhappiness for everyone. If you find yourself in this situation, and hopefully you will not, look for an understanding of why the project failed. Evaluate the project requirements, the finances, the talents of the team, and the available time. Evaluate your own performance and the performance of your team. Learn from the mistake and become a better person because of it. As Thomas Edison said, “I have not failed. I’ve just found 10,000 ways that won’t work.”

In other instances, the project may be cancelled not because of a lack of leadership, finances, or time, but because of a new influence on the project. Examples include the following:

•   A better, cheaper technology is released.

•   A better solution is discovered within the current project.

•   The need for the deliverables has been eliminated by the client.

•   The organization has changed its focus.

•   The organization is experiencing financial strains.

•   The organization has been absorbed by another organization.

Regardless of the project status as a success or failure, the project manager must create a final project report so that management may review the work of the project. Scope verification and an audit of the project up to the point of the project’s cancellation are needed.

Cheers! Celebrating Victory

At the end of the project, give congratulations and kudos to the project team, the project sponsor, and anyone else who helped make the project a success. It is necessary to celebrate the victory of a project and reward the team members for their commitment and hard work. Hopefully, especially if you want future projects to be a success, your organization will spring for something elaborate and in proportion to the project you’ve completed and the success of the victory.

The team members that you’ve coached along have formed friendships and trust among themselves and hopefully with you. This group of individuals has worked hard day and night for you to make you look good and make the project a success. Reward them! Offer tickets to an event, take the team to a fancy dinner, go out dancing, or offer individual rewards that the team members can enjoy on their own such as gift certificates or cold, hard cash. The point is, reward them, appreciate them, and they’ll come back to work with you again and again.

CompTIA Project+ Exam Highlight: Closing the Project

You can expect plenty of questions about closing projects on the CompTIA Project+ exam. Project closure, while often short in duration, is one of the most important process groups on your project. Also, remember that while the focus of these closing processes is often on the final stage of a predictive project’s life cycle, you can also close each phase of a project. Project closure is about the customer accepting the project deliverables and benefits, finalizing the closure of the project, and then archiving the project’s lessons learned, documentation, and supporting details as part of the organizational process assets.

2.5 Explain the importance of activities performed during the closing phase  The CompTIA Project+ exam outline has one specific objective for closing out the project. During project closure, you’ll evaluate the project, confirm validation of deliverables, and generate a final project report. Closing out the project also includes getting feedback from stakeholders, budget reconciliation, and archiving the project documentation for use in future projects.

The transition plan, sometimes called the integration plan, defines how the benefits and deliverables of the project will be transitioned from the project team and integrated into the operations of the performing organization. The plan defines who owns the project deliverables and who will be responsible for the maintenance and support of the deliverables. The plan also defines when the transition from the project to operations will happen and how the recipients of the deliverables will be trained. The transition plan should also define any terms for extended support and warranties of the project.

Agile projects also follow some rules when it comes to closure. Agile projects finalize the product for operational transfer and product release with the product owner, and they complete any final tasks to shut down the project work. These final tasks can be decommissioning hardware and software, providing insight to what items may not have been completed in the product backlog for future projects, and perhaps providing some ongoing support to the product that’s been created for the customer.

Formal project closure is important, because it defines what the project has completed, and the customer signs off on the acceptance of the project deliverables. It confirms that the project deliverables, objectives, and requirements were met—and in some cases, such as project cancellation, that the project deliverables, objectives, and requirements may not have been achieved. Formal project closure also allows the project manager to formally close project contracts, release the project resources, and complete a post-project review of what went well or poorly in the project.

The closing processes don’t happen just at the end of the project. You can use the closing processes at the end of project phases or stages, at milestone completion, and should the project get canceled. Most often, however, the closing processes are completed at the end of each project phase in the project life cycle and at the end of the project. On smaller projects, the project manager may elect to do the closing processes only at the end of the project. On larger projects, it’s often better to close each project phase formally to ensure with the project customer that all of the requirements of the phase were met before moving forward. Should a project get canceled, the project manager should formally close out the project and document why the project was cancelled, what was created up to the point of the cancellation, and how the project performed.

4.1 Summarize basic environmental, social, and governance (ESG) factors related to project management activities  Throughout project planning and execution, you’ll need to address the environmental, social, and governance constraints of the project. In project closing, you’ll need to confirm that the project adhered to these requirements. Failure to meet the ESG requirements can result in fines, penalties, or loss of business value and can adversely affect the environment where the project took place. As part of project closing, it is essential to confirm that the deliverables the project created conform to the ESG requirements of the project before the deliverables go into production.

Chapter Review

A successful project manager has to complete many tasks to finish any technical project. As the project is winding down, you must conduct an analysis of the critical path and the resources assigned to the path to ensure that the work is completed and resources are committed. You have to be seen, be available, and be in the trenches with the project team to keep the project momentum moving toward the deliverables.

Once the project work has been completed, the project manager, the project sponsor, and the project team need to review the work for quality, snags, or technical issues that may have popped up in the final tasks. Any issues need to be immediately addressed and resolved. You can evaluate the project’s worth to predict the ROI of the product; of course, you’ll need to consider the law of diminishing returns as the calculations are made.

Once the work has met the satisfaction of the project manager and client, the client accepts the project either formally or informally, depending on the type of work completed. Some projects may require you and members of your team to work with the client to ensure the client acceptance agreement criteria are met as defined in the early stages of the project.

Once the client has approved the work, you must create a final project report that includes all documentation and facts from the project lifespan. An audit of the work and the success of the project need to be included in the plan. Ultimately, the final project report must answer whether the project vision was met and if the overall health of the project is excellent or otherwise.

At the project’s finale, you may determine from the evidence of the goods produced if the project was a success or a failure. Regardless of the project evaluation, you should create a lessons learned document for your own future success, but also for the success of others.

You should review the project together with the project sponsor and focus on the quality of the work, a review of the budget at completion, and the success of the effort. The project sponsor may want to work with you on how you can manage your next project better, or what you did successfully on this implementation.

Finally, once the project is officially finished, the team is relieved, the client is satisfied, and recognition is given. A celebration is in order for the project team, the support of management, and the hard work and commitment poured into the project vision by you, the successful project manager.

Exercises

These exercises allow you to apply the knowledge you have learned in this chapter and are followed by possible solutions. In these exercises, you will be presented with a scenario of a project for a fictitious company. You will then be asked a series of questions about the project.

Exercise Solutions

The following offer possible solutions for the chapter exercises.

Questions

1.   Of the following, which is the greatest danger to a project as it nears completion?

A.   The project scope changes.

B.   The project manager eases off of the project.

C.   The budget has a surplus and the project manager doesn’t know what to spend it on.

D.   The project sponsor eases off of the project.

2.   What method should a project manager use to ensure that a project maintains momentum in the final stages?

A.   Host a celebration for the project team.

B.   Discipline any team members who stray from the project.

C.   Become available to the project team.

D.   Get in the trenches and work with the project team.

3.   Of the following, which is a reflection of the project manager’s ability to lead?

A.   The project manager attends regular meetings.

B.   The project manager speaks with team members weekly.

C.   The project manager leads by example.

D.   The project manager speaks with management on a regular basis.

4.   Of the following, which method is a likely solution to successfully finish a project that is near completion but may be lagging?

A.   Ask for additional time to produce the deliverables.

B.   Ask for additional funds to hire outside help.

C.   Ask the project team to work additional hours.

D.   Remove parts of the project deliverable for delivery at a later date.

5.   Of the following, which is not a suggestion to quickly and accurately complete a project on schedule?

A.   Think clearly, but quickly.

B.   Create a visual marker to represent completed work on the workstations.

C.   Check for quality as applicable within the final phases.

D.   Ask for volunteers to work through the night and into the next day on an implementation.

6.   What information can an IT project manager learn from completed tasks in the project?

A.   If the tasks have been lagging, it is a sign that the future tasks may lag as well.

B.   If the same group of team members has completed the tasks, they may be bored with the work.

C.   If the same group of team members has completed the tasks, they may need to be replaced by other team members to keep the team excited.

D.   If the critical path has had tasks that can begin in unison (SS), the remaining work units may have SS tasks as well.

7.   Why should management reserve be examined near the end of a project?

A.   To determine the cost of the errors on the project

B.   To determine the additional revenues that are left in place

C.   To determine the amount of time that may actually be used, if necessary, for the implementation

D.   To determine the amount of time that may be used in addition to the allotted time for the remaining work units

8.   You are the project manager for your organization and your project is coming to a close. What project management component will guide you through the process of transferring the project deliverables to operations?

A.   Transition plan

B.   Transfer plan

C.   Project management plan

D.   Operational plan

9.   What must the project manager do before the customer accepts the project deliverables?

A.   Inspect the project deliverables for quality.

B.   Inspect the project deliverables for missing components.

C.   Present the invoice for the project completion.

D.   Assign the project team to new projects.

10.   What method can an IT project manager invoke to ensure that third parties will reach 100 percent completion on a project?

A.   Retain payment until the integrator reports the project is finished.

B.   Retain payment until the project manager approves the deliverables.

C.   Ask the vendor to add a few extra tasks to complete the project.

D.   Assign the final tasks in the critical path to an internal project to ensure the project is finished as planned.

11.   When should a project manager inspect the project for quality?

A.   Throughout the implementation phase

B.   During the final task

C.   In the last 1 to 3 percent of the implementation phase

D.   When the project is complete

12.   What should a project manager do if they encounter a flaw when evaluating the finished deliverables of a project?

A.   Note the flaw and add it to a to-do list.

B.   Reassign the project to another team member.

C.   Address the flaw immediately to have it resolved.

D.   Complete a Project Change Request form.

13.   What is the purpose of calculating a project’s worth?

A.   To determine if the project was worth doing

B.   To determine if the project manager did their job properly

C.   To determine if the project was an expense or an investment

D.   To determine the ROI of the project

14.   What is the law of diminishing returns?

A.   It is a law of economics that states all process cannot be improved infinitely.

B.   It is a law of economics that states if one area of profitability increases, the other areas of an organization must increase also to produce higher profits.

C.   It is a law of economics that states if one area of production is increased while other factors remain constant, the overall returns will eventually increase as well.

D.   It is a law of economics that states if one area of production is increased while other factors remain constant, the overall returns will eventually diminish.

15.   What is the purpose of having a third party review the completed project?

A.   To ensure the deliverables were worthy of the budget and time required to produce them

B.   To ensure the deliverables are of quality and to second-guess the project team

C.   To ensure the deliverables are of quality and in alignment with the project scope

D.   To ensure the project manager did their job as defined in the project plan

Answers

1.   B. Some project managers make the mistake of easing off a project as it concludes. The inverse is what is really needed, because project team members have a tendency to ease off of the project as well.

2.   D. A project manager should always be available to the project team, but getting in the trenches and helping the project team as much as possible to complete the project inspires a team to work harder and commit to the conclusion of a project.

3.   C. A project manager who sits behind a desk and manages the team through memos is not as effective as a project manager who gets involved with the team members and helps them succeed. Leading by example is never a bad idea.

4.   C. When a project is lagging behind on tasks in the final stages of a project, a project manager may need to ask the project team to work extra hours to complete the project on time.

5.   D. Asking team members to work an excessive number of hours without rest can be wasteful. Team members need a break from the project to be productive and useful.

6.   A. History of performance is a good indicator of what future tasks may bring. If the project manager can see that prior tasks have been lagging, they can predict that the remaining tasks may also lag. This can allow the project manager to stress the urgency that these final tasks must be completed on time. The project manager may also elect to reassign resources, add resources, or join the effort himself.

7.   C. A project manager should evaluate the remaining time in management reserve near the end of the project to determine the whole amount of time available for the project. Just because there is additional time in reserve does not mean that the project manager should assign the time to remaining tasks; it means the project manager can calculate the room for error.

8.   A. The project’s transition plan defines how the project will be transitioned from the project into operations. It defines the ownership of the project deliverables, when the transition will happen, how the recipients will be trained, and what type of extended support is offered. It also offers a review of the project’s warranty information.

9.   A. Before the customers accept the deliverables of the project, the project manager must inspect the final product for quality. This inspection keeps mistakes out of the hands of the customers.

10.   B. A project manager can withhold payment until they have approved all of the work that the vendor was assigned to complete. The project manager should, however, take time to review the work as soon as the vendor reports that the work is done. It is unprofessional to use this leverage and then take weeks to review the submitted work.

11.   A. A project manager should work throughout the project to ensure quality in each phase of the implementation.

12.   C. When a project manager discovers a flaw in the implementation during the review, the project manager must address that flaw immediately to rectify the problem.

13.   D. The project manager and management should calculate the ROI of the project to determine if the budgeted cost and the actual cost outweigh the benefits of the project’s deliverables. Hopefully, if everyone has done the proper research and preproject calculations, the ROI will be excellent.

14.   D. The law of diminishing returns predicts if one area of production increases, but the other areas remain the same, the overall returns will eventually diminish. For an IT project manager, that means the productivity and the profitability gained by the implementation will eventually reach a plateau because the remaining factors in production have not been improved.

15.   C. In some instances an organization should hire a third-party consultant to review the work of the project to determine whether the deliverables are of quality and are in alignment with the project scope.