The purpose of the Transition to support process is to prepare for a smooth transition of the deliverables to the support and main-tenance organization and to verify that all deliverables and other services, such as user training and installation, has been received as agreed upon.
Transition to support process Starts when the software re-quirements are being devel-oped.
Ends when the software and other deliverables have been turned over to the support or-ganization.
Input: Deliverables Output: Maintenance plan Transition to support group
The participants to consider for this process should be those in
6 Processes
© Daniel Svennberg 2001 111
are to install, maintain and support the product such as the fol-lowing roles: acquisition manager, technical manager, contract manager, administrator, technical expert, domain expert, legal expert, maintenance and support staff, and contractor, collabo-rating contractor, and subcontractor.
Minimal process activities
Identify the support and maintenance organization.
Identify and provide a budget for the support and mainte-nance organization early in the project, before the request for proposal is issued. Will maintenance be performed by the ac-quirer organization or will it be outsourced?
Identify the deliverables to be transferred.
Make a list of the deliverables that are to be transferred to the support organization, such as maintenance and support documentation, software, training materials, configuration management systems, etc.
Plan the installation of the software product.
Establish installation procedures regarding schedule, access to facilities, personnel, availability and access to systems and equipment, approval of installation, etc.
Review the results of the user training activities.
Make sure that the agreed upon user training has been per-formed.
Verify that all deliverables has been received as specified.
Additional controlled process activities
Prepare the support and maintenance organization.
Transfer and customize necessary processes from the devel-opment organization to the support organization. A mainte-nance plan should be developed. See the Maintemainte-nance plan on page 46.
Review the deliverables and preparations prior to transfer.
Review the usability of the software, its readiness for lation, status of user training, user manuals, status of instal-lation preparations and activities. Review the readiness of the software for transition, the maintenance plans and manuals, the status of transition preparation activities. Re-view copyright and licensing concerns addressed and agreed to. Review concerns regarding back-up copies of the soft-ware.
Additional robust process activities
Test the support capabilities of the support and mainte-nance organization.
Before transferring responsibility for the software, the port organization needs to demonstrate its capability to sup-port and maintain the software:
o Does it have the appropriate hardware, software, physical, fiscal, and personnel resources?
o Does it have a maintenance plan and other documenta-tion, processes and procedures?
o Does it have a configuration management system ca-pable of supporting the software?
o Is the personnel trained?
Maintain configuration and change management through-out the transition.
6 Processes
© Daniel Svennberg 2001 113
6.12 Post partum
The purpose of the post partum1 process is not about passing judgment, but to learn from experience. What can be done bet-ter on future acquisition projects? It also includes documenting data on the project effort and on the contractor’s performance for future reference. Apart from the frameworks mentioned in appendix A, this process is based upon Kerth (n.d.).
Post partum process
Starts when the project has been finalized.
Ends when the project has been sufficiently reviewed and documented for future refer-ence.
Input: Project data Output: Post partum Post partum group
Preferably representatives from all involved organizations and roles should participate in the post partum.
Minimal process activities
Form a post partum group.
Also assign responsibility, authority, and accountability for the post partum activities. Make sure that the people in-volved in the process are trained in how to perform the process activities.
Allocate adequate resources for post partum activities.
Resources to consider are: funding, people, tools, equipment, facilities, etc.
1 Post partum means “after birth” in Latin. I find this to be a more appro-priate name for the process instead of the more common term post mortem, which means “after death.”
Set a goal for the post partum.
There can be many different purposes for holding a post par-tum:
o To capture effort data in order to understand the exist-ing process, or to improve the existexist-ing process, or to provide data for future acquisitions, or to identify training needs, etc.
o To document what happened and why. To capture the collective wisdom.
o To repair damage to the team.
o To enjoy the accomplishment.
Plan the post partum.
See the Post partum plan on page 57.
Prepare for the post partum.
Inform the participants that the post partum is a learning experience and not a blame session. Establish rules that cre-ate a non-threcre-atening atmosphere for the post partum.
Gather the data that will be analyzed during the post partum such as data on efforts, resources, product quality, etc. Each participant should refresh their memory and individually review what happened.
Conduct the post partum review.
Review what happened during the acquisition project and identify good and bad acquisition practices. What went wrong and what went right? Review the efforts expended regarding budget, staff, schedule, etc. Identify deviations and reasons to them. What was accomplished? What was the quality of the delivered product? Review any special diffi-culties and how they were handled. Review the contractor’s performance and compliance with requirements. If the con-tractor doesn’t participate in the post partum review, a post partum from the contractor should be reviewed. Give
im-6 Processes
© Daniel Svennberg 2001 115
next time?
Document data and lessons learned.
Identify and document the software acquisition lessons learned, project data, customization data, and data on the contractor’s performance. See the Post partum on page 58.
Additional controlled process activities
None.
Additional robust process activities
Get a skilled facilitator.
A suitable facilitator is preferably an outsider to the organi-zations involved in the project, though knowledgeable about software projects and with good people interaction skills.
7 Results and summary
“Caution: Cape does not enable user to fly.”
– Batman costume warning label
This chapter summarizes the guidelines and gives an outlook on possible future research on software acquisition manage-ment.