The APM Body of Knowledge 6th edition defines handover as: “The point in the life cycle where deliverables are handed over to the sponsor and users.” . It might also be the end of the defects and liability period (essentially the first year’s warranty period of a building). It could be when the on-site support from the project team leaves site, when there are
no more snags noted on the snagging list and all are signed off as complete, or once the last of three post-occupancy evaluations is completed. It could be when no members of the project team are involved on a scheme anymore and the project has completely transitioned to business as usual operations. Perhaps it is financial close, or it might even be argued that it is when the benefits established at the outset have been delivered (which could be when the project deliverables have completed their lifespan and been decommissioned). The crucial requirement is to agree in advance and ensure all parties are working to the same definition and understand their responsibilities accordingly.
The Product Transition Process is used to transition a verified and validated end product that has been generated by product implementation or product integration to the customer at the next level in the system structure for integration into an end product or, for the top-level end product, transitioned to the intended end user.
The form of the product transitioned will be a function of the product life cycle phase success criteria and the location within the system structure of the WBS model in which the end product exists. The systems engineer involvement in this process includes ensuring the product being transitioned has been properly tested and verified/validated prior to being shipped to the next level stakeholder/customer.
Product transition occurs during all phases of the life cycle. During the early phases, the technical team’s products are documents, models, studies, and reports. As the project moves through the life cycle, these paper or soft products are transformed through implementation and integration processes into hardware and software solutions to meet the stakeholder expectations. They are repeated with different degrees of rigor throughout the life cycle. The Product Transition Process includes product transitions from one level of the system architecture upward. The Product Transition Process is the last of the product realization processes, and it is a bridge from one level of the system to the next higher level.
The Product Transition Process is the key to bridge from one activity, subsystem, or element to the overall engineered system. As the system development nears completion, the Product Transition Process is again applied for the end product, but with much more rigor since now the transition objective is delivery of the system-level end product to the actual end user.
Depending on the kind or category of system developed, this may involve a Center or the Agency and impact thousands of individuals storing, handling, and transporting multiple end products; preparing user sites; training operators and maintenance personnel; and installing and sustaining, as applicable. Examples are transitioning the external tank, solid rocket boosters, and orbiter to Kennedy Space Center (KSC) for integration and flight. Another example is the transition of a software subsystem for integration into a combined hardware/software system.
The end product or products to be transitioned (from the Product Validation Process): The product to be transitioned can take several forms. It can be a subsystem component, system assembly, or top-level end product. It can be hardware, analytical models, or software. It can be newly built, purchased, or reused. A product can transition from a lower system product to a higher one by being integrated with other transitioned products.
Documentation including manuals, procedures, and processes that accompany the end product (from the Technical Data Management Process): The documentation required for the Product Transition Process depends on the specific end product; its current location within the system structure; and the requirements identified in various agreements, plans, or requirements documents. Typically, a product has a unique identification (i.e., serial or version number) and may have a pedigree (documentation) that specifies its heritage and current state. Pertinent information may be controlled using a configuration control process or work order system as well as design drawings and test reports. Documentation often includes proof of verification and validation conformance. A COTS product would typically contain a manufacturer’s specification or fact sheet. Documentation may include operations manuals, installation instructions, and other information.
Product transition-enabling products, including packaging materials; containers; handling equipment; and storage, receiving, and shipping facilities (from existing resources or the Product Transition Process for enabling product realization)
Transitioning the product comprises of the delivery of the final end product to the customer or user that will use it in its operational environment. The end product might be one of several circuit cards that will be integrated together to form the final unit that is delivered. Or that unit might also be one of several units that have to be integrated together to form the final product.
Prepare to Conduct Transition
The form of the product being transitioned affects transition planning and the kind of packaging, handling, storage, and transportation that is required. Other tasks in preparing to transition a product involve making sure the end product, personnel, and any enabling products are ready for that transition. This includes the availability of the documentation or models that will be sent with the end product, including proof of verification and validation conformance.
Prepare the Product for Transition
Whether transitioning a product to the next room for integration into the next higher assembly, or for final transportation across the country to the customer, care should be taken to ensure the safe transportation of the product. The requirements for packaging, handling, storage, training, and transportation should have been identified during system design. Preparing the packaging for protection, security, and prevention of deterioration is critical for products placed in storage or when it is necessary to transport or ship between and within organizational facilities or between organizations by land, air, and/or water vehicles.
Transition the Product
The end product is then transitioned (i.e., moved, transported, or shipped) with required documentation to the customer based on the type of transition required, e.g., to the next higher level item in the product hierarchy (often called the Product Breakdown Structure [PBS]) for product integration or to the end user. Documentation may include operations manuals, installation instructions, and other information.
Delivered operational end product for end users: The appropriate documentation is to accompany the delivered end product as well as the operational end product appropriately packaged. Documentation includes applicable final installation, operation, user, maintenance, or training manuals; applicable baseline documents (configuration baseline, specifications, stakeholder expectations); and test results that reflect completion of verification and validation of the end product. If the end user will perform end product validation, sufficient documentation to support end user validation activities is delivered with the end product.
The process is complete when the following activities have been accomplished: For delivery to the end user path, the end products are installed at the appropriate sites; appropriate acceptance and certification activities are completed; training of users, operators, maintainers, and other necessary personnel is completed; and delivery is closed out with appropriate acceptance documentation.
Factors for Successful handover of projects