Project Closing Process Templates

The Project Closing Process group consists of the processes to formally closeout the project.
Once the closing process is completed the project manager has received acceptance from the
project sponsor, conducted a post-project review, performed and documented lessons learned and
archived all project related documents.

Lessons Learned
Even the most successful projects have lessons from which we can learn. Whether you're
building the next wonder of the Word, or upgrading an IT system there will be lessons you can
learn from your project. An effective Project Manager documents and analyzes the lessons
learned from his project and applies them to future projects throughout the organization.

LESSONS LEARNED TEMPLATE

Introduction

Capturing lessons learned is an integral part of every project and serves several purposes. While
the finalization of a formal lessons learned document is completed during the project closeout
process, capturing lessons learned should occur throughout the project lifecycle to ensure all
information is documented in a timely and accurate manner. The lessons learned document
serves as a valuable tool for use by other project managers within an organization who are
assigned similar projects. This document should not only describe what went wrong during a
project and suggestions to avoid similar occurrences in the future, but it should also describe
what went well and how similar projects may benefit from this information. This document
should be communicated to the project sponsor and Project Management Office (PMO) for
inclusion in the organizational assets and archives as part of the lessons learned database. If the
organization does not have a PMO then other, formal means of communicating the lessons
learned should be utilized to ensure all project managers are included.

The purpose of the lessons learned document for the New Building Construction (NBC) Project
is to capture the project’s lessons learned in a formal document for use by other project managers
on similar future projects. This document may be used as part of new project planning for similar
projects in order to determine what problems occurred and how those problems were handled
and may be avoided in the future. Additionally, this document details what went well with the
project and why, so that other project managers may capitalize on these actions. Project
managers may also use this document to determine who the project team members were in order
to solicit feedback for planning their projects in the future. This document will be formally
communicated with the organization and will become a part of the organizational assets and
archives.
Lessons Learned Approach

The lessons learned approach describes how the document will be created, what it will consist of,
and how lessons will be categorized. It is important that the lessons learned approach is covered
in the initial stages of project planning. The reason for this is that a methodology along with an
appropriate set of tools should be established to capture these lessons throughout the project’s
lifecycle. A project journal is one example of a tool to capture these lessons. If no thought is
given to lessons learned until project closeout then it is likely that many lessons and details will
be omitted from the document. The contents of the lessons learned document should also be
determined ahead of time. They should be detailed enough to provide value for future use and
the contents should be consistent with other lessons learned documents or organizational
standards. The categorization of lessons learned is another consideration. Many organizations
categorize lessons by project lifecycle phase or by the knowledge area that the lesson applies to.

The lessons learned from the NBC Project are compiled from project journal entries throughout
the project lifecycle. Lessons learned were also be gathered from both realized and unrealized
risks in the project risk register as well as through interviews with project team members and
other stakeholder as necessary. The lessons learned from this project are to be used as references
for future projects and contain an adequate level of detail so that other project managers may
have enough information on which to help base their project plans. The lessons learned in this
document are categorized by project knowledge area. These knowledge areas consist of:
procurement management, risk management, integration management, quality management, time
management, cost management, scope management, human resource management, and
communications management. NOTE: some knowledge areas may not contain lessons learned if
none were documented throughout the project lifecycle.

Lessons Learned From This Project

The lessons learned must be communicated in a consistent manner. In addition to the

categorization and description of the lesson, it is important to state what the impact was and
provide a recommendation for project managers to consider on future projects.

The following chart lists the lessons learned for the NBC project. These lessons are categorized
by project knowledge area and descriptions, impacts, and recommendations are provided for
consideration on similar future new construction projects. It is important to note that not only
failures or shortcomings are included but successes as well.

Category Issue Name Problem/Success Impact Recommendation

Procurement Contract The PM was not fully All requirements PM must be fully
Management Requirements engaged in the were not included engaged in all contract
contract process. in the initial processes. This must
contract award. A be communicated to
contract both PM and contract
modification was personnel.
required which
added a week to
 the project.
Human Award Plan There was no plan for Toward the end of The PM should
Resources providing awards and the project morale institute and
Management recognition to team was low among the communicate an
members. project team. There awards/recognition
was increased program for every
conflict and team project.
members were
asking to leave the
project.
Scope Scope Creep Stakeholders The PM did not The PM must have an
Management continuously tried have a plan for approval process for
adding to the project addressing scope any proposed scope
scope throughout the creep and allowed changes and
project lifecycle. some requirements communicate this
to be added until process to all
the sponsor stakeholders.
stopped it. Overall
project delay of 3
weeks was the
result.
Quality Building A process for This allowed the Always plan quality
Management Material determining project team to standards and
acceptable building work with the allowances into the
material quality was contractors to project plan. This helps
planned into the smoothly ensure all avoid delays and cost
project. materials were of overruns.
acceptable quality
and avoided any re-
work and delays
associated with
substandard
material.
Risk Zoning A risk was identified Impact was minimal Always consider
Management Approval that there may be because the PM external impacts on
delays in receiving included potential the project cost and
approval from the zoning delays into schedule. This must be
county zoning board. the project continuous throughout
This was a success schedule. the project lifecycle.
because it was
identified early and
planned for.

Lessons Learned Knowledge Base/Database

The Lesson Learned Knowledge Base contains historical information from previous projects. It
is part of the organizational project assets and provides a valuable source of information to be
used by similar projects in the future. All project lessons learned and other historical information
need to be transferred to this knowledge/database in order to provide one centralized repository
for ease of use. This should also include information on issues and risks as well as techniques
that worked well which can be applied to future projects. Most lessons learned
knowledge/databases contain large amounts of information, so it is important that there is a
system for cataloging this information.

The lessons learned for the NBC Project will be contained in the organizational lessons learned
knowledge base maintained by the project management office (PMO). This information will be
cataloged under the project’s year (20xx) and the type of project (New Construction) for future
reference. This information will be valuable for any project manager assigned to a new
construction project in the future.

Lessons Learned From Previous Projects

The lessons learned document might also state which historical lessons learned were used on this
project. This information not only shows the value of the documentation of such lessons, but it
also shows which lessons are consistently applied by other similar projects. It is important to
reference not only what the lesson was but from which project it was associated with.

The NBC Project utilized several lessons learned from past projects:

1. The addition of a risk associated with planning cost and schedule based on external
dependencies (i.e. zoning approvals) was determined during the planning process by consulting
the lessons learned from the Building #3 expansion project from 20xx.
2. The planning of acceptable quality standards was based on lessons learned from the Startup Site
Construction Project of 20xx. By planning for quality standards the project team was able to
avoid schedule and cost overruns by clearly communicating acceptable quality standards to all
contractors involved with the project.

Process Improvement Recommendations

It is important that once lessons learned are collected and documented that the organization
approves and implement any process improvements identified. It is important for organizations
to strive for continuous improvement and this portion of the lessons learned process is an integral
step.

As indicated in the lessons learned chart above, the NBC Project did not have a process for
reviewing and approving requested changes in requirements or project scope. Not only is this a
lesson learned for similar future projects; but the organization must ensure that all project
managers are aware of the need for this process to be included in the planning of all future
projects. Therefore, it is recommended that prior to work beginning on any new project, the
project manager must brief the project sponsor on the process for requesting and approving
changes to project scope.
Post Project Review
It's good practice to review all projects at their completion. A Post Project Review should be
performed in addition to a Lessons Learned. Reviewing your project to see how actuals
compared to planned gives you a good 30,000 foot view of the project's performance.

PROJECT REVIEW TEMPLATE

1. Project Summary

This section of the Post Project Review should provide a summary of the project which was
completed. It is important that this summary captures the scope of the project and contains
enough detail to provide a full understanding of the project. Since this document will
communicate what went right and wrong with the project, as well as lessons learned and
recommendations for future projects, it is imperative that this section provide enough
background information to base the details in the rest of the document on.

Cable Tech recently completed the MicroFiber Cable Project which has been transitioned to the
operations group for manufacturing. This marks the end of a difficult but successful project for the Cable
Tech research and development (R&D) group.

The objective of this project was to design a new optical fiber cable which is smaller than our current
line of cable products without sacrificing any performance parameters. The purpose of this is to reduce
material costs by utilizing less material in the manufacturing of smaller cables and to grow our customer
base by providing smaller cables which are able to fit in smaller or congested ducts and conduits.

The scope of this project included a phased approach for the design, testing, customer trials, and
transition to manufacturing for the new MicroFiber Cable Project. Project success was defined as
designing and manufacturing a MicroFiber cable product which passed all performance and
mechanical testing, achieved the goal of smaller cable diameters, received positive customer
feedback in trials, and was able to be transitioned to production without significant capital
investments.

2. Project Team Staffing

This section provides information about who the project team consisted of. This usually includes
names, titles, project role, and contact information. This information is useful when questions
may arise on future projects which are similar in nature. It also provides a useful list of points of
contact should more information be needed on lessons learned from the project.
The Cable Tech MicroFiber Project consisted of a skilled and knowledgeable team. The chart
below provides information about MicroFiber Project team members:

Name Title Project Role Contact

A. Smith VP Technology Project Sponsor [email protected]
B. White Asst Mgr PMO Project Manager [email protected]
C. Black Design Tech Design Engineer [email protected]
D. Green Testing Tech Testing Engineer [email protected]
E. Blue Material Tech Materials Engineer [email protected]
F. Production Tech Production Engineer [email protected]
Brown

MicroFiber project team members utilized standard project management methodologies to

successfully complete the project. The project team was a matrixed organization with full
support from functional managers and senior leadership. Effective communication, detailed
planning, stakeholder involvement, project management tools, and organizational structure all
played key roles in the project’s success.

Staffing lessons from previous projects were used in building the project team. Rather than
allocate too many resources, as some past projects have done, the MicroFiber team was staffed
with one resource per development area. The project sponsor made clear to the project manager
that if any additional resources were required, they must be requested through standard Cable
Tech channels and the impact on project cost and schedule would need to be defined.

3. Project Deliverables (Planned vs. Actual)

This section of the Post Project Review describes the expected outcomes of the project as it was
originally planned and compares these outcomes against the actual outcomes. This is beneficial
in defining any occurrences of scope creep or whether a project may not have been completed as
planned. This is helpful information for lessons learned and for future project teams conducting
similar projects.

The Cable Tech MicroFiber Project has been completed successfully. There were planned
deliverables for each phase of this project as well as for the completed product. This section
highlights the planned deliverables and compares them to actual deliverables as they occurred.

MicroFiber Design

Planned Deliverable Actual Deliverable Summary

Complete cable specification kit and Complete cable specification kit and This deliverable was
design parameter package design parameter package completed as planned

MicroFiber Production (Prototype)

Planned Deliverable Actual Deliverable Summary

Range of prototype MicroFiber Range of prototype MicroFiber This deliverable was
cables for testing and customer trials cables for testing and customer trials completed as planned

MicroFiber Testing

Planned Deliverable Actual Deliverable Summary

Testing documentation package Testing documentation package This deliverable was
establishing all product limits and establishing all product limits and completed as planned
thresholds thresholds

MicroFiber Final Project Deliverables

Planned Deliverable Actual Deliverable Summary

Final cable product line with Final cable product line with This deliverable was completed
standard performance criteria standard performance criteria and as planned
and diameters reduced by 10% diameters reduced by 10%
MicroFiber production MicroFiber production guidelines This deliverable was completed
guidelines and specifications for and specifications for operational as planned
operational manufacturing manufacturing
Completed Technical Reference Technical Reference Package for Material and vendor list is
Package for product users product users with exception of under review with legal
approved material/vendor list department and will be added
upon approval

In summary all documented project deliverables have been met by the MicroFiber project team.
All stakeholders have submitted their feedback and acknowledge that there are no deliverables
which were missed or omitted for this project.

4. Transition to Operations

Here, the Post Project Review describes the transition of the project to operations upon
completion. This section should include any difficulties or challenges faced during this
transition. This section should also highlight what went right during the transition so future
projects may reference and use best practices to improve project performance.

Transition of a project to an operational environment can be a challenging task for many

organizations. Cable Tech ensures that R&D and operations leadership practice effective
communication throughout a project’s duration to ensure continuity once the transition takes
place. Additionally, Cable Tech encourages that all project managers include senior operations
leadership as stakeholders in all projects.

The MicroFiber project was successfully transitioned to operations as a direct result of effective
communication and detailed planning. The inclusion of the Vice President of Operations, shift
managers, and business unit leaders as stakeholders ensured a collective approach to the creation
of an improved product which could be transitioned smoothly to a manufacturing environment.
Future projects can benefit by involving operations staff early in the project planning phase and
soliciting input from operations team members on important considerations for the project from
an operational perspective. The MicroFiber team was not only successful in communicating and
planning with operations staff but they leveraged these strengths to determine expectations of
what operations required as part of the transition. In this case, the project team was able to
develop complete technical data packages and process specifications for operations to use in the
manufacturing of the MicroFiber product. This resulted in an almost seamless transition of
product lines on the manufacturing floor. If the operations staff had not been included as
stakeholders nor participated in the project planning, it is likely this step would have been
overlooked and the project would have encountered delays and additional costs.

One area of improvement would be to build all prototype products on manufacturing lines with
operations personnel assisting as opposed to R&D personnel building products in the R&D lab.
This would have allowed operations personnel to gain familiarity with the product earlier in the
project’s lifecycle and facilitated an even smoother transition period.

5. Project Costs

This section of the Post Project Review should describe how the planned or budgeted costs for
the project compare with the actual costs. Costs may be affected by scope creep, poor planning,
schedule delays, progressive elaboration, or many other factors. This section should highlight
whether or not costs were controlled adequately and if there were additional or excessive costs
the reasons should be stated. It is important to communicate why costs were met or may have
been higher than planned so future projects can benefit from this information in building a more
effective project management methodology within the organization.

The budgeted cost for the Cable Tech MicroFiber Project was set at $6,600,000. This cost was
broken out by project phase in the following chart with actual costs compared to the
planned/budgeted cost.

Project Phase Budgeted Actual Comments

Cost Cost
Product Design $1,100,000 $1,050,000 Design costs came in under budget
Prototype Builds $2,000,000 $2,075,000 Prototype builds were over budget due to errors
resulting in the rebuilding of one cable
Testing $250,000 $250,000 Testing costs were on budget
Trial Cable Builds and $2,500,000 $2,400,000 Trial cables were built and installed under budget
Installation
Transition to $750,000 $750,000 Transition costs were on budget
Operations

Total actual costs of the MicroFiber Project amounted to $6,525,000. The MicroFiber project
was not only successful in meeting all of its objectives and deliverables, but by completing under
budget, it also allowed Cable Tech to allocate $75,000 to other important initiatives.
Product design was completed under budget. This was due primarily to the fact that the
MicroFiber product’s performance specifications are identical to our previous product line and
that the only required change was reducing the cable size and diameter. This resulted in slightly
less design work than anticipated.

Prototype builds was completed over budget. The reason for this was that one of the cable lines
malfunctioned during the build and a cable had to be re-built. The line time, labor, and material
waste were not included in the budgeted amount for this portion of the project resulting in an
overrun.

Trial cable builds and installation was completed under budget. The primary reason for this is
that the smaller cable diameters allowed for easier installation of the cables at trial customer
premises. This resulted in taking less time for installation which resulted in lower actual cost for
this portion of the project.

Testing and transition to operations completed on budget for this project. Past project
documentation was used in developing our budgets for these portions of the project. By utilizing
Cable Tech project archives and standard best practices we were able to plan accurately and
complete the work according to plan.

6. Project Schedule

This portion of the Post Project Review describes the project’s planned schedule or timeline and
how the project measured against this plan. This information is helpful in identifying and
understanding what may have contributed to project delays or allowed the project to complete
early or on time. This can then be used by the team members on future projects or be referenced
by other project teams for use on future projects. Archiving project information during the
project closure phase is one of the best ways for an organization to improve its project
management methodologies and effectiveness.

The Cable Tech MicroFiber Project schedule called for a one year project with initiation
beginning on January 1, 2011 and project closeout ending on December 31, 2011. There were
initial concerns by the project team that the schedule would potentially slip due to the small
number of resources assigned to the project. The below chart shows each phase of the project
lifecycle, the planned schedule dates, and the actual completion dates of each phase.

Project Phase Scheduled Completion Actual Completion Comments

Initiation January 15, 20xx January 15, 20xx Completed on time
Design February 28, 20xx February 28, 20xx Completed on time
Prototype Build April 30, 20xx April 30, 20xx Completed on time
Testing June 30, 20xx June 30, 20xx Completed on time
Trial Build/Install September 30, 20xx September 30, 20xx Completed on time
Transition to Ops November 30, 20xx November 30, 20xx Completed on time
Project Closure December 31, 20xx TBD Progressing on time
Many Cable Tech projects do not complete a thorough project closure phase. This is usually due
to earlier project phases completing late which results in having to cut short or omit this
important final phase. The MicroFiber Project successfully completed each phase on time which
can be attributed to effective planning and communication as well as sponsor and executive level
support of this important initiative. Throughout the project there was a strong sense of
cooperation across the organization as the importance of this project was stressed and its benefits
were realized.

During the initiation and planning phases there was concern among the team members that there
were inadequate resources assigned to this project. However, due to the many similarities
between MicroFiber and the previous product line, additional resources were not needed and the
assigned staff was adequate to complete all work packages in the planned timeframes.

The only project phase which encountered schedule problems was the prototype build phase.
This was due to a cable line malfunctioning and a prototype cable having to be rebuilt. The
project team was able to reallocate its resources and complete the rebuild within the planned
timeframe.

7. Recommendations

This section of the Post Project Review Template highlights any recommendations and lessons
learned which would be of use on future projects. This is a valuable part of the project closeout
phase and organizational project archives. In the project planning phase one of the first steps is to
research organizational archives to identify useful information for planning and executing a
project. These recommendations and lessons learned are one of the most important pieces or
project success in any effective project management group.

The MicroFiber Project was an example of a carefully planned and successfully executed project
for Cable Tech. However, it is not without its recommendations or lessons learned.

Recommendation #1:
Involve operations personnel during the initiation phase for new product development projects so
they are involved during every step of the planning and execution process. This is imperative in
establishing familiarity with the product and processes as well as establishing expectations of
what operations will require during transition.

Recommendation #2:
Build prototype products on actual manufacturing lines with operations support. In addition to
the familiarity discussed in recommendation #1, this would provide verification that
manufacturing lines are configured and capable of manufacturing the new product prior to
transition to operations.

Recommendation #3:
Researching Cable Tech project archives was extremely beneficial in establishing budgets and
schedules for project phases. As a result of studying documentation from similar past projects the
MicroFiber project team was able to accurately determine budgets, work packages required, and
resource allocation.

Project Acceptance
Formal Project Acceptance Requires a Signature by the Project Sponsor or Customer. Before a
project can be closed out the Project Manager needs formal acceptance of the project by the
Project Sponsor or Customer. Formal acceptance is one step of the close out process and doesn't
release the Project Manager or resources from the Project. It is the Project Manager's
responsibility to release resources during the closing process and ensure that all closing tasks are
completed.

PROJECT ACCEPTANCE TEMPLATE

This document establishes formal acceptance of all the deliverables for the (Project Name)
project. The (Project Name) project has met all the acceptance criteria as defined in the
requirements document and project scope statement. A project audit has been performed to
verify that all deliverables meet performance and product requirements. Additionally a product
evaluation has been performed and determined that all products meet the quality and functional
requirements defined within this project.

Transition to Operations has been completed. The live system has been handed over to
Operations and the transfer of knowledge from the Project Team to Operations has also been
completed. All training has concluded and the System Operations Guide has been handed over to
Operations.

The Project Manager is authorized to continue with the formal close out of this project. The
closeout process will include a post-project review, documentation of lessons learned, release of
the Project Team, close out all procurements and archive all relevant project documents. Once
the closing process is completed the Project Sponsor will be notified and the Project Manager
will then be released from the project.

Sponsor Acceptance

Approved by the Project Sponsor:

__________________________________________                              Date:________________
____
(Project Sponsor Name)
(Project Sponsor Title)

Transition Out Plan

A well written Transition Out Plan will help make the transition seamless at the end of a project
or contract. Many Request for Proposals (RFP's) require a draft contract transition out plan to be
submitted with your proposal. This template is a good starting point as it includes many of the
considerations when transitioning a project or contract to a new contractor or back to the
customer. You must be sure to adjust it to the specific needs of your organization, the specific
contract and the customer.

TRANSITION OUT PLAN TEMPLATE

1. Executive Summary

The purpose of the executive summary is to describe the transition plan at a high level and what
the plan should accomplish. This section of the transition plan should include an overview and
history of the contract, who the contract is currently with, who it is transitioning to, and the
timeframe/period of transition.

This plan formally documents the process for the transition of the powers, duties, activities, and
functions of tasks and tools for the PayBase contract (Contract # 11-10159). It describes the
approach to transitioning work and employees from ABC Corporation (incumbent contractor) to
XYZ Inc. The PayBase contract is for the creation and implementation of a new payroll database
for Smith Consulting Group (SCG). This database will allow SCG to integrate all payroll
tracking and reporting into a consolidated database. This contract is currently with ABC
Corporation and will transition to XYZ Inc. will be completed no later than 180 days after
contract award. The period of performance is from 1 January 2011 to 31 December 2011. The
value of the contract is $2,000,000.00.

2. Transition Approach

This section of the contract transition out plan discusses the overall approach to the transition.
Some items which must be considered are: will you scale down your staff during the transition or
will you bring in additional staff to handle and manage the transition? How long is the transition?
What are your assumptions (i.e. the staff of the new contractor will be available onsite to
participate in the transition and receive knowledge transfer, etc.)?
For this transition, ABC Corporation will maintain its existing staff on-site throughout the
transition period. No additional staffing requirements are anticipated to complete the transition to
XYZ Inc. The transition is expected to take 60 days to complete. Immediately prior to the
transition, ABC Corporation will stand up its transition team in order to facilitate the activities
necessary for successful transition. It is assumed that XYZ Inc. will have its staff on site at the
beginning of the 60 day transition period and will establish a similar team to work with ABC
Corporation to coordinate the contract’s transition. It is also assumed that SCG will provide
adequate workspace for both contractors throughout the duration of the transition. SCG should
also designate a transition project manager to work with both contractors throughout the
transition.

3. Transition Team Organization

This section of the transition out plan should provide an organizational chart showing all
resources and their roles in the transition (i.e. Transition Project Manager, etc.). Key team
members should be from both the incumbent and new contractors as well as the customer.

The following chart illustrates the transition team members from SCG, ABC Corporation, and
XYZ Inc. as well as the roles and responsibilities of each team member.

Organzation Title Roles/Responsibilities

SGC Transition Coordinate activities between contractors throughout transition;
Project Manager provide workspace for all transition staff; facilitate transition
meetings as required
SCG Contracting Responsible for overseeing all contract actions and deliverables;
Officer responsible for ensuring accountability on all funding and budget
items pertaining to the contract
ABC Corp. Transition Work with SCG and XYZ PMs to coordinate and schedule all transition
Project Manager activities; provide weekly reporting on transition progress; ensure all
applicable property and tools are included as part of transition
ABC Corp. IT Transition Ensure all IT activities are completed during transition; document all
Lead IT processes, tasks, and activities for transition to XYZ
ABC Corp. Configuration Ensure all training documentation is complete; ensure completion of
Manager user and technical manuals; ensure all documentation is in
accordance with SCG standards; ensure proprietary materials are not
part of transition
XYZ Inc. Transition Work with SCG and ABC PMs; ensure all transition deliverables are
Project Manager received and understood; identify any gaps in transition activities
XYZ Inc. IT Transition Ensure continuity of all IT activities throughout transition; ensure
Lead receipt of adequate IT documentation of all processes, tasks, and
activities
XYZ Inc. Configuration Ensure all training documentation received addresses all planned
Manager training items; ensure standardization of all transitioned
documentation
4. Workforce Transition

It is not uncommon for the workforce to transition from one contractor to another as part of the
contract transition. The workforce may stay in place with the client or customer and simply “re-
badge” from the incumbent to the new contractor. It is also common for the incumbent
workforce to leave the site once the transition is completed and approved. In order to set
expectations and allow for adequate transition planning, the workforce must be determined and
communicated ahead of time.

For this contract transition, all workforce members will remain with their current organization.
The incumbent (ABC Corp) workforce will remain on-site to perform their transition activities
until such time that the transition is completed and approved by all parties. The new contractor
(XYZ Inc.) will ensure its workforce is on site 60 days prior to transition completion. This will
allow adequate time to perform all transition activities. SCG will provide additional temporary
workspace for XYZ Inc. employees until transition completion, at which time the workforce will
occupy the vacated locations of the outgoing ABC Corp workforce.

5. Work Execution During Transition

Discuss the level of work which is to be performed during the transition period and the impact of
the transition on that work (i.e. system maintenance, software development, support services,
etc.).

Throughout the transition of this contract, work will continue to be performed by ABC Corp in
accordance with the approved project schedule and work breakdown structure (WBS) in place.
The transition management team will ensure that XYZ Inc. employees work alongside their ABC
Corp. counterparts; however, ABC will maintain all responsibility for tasks and deliverables. At
the end of the 60 day transition period, and upon transition approval, XYZ Inc. will assume full
responsibility for all tasks and deliverables.

6. Subcontracts

Here the project transition out plan documents all the existing contracts and if/how they will be
transitioned. It should contain this information in a table format (subcontract agreements,
software/hardware maintenance contracts, etc.).

The following chart illustrates the subcontracts in place which are in support of SCG’s PayBase
activity. These subcontracts apply to third party tasks to ensure all required cabling and facilities
functionality is in place to support the PayBase project.

Subcontract Awarded Tasks

# To
11-10010 CableQuest Perform cabling work within datacenter to support PayBase database
functionality
11-10020 BuildTech Build out existing data center facility to house additional servers to ensure
PayBase database functionality
7. Property Transition

7.1 Government Furnished Equipment (GFE)

This section of the transition plan describes the transition of any equipment for a scenario where
the customer is a government entity and provides the contractor with government property. This
property may include hardware such as laptops/PCs, software bundles or add-ons, portable
electronic devices (PEDs), and security badges. Typically, GFE will be turned back over to the
government customer during a transition and may or may not be re-issued to the new contractor.

As part of this transition, all GFE provided to ABC Corp under the PayBase contract will be
turned in to the government upon completion and approval of the transition phase. GFE includes
laptop computers, all PEDs, flash and external hard drives, and employee ID badges. All
electronic devices will be re-imaged by government IT personnel and re-issued to appropriate
XYZ Inc. employees.

7.2 Incumbent Owned Equipment

Equipment owned by the incumbent contractor will usually remain with them when they
transition off of the contract. However, there may be instances where incumbent owned
equipment supports customer applications and services. This section should state that incumbent
owned equipment will remain with the incumbent - and identify options where this equipment
may be available for purchase by the new contractor or customer for their use (i.e. application
server and application for helpdesk, etc.).

All incumbent owned equipment will remain with the incumbent upon completion and approval
of the transition. This equipment includes incumbent-issues laptops and PEDs, organizational
tools, organizational process maps, and company ID badges. If it is determined that any
incumbent owned equipment is required to stay with the customer to ensure successful
completion of the contract, the customer and incumbent contracting officer representatives will
coordinate procurement of the equipment through the customer’s established procurement
management process.

7.3 Intellectual Property

This section of the contract transition out plan should describe how intellectual property will be
handled as part of the transfer process. Intellectual property may include various documentation,
supplier and subcontractor information, service agreements, or original designs or plans.
Intellectual property generates many legal considerations and may include the completion of
non-disclosure agreements (NDAs) between the incumbent and the customer. Intellectual
property may be transferred, sold, or retained by the incumbent depending on the contractual
agreements in place.

Per the PayBase contract, all intellectual property which is a direct result of work on the contract
deliverables will be transitioned to the new contractor in order to ensure the successful
completion of the project. The contract pricing takes intellectual property into consideration and
as such, any resulting intellectual property will be owned by the customer.

7.4 User Accounts and Passwords

This section should discuss how any accounts will be transitioned, who they will be transitioned
to (i.e. system administrator accounts). Provide a table of all user accounts to be
transitioned/disabled.

As part of the contract transition, various user account accesses and authorizations must be
created and disabled. Currently ABC personnel listed in the chart below possess the user
accounts and access necessary for contract deliverables. The listed XYZ Inc. employees will be
granted access on the first day of the contract transition phase. Once transition is complete and
approved, all ABC Corp personnel’s user accounts will be disabled.

User Account ABC Corp. XYZ Corp.

SAP Master User IT Transition Lead and Configuration IT Transition Lead and Configuration
Manager Manager
Database Administrator IT Transition Lead IT Transition Lead
Customer Intranet Master Transition PM and IT Transition Lead Transition PM and IT Transition Lead
User

8. Knowledge Transfer

This section of the project transition out plan should discuss how knowledge will be transferred
from the incumbent staff to the staff of the new contractor (documentation/instruction manuals
including as-built documents, formal training classes, one-on-one training/knowledge transfer,
etc.). This is an important consideration as the transfer of knowledge is what provides continuity
for the contract.

For this transition, knowledge transfer will occur over the entirety of the 60 day transition period.
The knowledge transfer will take place via various methods. The incumbent PM will coordinate
two formal classroom training sessions to be conducted by the incumbent IT Transition Lead.
These sessions will focus on the specific IT concerns related to the database tasks and activities.
The incumbent PM will also coordinate two formal classroom sessions to be conducted by the
incumbent Configuration Manager. These sessions will cover documentation requirements and
organizational processes and assets. These sessions will be completed no later than 15 days prior
to the end of the 60 day transition period. Additionally, all XYZ Inc. staff will work alongside
their ABC Corp counterparts throughout the 60 day period in order to gain familiarity with the
database, tools, processes, and organizational assets. The PMs from ABC Corp., XYZ, Inc., and
the customer will meet no later than 10 days prior to transition completion in order to determine
if any further training or knowledge transfer is required.
9. Schedule

This part of the transition plan should contain a GANTT chart schedule of the transition. The
complexity of the transition will dictate the level of detail required in the schedule. However, all
major milestones as well as transition start and completion dates should be included at a
minimum.

The following GANTT chart illustrates the schedule for transition of the PayBase contract from
ABC Corp. to XYZ Inc. Any changes to this schedule will require review and approval from the
customer and all other parties.

10. Handover and Acceptance

This section of the contract transition out plan should discuss how the customer will formally
accept the handover at the end of the transition. This may include whether or not there’s a
checklist for acceptance or formal sign-off. There are typically several people who need to
accept the handover (i.e. security office for all badges, IT Manager for system accounts,
Contracts Manager, etc.).

The customer will make the determination of when transition is completed and will provide
formal acceptance indicating such. To do this, the customer’s transition PM will utilize the
established transition checklist in order to determine that all activities associated with the
transition have been completed. The customer’s transition PM will also meet with the transition
PMs from each contractor to ensure that all concerns and issues have been met and addressed
appropriately. Once the customer’s transition PM has formally accepted the transition, the
checklist and supporting documentation will be signed and accepted by the customer’s project
sponsor and the company’s human resources director. The last step is the formal acceptance and
signature of the customer’s contracting officer representative. It is only after all of these
approvals and signatures are in place that the transition will be considered complete.