Course Transcript

In an orchestra, many instruments play different notes at the same time. The conductor must pay attention to what each section of the orchestra is doing. For example, when leading the string section, the conductor must consider how its music will affect the woodwinds and brass sections. If the conductor focuses on just one section, the other musicians will not receive the direction they require in order to produce a unified and beautiful effect.

Like the conductor leading the orchestra, a project manager must also lead a project in an orchestrated way. Decisions related to controlling costs may affect time lines, quality, human resources, and many other aspects of the project.

Project issues, decisions, and administrative activities must be looked at from all sides and managed in an integrated way.

A key aspect of bringing everything together within a project is managing project changes effectively. By controlling change and responding carefully to a changing environment, you're better able to ensure successful completion of a project. Then when it's completed, you can follow closing procedures to ensure there are no loose ends. And you can also provide documentation that'll help generate further success in new projects.

This course outlines the principles you should follow when managing the Perform Integrated Change Control process. It covers what inputs you can use in this process, what activities need to be performed, and what the outcomes of the process are.

The course also explains the Close Project or Phase process, guiding you how to ensure product acceptance, tie up loose ends, and assess the project's success.

Back to top

1. Integrated change control

Changes are inevitable during a project. So handling change well is key to every project's success. The Perform Integrated Change Control process can help you deal with change effectively. This process involves reviewing, approving, and managing changes to project deliverables, plans, and processes.

The Perform Integrated Change Control process is triggered when there's a change request generated as an output of project work processes or control processes.

If members of the project team make even small changes without using the process, these could accumulate and badly affect the project scope, budget, and schedule.

Every change, no matter how small, should go through the control process. This avoids scope creep. And it helps ensure only necessary changes are approved and that the project remains within budget and on schedule.

So how can you effectively manage changes? There are several principles of the Perform Integrated Change Control process that you should follow. First, you need to develop a method to identify when changes to the baseline plan occur. Second, you need to address and manage changes promptly. And third you should track and document the impact of the changes.

Select each key principle of the Perform Integrated Change Control process for examples of how it can be implemented.

Develop method to identify changes

Project managers need to establish methods to identify potential and actual changes to the project's baseline plan. To do this, you can request daily e-mail status updates that include any issues of the day from team members.

You can also schedule weekly phone calls with the customer or other key stakeholders to find out about any changes that could affect the project.

Another method is to check online sources for environmental, technical, or legislative changes that may affect the project.

Address and manage changes promptly

Slow responses may affect the time, cost, or feasibility of making a change. So emergency procedures need to be in place to fast track the approval of change requests when necessary.

Suppose your team finds that a key component in a program malfunctions and is causing safety concerns. You're under tight deadline pressures but the team finds a solution. You may need to apply the new solution without waiting for the change control board to approve it. However, this solution should still be recorded and processed within the change control system.

Document impact of changes

Project managers need to track and document the impact of all changes in an issues log or change control log. This helps improve your own change management skills, and develops resources for others on similar projects.

The fourth principle of the Perform Integrated Change Control process is to review and assess change requests before making a decision to reject or approve them. Reviewing and assessing change requests is one of the main activities of change control.

When reviewing a change request, you need to determine who initiated the request and what type of change it asks for. You also need to understand the factors that have led to the request – these may be customer demands, changes in legislation, technical difficulties, and so on.

You need to assess what impact the change could have on scope, quality, schedule, and cost. Suppose the change you're considering pushes out the scheduled completion date. That means you'll need resources longer than expected and this will cost the customer more.

Finally, you need to decide whether the change should go ahead. To help you do this, you need to ask yourself whether the benefits of making the change increase or decrease the chances of successful project completion while still meeting the project objectives. You should then make a record of your decision.

The final three principles of Perform Integrated Change Control relate to making sure a project sticks to the project management plan when possible. To do this, you should implement only approved changes, adjust the project baselines only when necessary, and coordinate approved changes.

Select each principle for more information about it.

Implement approved changes

To ensure only approved changes are made, you need to document change requests and the process for approving them.

Where changes are not approved, you may need to address the factors that led to the change requests.

Adjust baselines when necessary

Very few approved changes should affect the project's performance baseline. If a change of this kind is justified and doesn't threaten the project, ensure you gain your sponsor's approval. Though approved changes are incorporated in a new baseline, you should also keep a copy of the original baseline for comparison purposes.

Changes that impact an existing or completed project management process require updates to that process. This could mean additional passes through the appropriate Planning and Executing processes.

Coordinate approved changes

Approved changes must be coordinated or integrated across the project. For example, changes in one area might require updates in other areas, such as risk response alternatives, schedule, cost, resource requirements, or other elements.

Also, updates to the product scope baseline typically result in changes to the budget and schedule. This means you need to assess the impact of a particular change right across the project.

It's important to remember that project baselines should be changed only when absolutely necessary. Always look for an alternative solution to managing the change.

For example, a stakeholder might demand a new feature for the product you're developing. On assessment, you find this change is beyond the project's scope.

Because the feature is a major departure from the project scope statement and is not absolutely necessary, the change control board rejects the change request. This protects the project baseline and helps to manage stakeholder demands more effectively.

2. Configuration management

So now that you've been introduced to integrated change control, there's another aspect to this that you'll hear a lot about in project management – configuration management. This is an important aspect of integrated change control.

You can think of configuration management as a fancy term for version control. A configuration management system is an all-encompassing system of procedures, software, and policies used to control versions of the product and its components. It also controls all product-related documentation and key project management documents, such as the project management plan and various logs.

So why is configuration management so important?

It prevents version-related errors, such as delivering the wrong version of a product to the customer, testing the wrong version, or losing the correct version by mistakenly over-writing it with an out-of-date one.

The larger a project is, the more complex the processes you follow, and the more people you have working on it. In these cases, mistakes are likely to happen. Using a configuration management system greatly reduces the risk of errors.

Besides ensuring version control, the configuration management system has another important role. It establishes a set of processes and checks for ensuring that only approved changes are made to the product and project documents. This is where the change control system comes into play. It's a subset of the configuration management system.

Configuration management involves three main activities that are directly related to the change control system. These activities involve identifying the characteristics of a product or service, controlling changes to those characteristics, and documenting and auditing these changes to ensure requirements are met.

Select each activity for more information about it.

Identifying characteristics

Configuration identification is when you select and record all the items related to the project, including the product and project management documents, that require version control. These are known as configuration items and are documented in the configuration management plan.

Part of this identification is providing an accurate and complete description of the characteristics of the product, service, or result. This description is used to verify when changes have been made.

Controlling changes

Controlling changes involves configuration status accounting. Configuration status accounting simply means that you keep track of the status of the product or document at all times. This includes the status of any proposed changes to the document and the implementation of any approved changes. Most project managers use project management software or some type of log for tracking status and storing information about the product.

Documenting and auditing changes

Documenting and auditing changes refers to configuration verification. Configuration verification is when the product is reviewed to ensure it meets quality standards and stakeholder requirements. Guidelines for configuration verifications would be outlined in the quality management plan and scheduled during planning. Configuration audits are simply ad hoc verifications that may be conducted by the project manager or another stakeholder.

As part of the change control system, any changes resulting from the verifications or audits would be registered, assessed, approved, tracked, and correctly implemented.

Consider an example of how normal change control activities correspond to the three configuration management activities. Suppose you're managing a project to develop a new media player. An update to a media format is released and your customers decide they want the new player to be able to handle it.

Because the media player is a configuration item, you first review the product specifications recorded in the quality management plan. This tells you what formats the media player is currently designed to support. Unfortunately, the new format is not on the list.

Next you check the product status log to see what stage of development the product is currently in. You also log the change request, document when a change control board meeting should be held to consider the request, and document what the change may entail.

If the change is rejected, you simply log the rejection in the change control log. If the change is accepted, you need to update the change control log and make changes to the project plan, depending on how the change will impact the project's scope, budget, schedule, and resource requirements.

The change request is approved by the change control board and the media player is adapted to handle the new media format. The media player is tested during the quality control process to ensure that it can play back media correctly using the new format. If the player fails testing, corrective action will be required.

So a configuration management system includes the documentation, tracking systems, and defined approval levels necessary for authorizing and controlling changes to a product. A project's change control system is the mechanism through which this is done.

3. Summary

The Perform Integrated Change Control process involves reviewing, approving, and managing changes to project deliverables, plans, and processes. This process helps ensure only necessary changes are approved and made, so a project remains within budget and on schedule.

The configuration management system provides tools for implementing the Perform Integrated Change Control process. The change control system documents needed characteristics of a product or service, documents the change control process, and audits results to determine whether all specifications and requirements have been met.

Back to top

1. Integrated Change Control inputs

Change is a fact of life. And how you manage and control change during the life of a project will determine that project's success.

The Perform Integrated Change Control process is designed to review change requests and manage approved changes to deliverables, organizational process assets, project documents, and the project plan.

To use the Perform Integrated Change Control process effectively, you need to be aware of its key inputs, tools and techniques, and outputs.

The main inputs to the Perform Integrated Change Control Process are change requests. Changes may include corrective actions, preventive actions, and defect repairs. Most change requests are recommendations or requests generated as the project progresses.

Change requests can come from any of the processes in the Project Integration Management Knowledge Area, such as Direct and Manage Project Work or Monitor and Control Project Work. Change requests may also be generated by any of the control processes, such as Control Scope or Control Costs.

Select the Direct and Manage Project Work box and the Monitor and Control Project Work box for examples of change requests from each process.

Direct and Manage Project Work

Changes may be required when issues arise as project work is being performed. For example, once the project is underway, the project team might discover more efficient ways of performing tasks and so recommend changes.

Monitor and Control Project Work

Variances from the plan are identified as work performance information is analyzed. The project manager may request corrective actions to bring the project back into alignment with the plan – for example, to make up for a delay in the project work so the project stays on schedule.

Control processes that may lead to change requests include scope control, cost control, schedule control, and quality control.

Suppose a delay in receiving components threatens to put a project one month behind schedule. The project manager, the project team, and even the stakeholders can examine the project schedule to see what possible alternatives can be used to bring the project back on track.

Solutions may include using additional team members to carry out the work and changing the order in which some of the work is completed. Certain areas of the project could also be fast tracked to ensure the project is completed on time.

Once a workable solution has been planned a change request is sent to the change control board, which then uses expert judgment to approve or reject the request.

Other inputs into the change control process are organizational process assets, including the configuration management knowledge base, change control procedures, and project files.

Select each organizational process asset for more information on how it influences the change control process.

Configuration management knowledge base

The configuration management knowledge base contains the versions and baselines of all official company standards, policies, and procedures. It also contains project documents and a lessons learned database, which may provide helpful information on similar changes and how they were handled in other projects. These resources can influence how a change in the current project will be handled.

Change control procedures

Change control procedures specify how each change should be reviewed and assessed. They also state the process that project managers and the change control board should use to document rejected and approved change requests. Finally, they may specify which documents, such as the project management plan, should be updated when a change is approved.

Project files

Project files for the current project are useful for assessing possible changes, before and once change requests are sent to the change control board, and by the change control board. These files may include scope, cost, schedule, quality, and performance measurement baselines. Other documents that may be used include risk registers, risk response plans, project calendars, project schedules, and so on.

Betty Park is a project manager for a hospital project. She has a reporting process in place to ensure she's updated with any potential changes that may impact the project. Team members send her daily e-mails about their progress and problems.

She notices that quality control procedures are taking longer than expected due to the various legal requirements for these checks. Betty shuffles her "To Do" list to make change management a priority and begins reviewing the configuration management knowledge base.

She checks the knowledge base to determine how similar problems were managed in the past and what lessons were learned.

Betty finds some potential solutions for the delays that are occurring in carrying out quality control procedures. She reviews the project files for the current project to assess the potential impact of these solutions on scope, cost, schedule, and quality.

Once she is clear on what the best possible solutions are, Betty checks the documentation outlining the change control procedures. Using these to guide her, she draws up a change request.

So in responding to problems that arise, Betty uses organizational process assets. These include the knowledge base, project files, and change control procedures. She also follows change control principles by ensuring there is a method for identifying change – daily e-mail reports – and by dealing with change issues promptly.

There are three remaining inputs to the Perform Integrated Change Control process:

• the project management plan
• work performance reports, and
• enterprise environmental factors

Select each input for an example of how it is used during the Perform Integrated Change Control process.

Project management plan

The project management plan outlines how a project is to be executed, monitored, and controlled. It is an input to the Perform Integrated Change Control process because it contains the subsidiary plans and the baselines against which actual results are compared.

So the plan may contain a schedule management plan which outlines the planned delivery dates of all deliverables. If a comparison shows that one deliverable will be delivered five days later than planned, a change request needs to be submitted and approved. The result of the Perform Integrated Change Control process leads to an updated plan.

Work performance reports

A project manager receives work performance reports on a project's deliverables' status, schedule progress, and cost to date. The information reflects the actual results of a project, and is used when reviewing, approving, and managing change requests during the Perform Integrated Change Control process.

When a project manager discovers that a deliverable is not completed on September 23 – three days behind schedule according to the project management plan, he knows that he needs to initiate corrective action.

Enterprise environmental factors

An enterprise environmental factor becomes an input to the Perform Integrated Change Control process when it is used to manage and apply changes across all affected components of a project in an organized and efficient way. A project management information system, such as a scheduling tool, is one example of an enterprise environmental factor.

The scheduling tool helps to monitor the status of the schedule, identify changes to it, analyze alternative actions if planned and actual results deviate, apply changes to the schedule, and communicate the changes to all relevant stakeholders.

2. Change control board

There are three tools and techniques used in the Perform Integrated Change Control process – expert judgment, change control meetings, and change control tools.

The project manager uses the expert judgment of the entire project team to make change control decisions. Other stakeholders, such as consultants or the customer, may also provide expertise.

Expert judgment about how to control project change is generally obtained during change control meetings.

There are many manual and automated tools that the project manager may use during the change control process. For example, communication technologies such as e-mail and online collaboration sites are used to manage change requests and communicate decisions made during the meetings.

To understand change control tools and meetings and how expert judgment is used in the change control process, you need to understand the role played by the change control board.

This board reviews change requests and approves or rejects each proposed change. The range of the project manager's responsibility in approving or rejecting minor change requests is clearly set out and must be approved by all key stakeholders.

All change control board decisions are documented and communicated to stakeholders.

The role of the change control board depends on the change control system set up for a project and the level of authority – either high or low – the project manager has been granted. Select each system type for more information.

High authority

In some projects, the project manager holds authority for much of the decision making and brings changes to the change control board only when the requests are significant.

Low authority

In certain projects, very tight controls are put in place. The project manager and change control board have regular meetings – for example every week – to discuss and manage all project changes and related issues.

Members of the change control board can include stakeholders, managers, technical experts, and project team members, as well as others who might not have any connection to the project.

Others may be called in for their expert judgment. These decision makers include customers, consultants, and members of industry groups, professional and technical associations, and the Project Management Office.

The project team is expected to provide expert judgment too. Members of the board and any other chosen experts also give their input on technical and management details. The members of the change control committee will use their own backgrounds, perspectives, and expertise to assist the project manager. They interpret work performance information and determine what action to take when managing change.

3. Approving or rejecting changes

The change control board usually either approves or rejects a proposed change. In some instances, it may feel it cannot make a decision right away and will put a change request on hold, pending further information. The criteria a change control board uses to make decisions are the feasibility of the change and whether the change will impact the project scope.

Select each of the criterion used by the control board for more information about it.

Feasibility of change

A change is considered "feasible" if the baselines can be adjusted to accommodate it and it won't affect the project's performance beyond tolerable levels. A change that is not feasible would place undue stress on the project, making it impossible for it to finish on time and on budget.

If the board decides a change isn't feasible, it will reject the request for change or possibly send it back to the person who submitted it with a request for more information.

Impact on scope

The change control board has to determine whether a requested change will impact the project's scope. This means whether it will affect the project performance baselines.

A change request is likely to be rejected if it does impact scope, unless the change is considered important enough.

An example of a feasible change request may be a color palette change for a web site. This requires very little work and has no real impact on the project schedule, budget, and scope. So it would likely be approved.

This change is considered within scope because the color change doesn't add anything significant to the end product and so won't have a large impact on performance baselines.

Another feasible change may be to upgrade the site to run both Java and Flash applets for advertisements. This change impacts the project scope, increasing the time and resources needed to complete the project. But if the change is sufficiently important to the project, it can be approved.

A request to change the functionality of the web site so it can process financial transactions is rejected as not feasible. This change would involve a further five months of development and testing time and a large cost increase. So it would significantly extend the scope of the project.

In this case, the customer may be persuaded to purchase this enhancement separately, as a new project.

If a change is not feasible, it is rejected. If the change is feasible, its impact on project scope is assessed. If a change is rejected at this stage, the change request is updated and filed. If the change is approved, its impact on scope determines what project documents will need to be updated.

Suppose the change request to upgrade the web site to run both Java and Flash applets for advertisements is approved.

This change will impact the scope of the project in terms of its functionality. This also impacts cost in terms of paying web developers to include the required coding. It may also take a few days longer and so affect the project schedule.

To counteract rises in costs and changes in schedule, further changes may have to be made to plans.

4. Integrated Change Control outputs

The outputs of the Perform Integrated Change Control process are approved change requests, change log, project management plan updates, and project documents updates.

Select each output of the Perform Integrated Change Control process for more information on the updates that need to be made.

Approved change requests

Approved change requests, which are implemented in the Direct and Manage Project Work process, are a result of the Perform Integrated Change Control process.

Change log

Details on whether a requested change is approved, rejected, or given a pending status should be recorded in a change log, including details on the impact to the project. The change log should be stored in a single knowledge base for the project.

Project management plan updates

When a change affects the scope of a project, the project management plan must be updated. This includes updates to the subsidiary plans.

Subsidiary plans can include the quality management plan, human resource management plan, and risk management plan. An example of an update might be a cost overrun due to a change in suppliers. This must be reflected in the cost and procurement management plans.

Project documents updates

Updates need to be made to documents that are affected by the change control system.

The change control log must always be updated, regardless of whether the change is approved or rejected. This log may take the form of a spreadsheet or automated change control system that tracks the status of change requests. Forecast documents are updated only when a change affects project baselines. So changes in project scope must be documented in forecasts.

So to manage change effectively, you need to maintain accurate and reliable performance measurement baselines, coordinate all processes impacted by the change, and update the project baselines to reflect any changes in product scope.

5. Summary

Inputs to the Perform Integrated Change Control process are change requests, organizational process assets, project management plan, work performance information, and environmental enterprise factors. As the project progresses, change requests may stem from monitoring and controlling processes as well as the executing processes.

The tools and techniques for the process are expert judgment, change control tools, and change control meetings. The change control board reviews and assesses change requests. It then approves or rejects the requests depending on their feasibility and impact on project scope.

Outputs of the Perform Integrated Change Control process include approved change requests, the change log, and updates to the project management plan and project documents.

Back to top

1. Closing projects and phases

You've done everything, the deadlines have been met, and the project is over. Or is it?

If you take time to think through what has happened and formally bring activities to a clear conclusion at the end of a project, you'll reap the benefits.

"I was so relieved to get the project finished, I didn't think about what might need to be done to close the project properly. If I had finalized all activities across all project Process Groups, we wouldn't be dealing with problems after the project has finished."

"I could have established procedures to verify and document the project deliverables. Doing so would have ensured that the transfer to operations went more smoothly."

"I know I can't prevent problems from occurring in future projects, but I could have used the lessons I learned and revised processes. As it is, I'm back to square one with the new project I'm starting."

When you formally close a project or a phase, you can avoid some of the problems Betty faced. Closing a project or phase confirms the project status. It also clarifies the successes and failures of the project. Closing properly releases resources and ensures completed project documentation is available for use in the future.

Select each benefit of the Close Project or Phase process for more information about it.

Confirms project status

Confirming the status helps you to know for sure the project or phase is really over. This frees you for other tasks. It also ensures that stakeholders will agree on the project's status too. So, for example, stakeholders won't send any further requests for changes once they know the project is completed.

Clarifies successes and failures

You need to debrief the project sponsor on the successes or failures of the project. The Close Project or Phase process helps to clarify what these are.

Releases resources

By following the Close Project or Phase process, you are able to formally release resources so they can be used in the next project or phase.

Completes project documentation

Project documentation and formal sign-offs can help you in the future, so you have to know how to find them quickly and know they are complete. The Close Project or Phase process helps ensure all documentation is complete and archived.

Close Project or Phase is the process of finalizing all the activities across all of the project management Process Groups to formally close a project.

The close process can also be used to end a phase of a multiphase project. This helps ensure that resources are released and that the deliverable is properly transferred to the next phase of the project.

So the Close Project or Phase process ensures you transfer the completed deliverables as appropriate.

It coordinates the activities needed to verify and document project deliverables, formalizing the acceptance of deliverables by the customer or sponsor.

Finally, it is used to investigate and document the success or failure of a project or phase. If a project or phase is terminated before completion, it also identifies the reasons why.

2. Closing process inputs

The inputs to the Close Project or Phase process are the project management plan, accepted deliverables, and organizational process assets.

Areas of the project management plan that are compared with actual results include the schedule, budget, and risks.

Select each area within the project plan for more information about how it acts as an input to the Close Project or Phase process.

Schedule

Budget

When checking the budget, you need to determine whether the project expenses are within tolerated limits outlined in the cost baseline.

Risks

To be used as inputs to the Close Project or Phase process, deliverables need to progress through several phases and processes before they reach the accepted deliverable stage. Follow along to learn more about each phase and process.

Project managers use the Direct and Manage Project Work process to oversee the creation of a product, component, or service. For example, a project team might create a software component during the work execution phase.

The software then passes through the Perform Quality Control process, where it is validated internally. For example, it passes through software testing.

Then during the Validate Scope process, the software is reviewed by an internal team to ensure it matches the project's scope statement. Stakeholders such as the customer or sponsor may also review and sign off on the product at this stage.
For example, a checklist for validating scope may have the items user interface, help files, and easy navigation.

Changes needed during the Validate Scope process are controlled through the Perform Integrated Change Control process. For example, keyboard shortcuts are added for key tasks within the software.

Finally, approval is obtained and the software becomes an "accepted deliverable" that's an input to the Close Project or Phase process.

Organizational process assets are the third and final input to the Close Project or Phase process. Some companies have phase and project closure guidelines, such as templates for performing project audits and evaluations.

Company guidelines may also include processes for performing subproduct – or component – validations and completed product validations. There are also likely to be guidelines for standard acceptance criteria.

3. Meetings and expert judgment

There are three tools and techniques used in the Close Project or Phase process. These are meetings, expert judgment, and analytical techniques.

One of the main activities carried out during the Close Project or Phase process is ensuring the acceptance of deliverables. This involves meeting with members of the project team, the customer, and support personnel to confirm that all acceptance criteria have been met. You may also need to confirm that the deliverable has been accepted by the customer, and that all product sign-offs have been filed.

Expert judgment is chiefly used as you carry out administrative closure. This involves ensuring all the necessary paperwork is completed and properly archived. These documents include customer or sponsor sign-offs, finalized project files, and other project or phase records.

During administrative closure, you also gather lessons learned and archive project information for future use by the organization.

When performing administrative closure activities, use expert judgment to ensure the project or phase closure is performed to the appropriate standards.

How should project managers handle the situation if a project is canceled or closed early?

If a project is terminated, it's critical to document all information about it. This information may be needed if the project is reopened or if a similar project is started at a later date. For this reason, the administrative closure activities should be completed.

If a project is canceled or closed early, it is important that you investigate and document the reasons why. Reasons for early closure may include a change in business focus, technology, or legislation. There may also be changes in customer demands or in the market or business environment. Another reason for early closure is that the company may need resources to respond to a more urgent issue.

4. Analytical techniques

The third main activity in closing a project or phase is to assess project success. This involves comparing actual project results to the planned results in the project management plan. This is the main activity during which analytical techniques are used, such as regression analysis and trend analysis.

A project manager gathers assessment information by performing any required project audits or evaluations. Typically a group of stakeholders carry out the assessment using this information. This group reviews the project management plan and deliverables to determine the degree of the project's success.

A project assessment should answer several questions:

• Was the quality of the product or service acceptable?
• Was it delivered on time and within budget?
• Was there adequate communication between the project manager and the team?
• How well did the project manager and the team perform?
• What revisions were added to the project?
• Was the documentation well presented and informative?

5. Summary

The Close Project or Phase process helps confirm the closed status of a project or phase, and clarify its successes or failures. It also releases resources and ensures project documentation is complete.

The inputs of this process include the project management plan, the accepted deliverables, and organizational process assets. Using these inputs, you can ensure deliverables meet the proper criteria, project documents are gathered and archived, and the success of the project is assessed.

Expert judgment, analytical techniques, and meetings are used to ensure that all activities have been completed correctly.

Back to top

1. Transition of the project result

You've done it. You've gotten through the project, and you think you've finished. But how can you be sure? You can be sure you're finished when you have two main outputs from closing the project – the transition of the final product, service, or result; and updates to organizational process assets.

Transitioning the project's final result means handing over its deliverables to whoever will control them next. This person or team will differ depending on several factors, including whether a product is at the end of a particular phase or at the end of the project, or whether the deliverable is a process improvement.

Select each transition situation for an example of how it may be handled.

End of phase

When the product of one phase is used as an input for another phase, you need to transfer the product to those responsible for handling the next phase. For example, after your coding team finishes creating the code for a software update, the code must be passed to those responsible for testing it.

End of project

When a project is completed, you may need to hand a deliverable over to a team that is responsible for its maintenance or for its mass production or operations. For example, after you complete constructing a water treatment plant, the plant and its processes must be handed over to the maintenance teams, engineers, and others for ongoing maintenance.

Process improvement

If the project is one that develops a process improvement, the required process and procedure documents, performance targets, and other deliverables are handed over to the company for ongoing monitoring and control.

You need to ensure that the product, service, or other result of a project or phase is formally accepted. This requires a signoff from relevant stakeholders.

For example, if there is a contract in place, you need formal signoff indicating that those who contracted the project have received and accepted the final product.

The acceptance must include a formal statement that the terms of the contract have been met.

Final product sign-offs generally include details of the product and an official signoff form that has to be signed by key stakeholders. Forms often differ depending on whether they are internal or external.

Select each form type for an example of it.

Internal

The planning phase of a project is over. The formal signoff document should include a signature from the project sponsor confirming approval of the plan. The signatures should be dated and the project name and working title should be on the document. The document should also include a summary of each key area of the plan.

External

At the end of a project, a new computer game has been created. The signoff document should include the project name, the author of the document, the version number of the game, and the date it was issued. The signatures of the sponsor, senior user, and project manager should be on the document.

The document must also state the project outcome has been measured against its acceptance criteria and formally accepted. Any comments about the customer acceptance should be noted. Additionally, any recorded shortfalls of the outcome should be listed in the signoff document.

The result of a project that develops or improves a business process is the document outlining the improvement. This should include a signoff document naming the process and owner, who it was reviewed and approved by, and any follow-up actions, such as the filing of signature copies.

Once a product or outcome has been formally signed off and transferred, the project manager is expected to notify relevant stakeholders of the transfer and that the product has been accepted.

2. Process asset updates

Updating organizational process assets at the close of a project helps you organize all the information, tools, experience, and documents from a project. Some of these may be used for future projects, so it's important that you make updates in these areas.

The organizational process assets that are updated during the Close Project or Phase process include project files, project or phase closure documents, and historical information.

Select each organizational process asset for more information about it.

Project files

Project files include all documentation resulting from the project's activities. Examples are the scope, cost, and schedule baselines, project calendars, risk registers, planned risk response actions, and risk impact assessment.

Closure documents

Project or phase closure documents, which include formal acceptance documentation, indicate a project or phase is complete and covers the transfer of its deliverables to others.

Formal acceptance documentation includes written confirmation that the customer or sponsor has officially accepted the project's deliverables as meeting all requirements.

If the project was terminated prior to its completion, the formal documentation indicates why the project was terminated and formalizes the procedures for transferring finished and unfinished deliverables to others.

Historical information

You need to transfer historical information about the project and the lessons learned during the project to the knowledge base. This information can then be used during a later phase or later projects to help build on successes and minimize mistakes.

Suppose you have recently completed the prototyping phase of a tool creation project. You begin updating organizational process assets by ensuring all formal acceptance documents for the prototype are completed and filed.

Next you review all the project documentation, such as the project management plan, scope, cost, and schedule baselines, and project calendars. You ensure these are complete and that the reports providing the end results of the phase are filed.

You ensure all phase closure documents, such as sign-offs and transfer reports, are completed and then enter historical information about the phase into the lessons learned database.

So outputs of the Close Project or Phase process include completed products or services, and updates to organizational process assets that are handed over to a new project phase or organizational function.

They also include completed signoff documents and archived project files and deliverables.

3. Summary

The outputs of the Close Project or Phase process include the transition of deliverables to the customer or a new phase, and updates to organizational process assets.

To transition a product, you need to obtain formal sign-offs for the product, officially hand the product over, and inform stakeholders of the product's acceptance and transfer.

Updating organizational process assets provides useful information and tools for later phases or projects. The organizational process assets that can be updated during the Close Project or Phase process include project files, project or phase closure documents, and historical information.

Back to top