ProjectClosure

THE COMPTIA IT PROJECT+ EXAM TOPICS COVERED IN THIS CHAPTER INCLUDE

• 4.1: Recognize and explain the value of conducting a comprehensive review process that identifies the lessons learned and evaluates the planning, organizing, directing, controlling, execution, and budget phases of the project, identifying both the positive and negative aspects in a written report.
• 4.2: Recognize the need to plan to transfer the project deliverable to support and maintenance and to budget for these resources including help desk.
• 4.4: Recognize the need to obtain formal customer sign-off of the project deliverable and hand off to the customer.
• 4.5: Recognize the need to complete project documentation, secure approvals , and archive/store appropriately.
• 4.6: Recognize the need to close out contracts and sign-off for vendors .

Finally, your project is winding down and the end date is in sight. But don t get too excited, your job is not over yet.

A project does not magically end when the last deliverable on the project schedule is complete. Your project plan should also include all the tasks required to transition the project to an ongoing operation. A good project manager follows processes to formally close the project. The good news regarding these additional tasks is that much of the work you do during project closure will help you do a better job managing future projects.

Project closure activities apply regardless of the reason the project is ending or at what point you are at in the project life cycle. Even if your project is canceled , there is still a closeout phase.

Contract closeout is the completion of all items documented in a vendor contract and the formal acceptance of all vendor work.

Administrative closure involves finishing and archiving project documentation, obtaining formal sign-off from the client, conducting a comprehensive review of the project to document lessons learned, turning over the project to operations and maintenance, and releasing project team members to their functional organizations.

Types of Closure

Project closure is the activities required to formally end the project work. This stage often includes formal acceptance of the project; however, a project doesn t always have its success and completion criteria met in order to be concluded. A project might end for other reasons.

Canceled or postponed A project may be canceled or postponed indefinitely, whether or not the products and results have been completed. A project that s going nowhere may be hard to cancel for those involved, but management will eventually make the call. Projects that should rightfully be postponed if the technology just isn t there yet or the funding isn t available also fall into this category.

Plan not approved The project plan is not approved, and instead of sending you back to the project management drawing board, the project is simply canceled. Projects that are proof of concept could easily fall into this genre ; management simply feels that the project has untenable deliverables. A proof of concept undertakes to prove that a specific activity can be done or an idea can be accomplished. If the concept is not feasible , the project is not approved to move forward.

Resources not available There are not enough resources available to complete the project. You have run out of money, hardware, people, or some other resource, and you have no choice but to conclude the project. This situation may arise due to poor estimating, or you may find that your resources are being diverted to another project with a higher priority. Either way, if you are not getting the resources you need, the project will end.

Note

If a project is canceled or the project plan is rejected, you may be within the planning process, well ahead of project implementation. Even then, you would still run through the closing elements of the project, because the metrics you developed might prove useful in another project.

There are two major processes in project closure: contract closeout and administrative closure. Let s start with the process for closing out vendor contracts.

Contract Closeout

When a vendor completes any portion of your project work, project closure needs to deal with the vendor contract. Contract closeout is the process of completing the terms of the contract and documenting acceptance. Even if the procurement department is managing the contract, you will need to provide information regarding the acceptance of the vendor deliverables.

As we discussed in Chapter 9, you should perform quality control activities on vendor deliverables as you receive them and provide feedback regarding acceptance throughout the project life cycle. Any rework you require of the vendor should not come as a big surprise at the end of the project.

The procurement department needs to provide the vendor with formal written notice that the deliverables have been accepted and the contract has been completed. This letter will more than likely be sent based on your approval, so make certain that all vendor deliverables have met all required testing and acceptance criteria before you agree to have procurement release the vendor. Once the contract has been completed you may have no recourse if you find missing deliverables or poor quality work.

You should retain a copy of any completed contracts to include in the archives, which we will discuss later in this chapter.

Contract closure only applies to some projects, but all projects should go through the administrative closure process.

Administrative Closure

Once the project work is done, you may be tempted to quickly move on to a new assignment. But you still have important work to finalize your project. Administrative closure involves gathering and centralizing project documents, obtaining sign-offs, and communicating the finish of the project.

Some administrative work is tedious , but without it you have no point of reference for any future questions that may arise regarding why this project was authorized and what it accomplished.

Administrative closure also provides a reference source that can be used to improve the success of future projects. There is no reason for another project to make the same mistakes or recreate a useful tool or template that is already available.

We are going to take a closer look at several aspects of administrative closure: project archive, formal acceptance, comprehensive review (often know as lessons learned), turnover , and release of team members .

Project Archive

You have created a lot of documentation over the course of your project, and it was organized to fit your needs for overseeing the project work. One of the benefits of all this project documentation is that it can be used to help you or other project managers on future projects. Your planning documents can be a reference for cost and time estimates or used as templates for planning similar projects. But that can only happen if you create a project archive.

There are a variety of ways to create a project archive. Some organizations have a room dedicated to the storage of project binders for completed projects, and this area may even be set up like a mini-library where project documentation may be checked out. Your PMO may maintain a centralized project archive. If you have a project library or a centrally maintained archive, you should check what the guidelines are for documentation and how to organize it.

Even if your organization has no formal rule regarding project archives, you should create a project binder. Not only will the binder be a good reference tool on future projects, it will facilitate answering any questions you receive about your project s history. Even though you may be tempted to just empty your project files and shove all that paper in a binder, put some thought and effort into organizing the data so that it can be easily retrieved.

Electronic archives are also becoming more popular. Your organization may have a secure file server where it stores project documentation.

One of the documents that will eventually be placed in the project archive is the final acceptance and sign-off for your project.

Formal Acceptance

By this time, you should be very familiar with the importance of doing reviews with stakeholders to get sign-off on major deliverables or milestones to move from one phase to the next . If you have followed this process throughout the project, formal acceptance of the project itself should be easy.

After completion of the final project deliverable , you should bring the stakeholders together for one last formal review of the project. The purpose of this review is to officially declare the project work complete by obtaining stakeholder acceptance and sign-off on the project

Depending on the policies of your organization, there may be a specific format or template for formal project sign-off. Make sure you are aware of all the signatures you need to obtain. On some projects, you may need just the signatures of the sponsor and the client; for other projects you may need a signature from every work group impacted by the project. The formal approval document with all required signatures is your paper trail of project acceptance and should be included in your permanent project archive.

You can clear up any unanswered questions or issues regarding the project. You want everyone to walk away from this review with the agreement that the project is complete and has met the requirements.

Although you should have already communicated to the stakeholders changes to the project plan, some of the players may not remember all of these changes. You should cover any changes to requirements or scope to make sure everyone is on the same page regarding expectations of what the project will do. This is of particular importance if there was a decision to remove features or functionality from the original requirements.

Occasionally, stakeholders may panic as a project draws to a close and ask for all sorts of additions. If project closure were postponed until the project had everything it needed, most projects would never end. This is why obtaining the necessary approvals for changes, communicating how changes will be implemented, and updating your project plan is so important. The best defense against any last minute concerns is to continually focus on what stakeholders requested and agreed to in the project plan.

The stakeholders should also be made aware of which groups are responsible for the ongoing operation of the system. We will talk more about these people later in this chapter when we get to project turnover.

One of the last major accomplishments for you and your project team will be a comprehensive project review and documentation of lessons learned.

Comprehensive Review (Lessons Learned)

At the end of your project, you should conduct a comprehensive review to assess the good and the not so good aspects of the project. During this process, you evaluate each phase of the project in order to determine which things went right and which things could have been improved. This kind of review provides you an opportunity to improve your overall project management quality on the next project and benefits other projects. The most critical thing to derive from an end of project assessment is the lessons you learned from the project. You want to assess what went wrong and why, not so you can point fingers at the guilty parties, but so that you can do better next time by avoiding the pitfalls you encountered this time. Lessons learned is something project managers like to avoid working on because they re afraid of backwash on the job they did, but the idea is to gain knowledge about how to better manage projects.

If you are managing a cross-functional project, make sure that the review covers both the technical and nontechnical components of the project. Managing a project with deliverables from multiple disciplines has unique complexities. Even though you may be more interested in documenting what happened during development and testing, information on marketing and sales is equally important.

The following subsections describe some of the areas in which you ll concentrate your review process. All of the information generated can be kept in a single document, or you can choose to write a document for each category. Obviously, the larger the project, the more documentation you re going to need to create for any given category. All of this documentation will go into the project archive, whether it is electronic or paper in form. Whatever format you choose for capturing the output from the review process, keep in mind you will need to summarize this data in a written report, which we discuss later in this section.

Planning

When reviewing the planning process, ask yourself how well the project was planned in general. Were the tasks , activities, and phases well thought out and orderly, or did you have to backtrack to fix some things that you originally had set up in the wrong order? When you have to backtrack on things like this, you can get into a situation where you actually can t go back and fix, or at the very minimum precious time is taken up getting back to the place you can continue from.

Also, you should pay attention to the project plan itself, evaluating its complexity, the number of milestones, and whether you filled it out correctly. Project plans can be laborious if they re too detailed and useless if they don t include enough information.

Organizing

How well did the overall project come together? When you examine the organizational characteristics of your now-finished project, you re interested in more than the project plan itself. Did the team members come in for their various tasks at just the right time, or did some of them have to wait for something else to happen before they could go to work? You should examine how well processes went into place and where you can improve next time. Things like equipment burn documents (documentation that stipulates the steps involved in the installation and configuration of computing equipment), network protocol assignments, coordination of physical equipment installations, and other orchestrated functions should be examined closely to see how you could improve them the next time.

It s especially critical to pay attention to the details of any software development involved in your project. Examine the coding, documentation, and testing of the software development. Pay close attention to the development tools used to see whether they were adequate for the process. Did the code repository system you used to store developed modules meet the developer s needs? Further, was the choice of development language appropriate for the project? Often, developers have pet languages that they ll use for all their work, but some projects may be better suited for a different language.

Executing

The executing phase deals with bringing performance in line with your plans. Things such as team development, stakeholder relationships, performing according to schedule and cost baseline, information distribution, and vendor contract administration happened in this phase.

When examining this phase, you should take a look at things such as vendor relationships and how well they worked out, the value of team meetings in maintaining team member linkages and revolving issues, and effectiveness of stakeholder communications.

You may ask yourself a number of other questions about the execution phase. Were the team meetings effective for team communications and issues resolution? Did the weekly progress reports from the team members provide you with accurate and timely data to assess project performance? Did project status reports paint a clear picture of project progress? Was vendor progress adequately monitored ?

Your focus here should be on looking at where the project worked flowed smoothly versus where problems or issues you did not expect arose.

Directing

Examine your work. Take a look at how well the project was directed through its steps. Like a movie director helping the actors play out the various shots, you should have been there for your team members at all points of the action. It s important to pay attention to the places where the project got off track and how you got it back on. Perhaps you can make adjustments to your next project to avoid such scenarios.

Look closely at the places where team members fell behind schedule. Determine whether what you had to deal with was personnel management or a technical issue. Defining people issues can help you work more closely with team members in the future.

Controlling

Controlling differs from directing. When you have a finalized project plan and are making sure that the deliverables you re creating meet the metrics you set down during requirements definition, you are controlling the project. For example, a piece of code that does a calculation should meet a success criterion that clearly indicates whether the code works as needed and expected. The controlling aspect of the project looks at metrics. When assessing the project, you might ask, How well were the metrics formulated, and did they meet expectations?

Don t forget that during the planning stages you pinpointed the risks to the project. Did any of those risks materialize while in the controlling phase? If so, how did you spot them and then deal with them? Risk monitoring and control is an important facet of any project.

Budget

This is an important end-of-project category. First, take a look at the variances that occurred during the project to see if you can match them to a reason for their occurrence. Spotting the reason could potentially help avoid the same thing next time.

Also, you should evaluate the project budget compared to the way that the corporate budget outlined your budget categories. You do this to make sure that you effectively used the money the way that the company intended you to. Chances are you robbed Peter to pay Paul in certain cases, and this is acceptable, but you need to reconcile that with the company s budget.

Prepare reports that represent what was spent, on what, and where your closing budget stands. You should also show the hours spent on the project compared to the salaries of the individuals working on various tasks.

Preparing a Written Project Assessment

A finalized project assessment needs to be prepared and distributed to all of the project stakeholders. The size of the project and the amount of feedback provided by the project team will dictate how large the report should be; a small project might only contain a paragraph or two for each section, while a large project might wind up being a fairly comprehensive document of many pages.

As with any other project documentation, you should check to see whether your organization has standards or a template for documenting lessons learned. If you have no specific guidelines or template, organize your material around topics such as the project phases discussed earlier. For each section, cover the positive aspects, the negative aspects, and plans for improvement.

Real World Scenario ”Involving Project Team Members in Lessons Learned

Although you can evaluate the various components of the project on your own using the project plan and the project results, to get a more comprehensive lessons learned you should involve the team members.

One way to organize a project review session is to make the session very interactive. Let the team members know in advance which aspects of the project the review will focus on, and ask them to be prepared to contribute input on both what went well and what did not.

You should always set ground rules before you start. You want to stress that the purpose of this session is not to assign blame, but to assess the project so that both this team and other project teams can learn from your experience.

Just sitting around a conference table for several hours can get boring, so we like to keep people moving around. One way to do this is to prepare the meeting room in advance with easel paper listing all the areas of the project you want to cover, and provide each team member with a pad of sticky notes. For each topic, ask the team members to post one positive thing and one negative thing. For each negative comment, a plan for improvement needs to be included. If they encounter this situation on a future project, what would they do differently? Requiring a plan for improvement serves two purposes: it engages the team members in the review by making them part of a problem solving process, and it helps keeps those few team members who may only want to whine under control. This is not the time or place to complain about the pastry or lunch selection at a team meeting. After the team members have posted their sticky notes, you can moderate a group discussion of the items that have been posted. Seeing what others have posted may generate additional thoughts.

When you have concluded the session, collect all the easel paper to use as input for your written report.

Positive Aspects of the Project

This is the easiest part of the written report; everyone wants to share successes. Talk about what went right with the project. Provide detail regarding specific tasks that you thought went exceptionally well and why. You may also include any positive comments that customers made about the project and its progress.

It would be a good political idea to also mention positive participation from people from other departments or teams that helped you get your job done. Mentioning other departments has two effects: It reinforces the opinions of people from those departments, putting it in the back of their minds that they d like to work for you on another project. It also shows other departments that your team wasn t a force of one; you needed them to help you get your job done.

With respect to the constraints of any project, if something went particularly well, it s important to point it out at this time. If your project came in well under budget, ahead of schedule, or with an output whose quality is higher than expected, this should be mentioned in your closure document.

Negative Aspects of the Project

Project managers sometimes avoid writing anything negative about a project, but that really defeats the purpose of doing lessons learned. If you do not document what went wrong and what you would do to change the situation, other project managers are likely to make the same mistake. You have to be careful not to use this portion of the report to point fingers or assign blame. If you had communications difficulties with a particular department, stating ways you could improve the communications plan is more beneficial to future projects than stating department X was not responsive .

If your relationship with a vendor did not go smoothly, list the areas that were problematic such as deliverables being off track, or poor quality and state what you would do differently ” more frequent review sessions, more detailed acceptance testing, etc.

Describe any problems you ran into with software or hardware that you purchased ” problems that surfaced time and again and weren t a one-time thing. For example, if you had trouble with some firmware updates, software that you had to apply across a lot of the same equipment, you would mention that here. You should also talk about hardware that consistently malfunctioned the same way, regardless of the number of units you deployed.

You should also mention limitations that you encountered simply based on the constraints of the project. You don t have to come across negatively when mentioning a constraint, but it s important that readers know that if you had had more time or budget, you could ve brought in a better product.

It s important to stay away from blaming people directly, but also to not be shy about talking about processes that didn t work, promises that weren t kept, and fundamental operations that could ve gone better. The point is to clearly state what went wrong and what you would do differently in that situation in the future.

As you are writing your project report, you will also need to be implementing project turnover.

Project Turnover

When a project ends, another work group will maintain the deliverable produced by the project. The project deliverable needs to be turned over to this new team. This is not something that just happens magically; it has to be coordinated between the project manager and the operational groups that will run and maintain the new system.

For an IT project, it may be easy to think about the groups who will operate the equipment and update the system. But your project turnover may be far more involved.

Many systems involve a help-desk function. Your project schedule should include activities for developing and delivering training to the help-desk staff. In addition to making sure the help-desk technicians are thoroughly trained, you need to coordinate when this group will start taking end user calls. Typically, a help desk takes over a new system as it is deployed to the users. If the system is being deployed on a staggered schedule across multiple end user locations, the help-desk management should be involved in the development of the schedule to ensure adequate help-desk coverage as each office comes online with the new application.

Although the development of supporting documentation is part of the project work, updating the documentation is the responsibility of the individual operations groups. You need to make sure that the technical documentation reflects any changes to the project scope or requirements. All documentation should be updated to include any changes as a result of testing or other quality control activities.

If your project was cross functional, there may be user related documentation that will require maintenance and updates as the system is enhanced. If project team members were responsible for development of user documentation, you will hand off the user documentation to the ongoing operations technical writing team. User training material needs to be moved to the training department for the client organization.

If additional technical staff is required to maintain your system or provide end user support, these people may have been brought on using money from the project budget. The length of time these people are charged against the project budget should have been negotiated up front. You need to make sure that you have a written agreement as to when salary dollars or any other ongoing operational expenses are transferred to the operation budget.

Case Study: Chaptal Wineries ”Intranet and Email

Closeout of the Chaptal project is straightforward. You need to validate that all the email servers are up and running and that email is able to move back and forth between the sites. Also, you want to validate that the intranet is working and people are satisfied that the information they derive from the pages is useful and straightforward and that information that needs to be put onto the intranet by various stakeholders can be done so with a minimum of hassle.

Email You can use the Exchange Server administrator interface to validate that you see all of the sites in your organization. You pull up the administrator interface and see the California, Australia, France, and Chile sites just fine. You can also see the mailboxes that are associated with each site. Even though systems testing has validated that everything is working well, you send a couple of email items to various people throughout the organization. You include some emails with attachments to make sure that they re being transported well.

You adjust some Exchange routing metrics and are satisfied that email is moving well. While at the international sites, you visited user computers and installed the Outlook client so that users are ready to utilize their email. You now send out an email to the main contact at each site instructing them that the system is available for immediate use. You have already trained your international contacts on how Outlook works and how it interfaces with Exchange ”you feel they are prepared to handle most end user problems.

You will now enter into maintenance mode with the email system. You note in your project closeout that you have successfully concluded this step and that the system is in production. From this point forward, new additions or enhancements will be considered a new project. You interview Kim Cox and the international stakeholders to see what input they can provide relative to ways that you could have done things better. This information will go into the lessons learned component of the project.

Intranet The Chaptal intranet site pages have been developed and approved for usage. You re particularly pleased with a page that the contractor developed that allows the winemakers at the various sites to key in information pertinent to the wines being developed. Topics that are interesting to Kim will be the type of grapes used as well as the percentages of mixture of grape varieties (i.e., 40 percent cabernet sauvignon, 60 percent Shiraz, etc.). Also of interest is the specific gravity of the wine, sugar content, alcohol content, container aging (barrel and stainless steel ), and bottling and labeling information. Additionally, Kim wants to keep track of the number of barrels made as well as shipping and reseller information. The application that your intranet Web page developer created elegantly handles all of these elements in a nicely built application interface.

An additional application that Kim would like to have ”one that was not included in the purview of the original project ”would track the costs involved to maintain tasting rooms at each winery. Currently, French and Chilean wineries that provide tasting rooms for drive-up customers are rare. But Californian and Australian wineries commonly include this feature as a part of their operation. Kim would like to provide tasting opportunities at all Chaptal wineries and wants to track the costs (and revenue) of this side of the operation from site-specific levels. This will be a new project that s tied to the build-out of tasting rooms at the French and Chilean wineries. The Web page developer also created a financial tracking application that allows the various sites to report earnings and expense numbers for final accounting roll-up at the California main site. The next project you will undertake relative to Web development work will involve designing and building a full Internet site that details information about all of Chaptal s wineries from a single site. The lessons learned segment for the intranet site has a very short list. Overall Kim s quite pleased and only wishes that some expandability was built into the intranet interface so that as new wineries are acquired (she s looking at a lovely operation in the Piedmont area of Italy), they can be easily snapped into the existing infrastructure.

You prepare an end user training manual that you ll post on the intranet as well as the lessons learned documentation. You send out notice that the project is officially closed.

You begin work on your next projects: The Chaptal Internet site and the acquisition of Marcello Wineries of Piedmont.

Project turnover can sometimes be shortchanged because everyone on the project team is in a hurry to move on to the next assignment. It is your job as project manager to oversee this process and resolve any outstanding issues before you officially closeout the project.

Turnover of various aspects of the project to ongoing maintenance is also a signal to start releasing your team members.

Release of Team Members

The staffing management plan developed during project planning should have addressed any special procedures you are required to follow as part of releasing team members from the project. It is a good idea to review this document as the project starts to wind down to ensure you are in compliance with all human resource guidelines.

You should start communications with functional managers at least a month before the anticipated release date. The functional manager needs to know when staff members will be available to be assigned to a new project or functional work.

Team members may also become anxious about their status, especially if people are rolling off the project at different times. You should explain to team members that as various deliverables are completed, team members who have completed their assignments are released. Unless you are prevented from doing so by labor contract terms or human resource guidelines, provide your team members with as much information as you can on anticipated release dates.

Once all of the closure documents are complete, the project is turned over to maintenance, and the team members have been released, you can start the planning process all over again for your next project.

Summary

Although project closure involves many important activities, it often falls off the radar for many project managers. Anxious as you may be to move on to your next assignment, your current project should not just cease to exist before you complete project closure activities.

You need to complete the project closure processes whenever the project ends, whether it was successfully completed or canceled . If you are working with any vendors , you need to complete contract closure by confirming that the terms of the contract have been met and all deliverables have been accepted. Contract closure includes written notification to the vendor that the terms of the contract have been met.

Although you may find some of the tasks tedious at times, administrative closure involves several key elements. As project manager, you create a project archive in either paper or electronic format to store a copy of all project documentation. A final review session with the stakeholders is scheduled to obtain formal acceptance and sign-off on the project. The project manager also organizes and facilitates a review session with project team members to discuss all aspects of the project life cycle, both negative and positive. The output of this session is a formal lessons learned document that can be used to replicate your successes and avoid the pitfalls you encountered in your project. Project documentation such as user guides or systems manuals as well as all ongoing maintenance and support of the system need to be turned over to the appropriate operational staff. Finally, as their work is completed, you release the project team members to their respective functional organizations. Now you are ready to move on to your next project.

Perhaps the most important element of project closure is the lessons-learned element. It is here that you identify where things went wrong, how you fixed them and what youd consider as alternatives in the future. Lessons learned isnt helpful in the here and now, but its extremely useful for those who have a similar project and who will come back to yours to see what kinds of issues you ran into. If youre into protecting the future, lessons learned is an endeavor that will be very worthwhile for you.

Exam Essentials

Name the project phases included in a project closeout review. The phases included in project closeout document are planning, organizing, executing, directing, controlling, and budget.

Understand why it is important to document both the positive and negative aspects of the project. It is equally important for the success of future projects to capture both what worked on the project and what you would change.

Explain the purpose of obtaining formal customer or stakeholder sign-off. Formal sign-off documents that the customer accepts the project work and that the project meets the defined requirements.

Describe the purpose of a project archive. The project archive is the official copy of all of the project documentation, which can be referenced to answer future questions regarding the project or as a resource for other projects.

Understand the key elements of contract closeout. Contract closeout verifies that all the work described in the contract was completed satisfactorily per the contract terms and conditions. It includes written notification of contract completion to the vendor.

Know what groups are involved in project turnover . Project turnover includes any group that will be involved in the ongoing maintenance, update, or support of the system, and includes both technical and nontechnical teams .

Understand why lessons learned is such an important facet of project closeout. Often overlooked as a vital component of project closeout, a formal lessons learned endeavor can reveal much valuable information that can be used in future projects. There is no such thing as the perfect projectall projects could have benefited by something being done differently or better than it actually happened .

Realize that end user support is a part of your closeout efforts. Because youve introduced a new system, its vital that you dont simply close out the project with a There, its all done! statement. You have to be sure that the project has provided for things such as end user training, training manuals, help-desk preparations for support, and so forth.

Key Terms

Before you take the exam, be certain you are familiar with the following terms:

administrative closure	project closure
contract closeout	proof of concept

Review Questions

1. Your project is winding down and you are eager to get started on your next project, which is high visibility and could lead to a promotion. An outside company was responsible for completing several of your deliverables. There are acceptance test activities for each of these deliverables on the project schedule. The procurement manager has called you because the terms of the contract require notification to the vendor of acceptance or rejection of all deliverables be provided to the vendor in 4 days. What action should you take? Choose the best answer.
   1. You should forward the procurement managers message to the person assigned to vendor acceptance test.
   2. You need more time to complete testing, so tell the procurement manager there are problems with some of the tests results.
   3. You should confirm that the vendor acceptance testing included all aspects of the vendor deliverables and that all testing has been completed with satisfactory results. If testing is ongoing, you need to take appropriate action to ensure it will complete before the contract deadline.
   4. You can ignore the procurement managers message for now, as you should have the final test results with a week. Procurement always thinks they need an answer right away.
2. You have just left a meeting with the project sponsor where you were advised that your project has been canceled due to budget cuts. You have called the project team together to fill them in and to review the remaining activities to closeout the project. Several of your team members question the benefit of doing a lessons learned review on a project that has been canceled. What should your response be? Choose the best answer.
   1. Advise the team that part of the review time will be spent on deciding how to blame the project failure on the lack of clear client requirements.
   2. Tell the team they need to do this to be able to stay on the project payroll another week while they look for a new assignment.
   3. Inform the team that a final report is a requirement from the PMO, regardless of how the project ends.
   4. Explain that there is value both to the team and for future projects in analyzing the phases of the project that have been completed to date to document what went right, what went wrong, and what you would change.
3. Which of the following scenarios would NOT trigger the project closure processes?
   1. The project is behind schedule and over budget, but no additional resources will be provided and a request for additional funding has been denied .
   2. End user deployment is delayed due to conflicting demands on the user training staff.
   3. The sponsor advises you the project does not fit the vision of the new CEO.
   4. Your critical path resources are pulled off your project to work on a newly approved strategic in initiative
4. You are gathering documents to work on your comprehensive project review. What aspects of the project should you focus on?
   1. The review should focus on the technical aspects of the project.
   2. All phases of the project, from planning through execution should be included in the review.
   3. The review should focus on the project schedule with an emphasis on the accuracy of the original estimates.
   4. The review should be limited to the positive aspects of the project. This will help all the team members get better assignments in the future.
5. You have scheduled a session with your project team members to obtain their input for documentation of key learnings from your project. Which of the following is the most effective technique to get the information you need?
   1. An informal project team session with no guidelines will produce the most data. Encourage team members to assign responsibility for portions of the project that did not go well.
   2. Send a survey to all project team members asking them to document five successes and five failures during the life of the project. Compiling this data can produce the report.
   3. Facilitate a session with the project team members structured around the project phases. For each phase ask team members to identify the successes and failures. For any item that did not go well, ask for a recommendation of what to do differently in a similar scenario.
   4. As project manager, you have the best perspective on what went right and what went wrong on the project. A review is not needed to complete an accurate report.
6. What is the purpose of a formal sign-off at the conclusion of the project work?
   1. A sign-off allows the project manager to start a new assignment.
   2. The sign-off finalizes the client agreement that the project team is no longer accountable for this product.
   3. The sign-off is the trigger for releasing team members back to their functional organization.
   4. A formal sign-off indicates that the project meets the documented requirements and the client has accepted the project deliverables.
7. You are transitioning a project to maintenance/support mode when you discover that the training for the help-desk staff to support the end users has still not been done. During the project deployment, all questions were funneled through project team members. What is the best course of action to take at this point?
   1. You should work with the functional managers to retain the team members currently taking end user calls until the help-desk staff is trained to take the calls.
   2. This is an operations issue, not a project issue. The operations manager will have to deal with the impact of the decision to delay training.
   3. The client should be notified that until further notice, all questions regarding the new application should be routed through the local office supervisors. The supervisors should call the help desk only as a last resort.
   4. You should shut down the new application until the help desk is prepared to support the end users.
8. What is the focus of the written report resulting from the comprehensive project review session?
   1. The report should cover both the positive and negative aspects of the project, with suggestions for improvement.
   2. The report should summarize the results of the project schedule, the budget, and any approved scope changes.
   3. The report should focus on the IT deliverables and any issues that were created by the client
   4. The report should cover what went well during the project. If the project was canceled, blame for the failure needs to be established.
9. Your project is winding down, and some of your team members are anxious about their status. What is the best way to deal with their concerns?
   1. Explain to the team members that they will be released when the project is done.
   2. Let the team members know that you can only discuss their release date with the functional managers.
   3. Establish the same release date for all the team members, even if their work is completed. If some people start leaving, others may try to jump ship as well.
   4. Review the team member release plans from the staffing management plan. Keep team members and functional managers informed based on the status of the project schedule.
10. Your client has suddenly produced a list of items that he wants fixed prior to final sign-off on the project. You suspect that he is attempting to add functionality to the system that should be handled through operations as a potential enhancement. What is the best approach to deal with the clients request?
    1. Let the client know that this is too late in the process to be bringing these issues to your attention. Any user issues should have been formally documented during user acceptance testing.
    2. Advise the client you will forward the list to the operations manager to provide time and cost estimates for each item.
    3. Request that the client map the fixes to specific requirements in the project scope document and explain what the problem is. Review the results of acceptance testing to determine if any bugs were identified.
    4. Escalate this to the project sponsor, so he can tell the client to follow the proper procedures for requesting enhancements
11. Which element of project closure is most often overlooked by project managers creating finalized project documentation?
    1. Completing the project book
    2. Including all metrics comparisons
    3. Getting the signatures of all of the stakeholders
    4. Creating lessons learned documentation
12. Which aspects of the project will you review when preparing your final closure documents? (Select all that apply.)
    1. Unfulfilled
    2. Positive
    3. Negative
    4. Unrealistic
13. Which four situations indicate that the project is ready to be closed?
    1. Stakeholders approve final testing results.
    2. Completion metrics are achieved.
    3. Sponsor says its time to use the project members on another project.
    4. Project is canceled.
    5. Project plan is rejected.
    6. Company priorities change.
    7. Project resources are exhausted.
14. Which of the following denote an unsuccessful conclusion to a project? (Select all that apply.)
    1. Resources exhausted.
    2. Project plan rejected.
    3. Project canceled.
    4. Project renamed .
    5. Project priority reduced.
15. From the list below, select those project phases in which you would expect successful project closure. (Select all that apply.)
    1. Initiating
    2. Planning
    3. Activating
    4. Executing
    5. Controlling
    6. Closing
16. Youre a project manager for a large, complex IT project thats just begun. Youre in the middle of the executing phase. The project sponsor has looked over your requirements definition plan and decided that the project is way too complicated for the minimal deliverables the customer has requested . She decides to cancel the project. What are your next steps? (Select all that apply.)
    1. Change vendors to obtain a lower bid for hardware and software components .
    2. Prepare project closure documents stipulating lessons learned.
    3. Release resources.
    4. Get the sponsor to let you redesign the project.
    5. Ask for a new sponsor.
17. Which projects should be required to have a closing phase? (Select all that apply.)
    1. Small projects
    2. Medium- sized projects
    3. Large projects
    4. All projects
    5. No projects
18. Which outflow of the closing phase stipulates that team members are free to go back to their departments?
    1. Release of resources
    2. Lessons learned
    3. Project book
    4. Sign-off
19. You are a project manager for a medium-sized project thats close to closure. Youve worked through the majority of the UAT for the deliverables, but you have a few more tests to go. Your sponsor wants you to conclude the project now, because by doing so it will look as though the project came in a few days ahead of schedule. What do you tell the sponsor?
    1. OK, thats doable. The last few UAT tests werent all that critical.
    2. No can do. We have to wait through the final UAT tests to make sure were completely successful.
    3. Youre the sponsor and can conclude the project any time you want, but for successful conclusion, we need to finish the UAT tests.
    4. Im sorry, Dave, I cant do that right now.
20. Who is responsible for authorizing the closure of the project?
    1. Stakeholders
    2. Project manager
    3. Customers
    4. Sponsor

Answers to Review Questions

1. C. Acceptance of deliverables is a key part of the vendor contract. Failure to meet the terms of communicating acceptance could put your company in breach of contract. You should immediately confirm the status of vendor deliverable acceptance testing and ensure that all results are completed to meet the deadline. This is not something that should be pushed aside or handed off to someone else.
2. D. There is valuable information to be gained from a review of any project, even projects that do not complete. The assessment should focus on those phases of the project that did complete, as well as a look at whether anything could have been done differently to make the project a success. The purpose of a review is not to assign blame, even for projects that are canceled. Facilitating a review session for a canceled project may not be the easiest task, but you will not energize the project team with the attitude that you are being forced to do this.
3. B. A delay in project implementation is not a signal that the project should be closed out, as long as the project is still viable . You will have to do some re-planning and analyze the impacts of the delay on other aspects of the project plan. If you have exhausted your budget, lost your resources, or no longer have executive support, you should obtain sponsor approval to officially cancel the project and move into the closure phase.
4. B. A project review is most beneficial to future projects if it covers all aspects of the project and includes both the negative and the positive of each phase.
5. C. A project review session can quickly turn into blamestorming if it is not well structured and tightly managed. By setting the expectations at the start, team members will know that they must offer suggestions for improvement and not just complain about whatever they did not like. A survey can be used as a last resort, but it lacks the human interaction that triggers ideas and suggestions. A report written from just one point of view may miss key elements.
6. D. A sign-off is the formal acceptance of the project. It signifies client acceptance of the product. Team members are released according to the staffing management plan, and both the project manager and the project team members may continue to be involved in the project until all closure activities are complete.
7. A. Your goal should be to continue the momentum of the project by working to provide a temporary solution for user support. If you take the application away from the users, they may need to be retrained once the help desk is in place. Reducing client support or taking the attitude that this is not your problem could jeopardize the long- term success of your project.
8. A. There are key conclusions for the future from both the successes and failures of a project. Successes will provide blueprints to follow, and failures will alert teams on what to avoid. A good lessons learned document covers all aspects of the project and deliverables from all participants .
9. D. The procedures for releasing project team members should be documented in your staffing management plan. Both team members and functional managers need to know in advance when you think a team member will be released. Team members may roll off the project at different times, so you need to discuss release with each team member individually.
10. C. You need to determine whether there is a valid issue here. If the system does not perform according to the requirements, the client has every right to expect fixes to be made. By asking the client to map the fixes to specific requirements, you can both determine if you are dealing with a fix or an enhancement. Escalation to the project sponsor would be premature at this point, as would passing the list to operations before you have determined the appropriate category for each item on the list.
11. D. Lessons learned is a simple idea: Youre pointing out the things that mightve gone better on this project and then documenting them so that project managers in later projects have information they can refer back to. Neophyte project managers might like to avoid lessons learned because they somehow associate this element with at least a modicum of project failure. In reality, no project is perfectly implemented, and all projects can offer additional information in the form of lessons learned. The project book is completed when all documentation has been signed and completed. You dont need the signatures of all of the stakeholders, only the project sponsor.
12. B, C. Youll evaluate both the positive and the negative aspects of the project. Undoubtedly, acknowledging the negative aspects of the project will be much more difficult than the positive. Part of the reason for this is that you have to be careful to not name names of people in the company who mightve had a less than positive effect on your project. The projects not complete if you have unfulfilled items. Unrealistic items shouldve been dealt with at requirements definition time.
13. B, D, E, G. The project is complete when the completion criteria say so, when the project is canceled, when the project plan has been rejected for whatever reason, or when the project resources have been consumed. The project isnt necessarily complete just because the stakeholders approve the final testing results, nor if the sponsor would like to free up team members for some other project.
14. B, C. Just because a projects resources are exhausted does not necessarily imply that the projects a failure; it may simply mean that the project utilized all of the resources allocated to it. If the project plan is rejected or the project is canceled, then one can assume there has been an unsuccessful conclusion to the project. Renaming, or even reduced priority, arent reasons to conclude the project.
15. F. Successful projects can be closed out only at the closing phase. You have successfully completed the projects deliverables, met the success and completion criteria, and youre ready to finish up. Youve entered the closing phase and can close out the project.
16. B, C. If you have a sponsor who opts to cancel the project, for whatever reason, you will still want to put the project into closing phase. During this phase, youll assemble the correct closure documents, in this case indicating why the project was closed and the metrics that were formulated for the requirements, and youll release any resources youve already set aside for the project.
17. D. All projects should recognize some sort of closing phase, even if its informal with a quick little document that specifies the criteria that indicated successful project completion, associated sign-off by the sponsor, and, of course, lessons learned.
18. A. The completion of the closing phase results in the documents that conclude the project and authorizes the release of the projects resources, including team members.
19. C. The sponsor has the right to conclude the project any time he or she wants to. Remember that the sponsor is the one who can authorize the expenditure of resources in order to prepare the deliverables. However, you cannot call it a successful project until youve completed your testing and then have validated your success and completion metrics.
20. D. The sponsor is the one who signs off on the closure documents. As project manager, you create them, providing supporting documentation that illustrates that all deliverables have been successfully completed.