Chapter 6 - Deploying Phase

Article
12/05/2007

Goals for the Deploying Phase

Figure 6.1: The Deploying Phase of the MSF Process Model

The overarching goal of the Deploying Phase is to place the solution into a production environment. Supporting goals include deploying the solution technology and components, stabilizing the deployment, and transitioning the project to operations and support. After the deployment, the team conducts a project review and a customer satisfaction survey. Stabilizing activities may continue during this period. The Deploying Phase culminates in the Deployment Complete Milestone, when the team obtains final customer approval of the project.

The tasks summarized in Table 6.1 need to be completed during the Deploying Phase. This project guide describes the processes and roles required to accomplish them. Detailed information specific to each migration project about each task, especially technical information, is provided in the migration guide for that project.

Table 6.1 Major Deploying Phase Tasks and Owners

Major Tasks	Owners
Completing deployment preparations The team updates the deployment plan installs, configures, and tests hardware and software components.	Release Management, Development
Creating operations procedures The team creates and documents procedures and defines checkpoints to help the operations team monitor and maintain the solution.	Release Management, Development
Deploying the solution The team deploys the core technology and completes site deployments.	Release Management, Development
Stabilizing the deployment Project team and operations work toward a predefined state of completion for the solution.	Project Team
Transferring ownership to operations The team formally hands over responsibility for the solution to the operations team.	Release Management
Closing the Deploying Phase The team meets the Deployment Complete Milestone requirements and later completes post-project reviews with the customer and project team.	Project Team

Team Focus during the Deploying Phase

Table 6.2 addresses the tasks described previously, but considers them from the perspective of the team roles.

The primary team role driving the Deploying Phase is Release Management.

Table 6.2 Role Cluster Focuses and Responsibilities in Deploying Phase

Role Cluster	Focus and Responsibility
Product Management	Customer feedback, assessment, and sign-off
Program Management	Solution/scope comparison; stabilization management
Development	Problem resolution; escalation support
User Experience	Training; training schedule management
Test	Performance testing; problem identification, definition, resolution, and reporting
Release Management	Site deployment management; change approval

Completing Deployment Preparations

This section describes MSF recommendations for deployment and the operational procedures that a project team can use to quickly and successfully complete a UNIX migration deployment and then transfer responsibility to operations.

The project team can deploy the solution upon completion of the Stabilizing Phase in a variety of ways. One option is to use the organizations operations team to handle the actual deployment. If the operations team manages the entire deployment, representatives from the development team usually remain on the project for a period of time after going live to mitigate potential problems during the solutions transfer of ownership. A second option is to combine members from each group and create a separate deployment team. The Release Management Role is responsible for coordinating the required activities that ensure a successful deployment.

Deployment Procedures

During development, and especially as the Stabilizing Phase nears completion, the Release Management lead assigns deployment tasks to the staff. These individuals review the project status and test results and update the deployment plan, which was initially created during the Planning Phase. The team creates task-based procedures that help ensure a successful deployment. During each of the previous phases, the team gathered information that identified what tasks need to be completed before transferring the solution. The tasks summarized in the following section reiterate significant completion points.

Staging and Production Environments

To prepare for deployment, the physical infrastructure, system software, and application software are tested, installed, and configured within their respective environments.

Physical Infrastructure

During the Planning Phase, the project team resolved the projects conceptual, logical, and physical architecture by considering the metrics of scale. The project team determined how it would configure the solution architecture, including the amount and specific types of hardware and software needed, how the software would be installed and configured on each computer, and what other components would be required to deploy and maintain the solution. For infrastructure migrations, the actual new physical and service hardware was completely built and tested, as that was the primary goal of the project.
System Software

The project team updates documentation of all commercial software (operating system, database platform, networking protocols, and so on) used for the solution and installs the software on each environments servers.
Application Software

The project team installs all commercial software applications required to support the environment including desktop tools such as spreadsheets or word processors.

Consult the vendor's various testing scenarios to verify and validate that the hardware and software are installed and configured correctly and there are no issues within each of the environments.
Custom Application Software (created or modified by the migration development team)

The project team finalizes documentation of all application software created by the development team for the solution and installs the custom application software on the environments servers. The testing conducted on custom applications should comply with the design and test requirements for each application.

Documentation

The project team and operations representatives will revisit and update the following documentation, ensuring it is ready for transfer to operations:

Deployment diagrams
Event-sequence charts from actual observations
Test plan including coverage for areas exposed in real use
Reliability plan
Security plan
Backup plan to prevent loss of data
Plan for analyzing system performance and solution usage
Plan for log handling and other administrative tasks
Disaster recovery plan
Business contingency plan
Training information

Customer Sign-off

The solutions key stakeholders review the collateral and solution and confirm it is ready for deployment. The project team prepares an affidavit reiterating that the key stakeholders have reviewed the solution and the accompanying collateral, and that they find the solution to be final and acceptable as it is.

Creating Operations Procedures

The operations team is responsible for many duties and tasks once it receives ownership of the solution. To facilitate the transition and help this team assume its assigned tasks, MSF recommends creating and documenting procedures and defining a series of checkpoints at this time.

Team Objectives

As mentioned previously, the operations team is represented on the project team throughout the project through the Release Management Role. As the Stabilizing Phase nears completion, the teams begin to transition into a deployment team. The operations team retains certain members of the development team to assist with deployment and stabilization, while other members will begin to disengage from the project. The deployment team also might recruit members from outside the projects environment.

Once the solution is successfully deployed, the operations team is responsible for maintaining the solution on a continual basis. This allows the team to proactively deal with problems. The team performs all daily maintenance procedures and provides low-level routine change management for the solution. Any large-scale changes are the responsibility of the Product Management Role or marketing function.

Team Roles and Responsibilities

The following personnel are involved in managing the successfully deployed solution:

Operations and support personnel routinely maintain and monitor the solution for low-level changes and ensure operation according to the defined operational requirements.
The administrative staff monitors capacity changes and collects user profiles.
The marketing staff analyzes the use and success of the solution in terms of the original plan, vision, and new add-ins. Marketing is also responsible for gathering and prioritizing change requirements to the solution overall.

Project Validation

Upon receipt of the solution ownership, the operations team immediately validates all collateral and equipment included in the transfer. This should proceed quickly because operations was represented throughout the project. The operations team validates the systems environment, equipment, software, configurations, and the following plans:

The disaster recovery plan

During the Planning Phase, the team created a disaster recovery plan establishing what the team expects to happen to the solution, its equipment, personnel, and data should a crisis occur. At this time, the team reviews the document and validates and updates its contents.

The plan might include the list of personnel who are supporting each of the components and specify who takes responsibility to notify management and staff when a crisis occurs, where the team will reconvene after a disaster strikes, and what actions should be taken to close the system down prior to evacuating the premises.

Disaster recovery plans should also include information for less catastrophic events. Good disaster recovery plans should also include:
- Identification of all known potential failure modes.
- Documented recovery processes for each of these modes.
- Documented testing results illustrating test procedures that successfully forced the failure modes and verification that the recovery processes resulted in system recovery.
Documentation and training information, as well as backup tapes or archived files, must be stored off site.

The team also must ensure the training of support personnel who would be involved with maintaining or updating the solution, and ensure that proper channels or regulations are met in the event of a disaster.
The business contingency plan

During the Planning Phase, the team created a business contingency plan, establishing what will happen should business activities halt. At this time, the operations team reviews and validates the contents of the business contingency plan. If necessary, the team provides updated information on team members and other pertinent information to the plan.
The security procedures

During the Planning Phase, the team created a security plan. At this time, the operations team upgrades and confirms that all security procedures are in place. The team should ensure that all permissible personnel are aware of the security standards and rules to which this project adheres.

Procedural Checklist

The operations team is responsible for the solutions daily maintenance and routine care. The team should create a checklist to ensure that it is proactive when maintaining the system and that any potential issues are avoided as much as possible. Operation teams may want to include the following questions on the checklist:

Have the service packs, drivers, or new versions of hardware and software been rigorously tested? Is there a procedure set up to alert the team should these items fail?
Is the solutions capacity monitored on a daily basis? Is there an alert if additional equipment is required? What is the procedure to obtain new equipment?
How are critical diagnostic messages identified? What will the team do to provide immediate relief to the critical error messages?
What will the team do if something fails? Will the team use third-party tools to identify and correct these issues?
How will the operations team validate data integrity on a daily basis? How will the team make sure nothing is corrupt because of memory or program failures?
How will the team monitor the solutions components? If a component fails, how will the team rectify the problem?
What process will the team use for file and data backups?
What process will the team use for content changes?
What processes will the team use to ensure the system is providing the functionality that was intended, per the specifications?

Deploying the Solution

Because deployment into the production environment can be complex, a transition process provides a quality assessment to ensure that all elements are ready. Checklists and procedures are invaluable tools during this stage.

Transitioning to Deployment

As they learn new information, project team members continually update and revise the deployment plan during the developing and stabilization phases while testing the solution. This approach minimizes schedule delays caused by last-minute changes. The Release Manager must review and revise the deployment plan and confirm that the team has accomplished the following tasks:

The deployment strategy is reviewed and approved.
Setup, installation, configuration, test, operation, and support procedures are available, reviewed, and approved.
Deployment procedures are documented, reviewed, and approved.
Hardware and software components are available and tested.
The deployment team has clearly defined roles, and the assigned personnel are trained and available.
The project schedule has been reviewed and approved.
There is a plan and ample resources for ownership transfer to the operations team.

While both testing and production pilots are excellent practices, neither can completely reproduce the actual solution usage and performance experience after going into the live production environment. The amount of work and the increased level of activity that typically occurs in the weeks prior to deployment could lead to some issues being overlooked. It is vital that the project team continues to monitor the solution after deployment until the transfer of ownership is finalized. This allows the team to establish baseline performance records to determine whether performance is improving or deteriorating. If the stress and capacity tests are executed well, the team should have both test scripts and test results available that provide the baseline numbers.

It is important to compare the baseline numbers to the new numbers any time a change is made to the solution, including infrastructure and code components. It is best if the team makes one change at a time; otherwise, it is difficult to tell which change produced which effect. If performance does not improve as expected, continue to analyze the data and make adjustments as required. Monitoring continues on a regular basis, even after ownership is transferred to operations.

Working with Configuration Management

Configuration management serves the same purpose for a deployed solution that revision control serves for source code under development-as a repository of state information regarding the actual components deployed as part of the solution. Aspects of the configuration that are tracked include exact versions of software, precise contents of configuration files and settings, exact system and network topologies, and so on. Operations personnel can use this configuration information to control the deployment environment. Precise changes can be applied to the environment (and tracked in the configuration management system), allowing the effects of those changes to be identified, understood, and controlled.

When deploying the migrated solution, it is vital for the Release Manager to provide all information required by the operations team for tracking configuration information. Uncontrolled change in the deployed environment makes it very difficult to understand and control the behavior of the deployed solution. Regardless of the size of a configuration change or its urgency, the change must be tracked.

Checking Readiness to Deploy

Although the final decision to deploy involves several factors, the team makes the decision only after reviewing the test results and information gained by using checklists. Reviewing the checklists alerts the team to any issues that may influence the deployment. Although the lists are created to use before the actual deployment date, continuous review during deployment is beneficial to ensure that all the suggested tasks are accounted for and to alert the team to needed improvements in the organization of the process.

Not all of the listed items apply to every solution. Only the team knows which items are important to consider for its project. The checklists are comprehensive and, therefore, may have many items that do not apply to each project. However, it is always a good rule, regardless of the size or complexities of the solution, to review the suggested tasks and confirm that all details have been considered.

The checklists are not intended to be decision-making devices. If your team finds itself investigating the how and why behind a specific consideration, it probably indicates that the project is not ready to move forward. All specific settings and configurations should have been defined by the time the decision is made to move the solution to operations and deploy it. If, upon reviewing the checklists, the team discovers this is not the case, the team should reconsider the decision to deploy.

Solution Deployment Considerations Checklists

A potential approach to take when going live is to review each layer of the architecture and run through the critical considerations. The first three checklists address considerations relevant to the database tier, the application and business layer, and the presentation layer.

Database Tier Considerations

This checklist lists issues to review when installing the database tier.

Table 6.3 Database Tier Considerations Checklist

Number	Consideration	Completed
1	Were database statistics updated prior to launch? Are database indexes fragmented? At what period will this be checked again, and corrected, if necessary?
2	Have all COM components been registered on their servers? Has the system run for long periods without failure or system resource issues?
3	Did the team define, test, schedule, and sign off on maintenance plans?
4	Are database backups tested and online? Has restoration been tested on the same computer and on a different system? Are off-site backup procedures in place?
5	Are alerts defined for key problems and conditions? Who monitors the e-mail address to which these are sent? Are beepers used? Has the alert system been tested?
6	Are jobs defined for common tasks? Are roles assigned for emergency situations? Has a lead been defined for incident handling?
7	Has the latest build of the database from your development/QA environment to operations been migrated, installed, tested, and verified?
8	Has database security been addressed with appropriate logon accounts created? Is the system administrators (SA) account password blank? Are applications using the SA account or other account(s)?
9	Have all relevant service packs been loaded to the operations databases? Are the OS and installed service pack level well known and documented in case of failure and manufacturer support is required to be called in? Are security bulletins being maintained and monitored?
10	Has clustering failover been tested in the operations environment? How long does the failover take to complete? Are all key decision makers aware of the time needed to failover?
11	Has the operations database been loaded with clean data and have initial inventory levels been set? Have feeds from other systems been verified under load to ensure that system availability is unaffected at the time they run?
12	Is there a backup of the operations database as it stands the day before launch? Is it well known where this is stored?
13	Were data loads tested against the operations system? At what level (2x, 4x, 10x normal load)?
14	Has a disaster recovery plan (DRP) been established that includes database procedures? Who is the DRP team leader? Is the leaders contact information well known, and is a contingency leader appointed?
15	Has a time increment been established for the transaction log dumping that will be sufficient to recover activity to the satisfaction of the business? Has it been tested?
16	Have backup power systems been fully tested to ensure proper operation?
17	Are an appropriate number of replacement hard disks on hand in case of failure in an array?
18	Are the default client connection network library settings established on the server (typically, TCP/IP)?
19	Are all Database Application Server installation settings documented (sort orders, default language, and so on)?
20	Is the database running on the default port of 1433? If so, can this be changed to another port or ports to enhance security of the application without affecting proper operation? If so, change it.
21	Are ancillary, non-essential SQL Server services running (MS Search, OLAP)? Stop them if not required.
22	Are databases installed on the server that are not being used? Remove them (pubs, Northwind, and so on be careful not to delete system databases such as model, tempdb, master).
23	Are sufficient client access licenses and connections installed for the database server and the OS? Are these being monitored to assure that they do not reach their limit?
24	Is the database correctly tuned, and does it have the proper memory usage settings applied?
25	Is the database set for Auto Growth? Is disk space sufficient for the expected size of the data 6-12 months ahead?

Application and Business Layer Considerations

This checklist lists issues to review when installing the application and business layer.

Table 6.4 Application and Business Layer Considerations

Number	Considerations	Completed
1	Has the final release of your applications and components been given a release number, been archived, and then deployed?
2	Were all required environmental settings for the applications set and documented?
3	Were the proper security settings for the applications set and documented?
4	Were the appropriate service packs for the environment applied and documented?
5	Are all third-party software or components that are required by the system installed and documented (version numbers, vendor contact information, and so on)?
6	Are all the required DSNs for the applications defined and tested (correct net library settings are being used)?
7	Has connectivity between the middle-tier system and any back-end systems been tested? Under load? Monitoring of connection pooling to assure proper operation?
8	Are operations configurations for this tier backed up? Were scripts created to reset configurations in an emergency, or to bring up a new server? Are they in a well-known location?
9	Are the activation types for your COM+ application set properly? Has the application been tested with the consoles logged on and logged off to assure the proper identity is used? Have bogus transactional calls been attempted to simulate rollback integrity?
10	Are the queuing settings for your COM+ application set? Have calls into the queue been monitored through the cycle to assure they clear
11	Are you sure that no active debug code or logging exists in the operations components?
12	Has debugging in the COM+ application properties window been turned off?
13	Has server communication between servers been checked to assure that proper DNS resolution and routing, in case of multiple network interface cards (NICs), is happening?
14	Are spare disk drives and NICs available on-site?
15	Has security logging been implemented? Has impact on the system been assessed?
16	Have all non-essential services and open ports on the server been identified and closed?
17	Have any and all event log messages been identified and investigated?

Presentation Layer Considerations

The following checklist lists issues to review when installing the presentation layer.

Table 6.5 Presentation Layer Considerations

Number	Considerations	Completed
1	Are the IIS server properties configured? Is a script available and stored in a well-known place to reset the application settings or to bring up a new server?
2	Have the secure socket layer (SSL) tokens been applied, as needed? Are the tokens backed up onto portable media and stored in a well-known place for emergencies or new server configuration?
3	Are any certificates that might be required loaded? Are the certificates backed up onto portable media and stored in a well-known place for emergencies or new server configuration?
4	Has the latest release of the ASP code, images, and HTML files been given a release number, been archived, and then deployed?
5	Was an external connection used when testing the application against the operations system? The external connection should be similar to what a customer will use.
6	Are the appropriate DSNs for the ASP code set up and tested?
7	Have the unnecessary ISAPI filters been removed?
8	Are the custom error messages for IIS set?
9	Is the appropriate level of directory security set
10	Are the performance tuning properties for IIS set, documented (preferably scripted), and stored in a well-known place?
11	Are the appropriate operators for the server set?
12	Are the execution permissions and application protection levels set?
13	Have you enabled/disabled application logging, as required?
14	Does the OS have sufficient client access licenses for the expected peak traffic loads?
15	Have you checked your Personalization and Membership (P&M) settings and assured that they are appropriate for your solution? Is LDAP required to be accessible to the public? If not, is it blocked at the firewall? Is Anonymous access to LDAP disabled?
16	Has the team checked the LDAP settings for its LDAP services?
17	Has the team loaded the appropriate P&M schema settings for its solution in P&M?
18	Has the team mapped its Web servers to the proper P&M instance?
19	Has the team loaded the appropriate Site Server pipeline components onto its servers and the related pipeline configuration files? Are permissions on these files (as well as any .csc files) set so that users cannot download these files? Were all .csc and .pcf files (and dependent VBS scripts) examined to assure that they contain no clear text credentials for servers or databases?
20	Has the team set the default pipeline component settings?
21	Has the team installed the proper scriptors for its pipelines, if it is using them (see #18 for security considerations)?
22	Has the team applied all metabase or registry settings required to improve performance?
23	Have all non-essential Web server instances been disabled and/or removed from the IIS application?
24	Have all non-essential SMTP server instances been disabled and/or removed from the IIS application?
25	Have all non-essential FTP server instances been disabled and/or removed from the IIS application?
26	Will the IIS Web-based administration be used? If not, disable or remove it from the Web server configuration.
27	Are any IIS samples, or any other manufacturer sample code, present on the server? Remove them prior to launch.

The next section of the Solution Deployment Considerations Checklists reviews technical issues that apply to the overall solution and business issues that could affect the solution. Again, the team should consider the specifics of the solution before deciding if any single item applies to the situation.

General Technical and Business Considerations

Note: The following suggested checklist should be supplemented with checklists specific to the migration solution.

Table 6.6 General Technical and Business Considerations

Number	Considerations	Completed
1	Has the team removed "Guest" accounts from the system and checked to ensure that this does not affect the application?
2	Has the team double-checked the operations network infrastructure against the architecture?
3	Has the team confirmed that no network equipment is in test or debug mode (such as routers, switches, hubs, load balancers, and so on)?
4	Has the team properly configured caching engines with the proper information?
5	Has the team applied any required operating system service packs and documented the OS version and service pack level accordingly?
6	Has the team tested operations integration with third-party systems?
7	Has the team finalized training of the operations teams?
8	Has the team put in place change-control procedures for the operations environment?
9	Has the team finalized the operational processes and guidelines?
10	Has the team limited the access of anonymous users to appropriate content
11	Has the team developed, tested, and simulated disaster recovery procedures? Are the appropriate lead roles assigned to individuals or project positions?
12	Does the team have procedures for contacting key decision makers in the event of a major problem or security threat?
13	Has the team created a backup of the operations code, data, and content?
14	Has the team tested backup power systems and assured they are online and fully charged?
15	Has the team tested the operations server farms for response to the removal or addition of servers?
16	Has the team considered issues related to physical security?
17	Does the team have a plan for quick-fix engineering in the event of a problem during the launch period?

Core Solution

Most solutions include a number of components (for example, individual products and code components), as well as infrastructure (for example, servers and other resources), that provide the framework or backbone for the entire solution. These components do not represent the solution from the perspective of a specific set of users or site, but the deployment of the solution to sites or users generally depends on this core set of features or technology. Examples include the domain controllers, mail routers, remote access servers, and database servers that any site deployments depend upon for the full functionality of the solution.

Depending on the solution scenario, the core technology may need to be deployed before or in parallel with site deployments. Deploying components includes the following tasks:

Configure systems
Load and configure software
Prepare physical locations
Mobilize configured hardware

To avoid delays, core solution components may be reviewed and approved for deployment in advance of other parts of the solution still being stabilized. Operations staff must feel confident making this commitment before the whole solution has been proved to be stable.

Interim Milestone: Core Technology Deployed

After the deployment of the core technology, all components upon which the remainder of the solution (yet to be deployed) depends are in place, running properly, and stable enough to move forward with any dependent or site deployment components.

Site Deployment

At this point the solution has the key features and components in place to enable usage of the technology. There may be off-site deployments that still need to take place, but those components dependent upon the core solution are now working and in the process of final stabilization.

After any core solution components are deployed, any site-specific components are now enabled to complete the solution features and enable all targeted users to have access to the solution.

Customer and user feedback might reveal some problems. The training may not have gone well, or a part of the solution may have malfunctioned. Certain solution deployments may need to be revisited based on feedback from site satisfaction surveys.

To reach the Site Deployments Complete Milestone, the team makes a concentrated effort to finish deployment activities, stabilize and close out the project. This milestone is applicable only for projects that involve client-side deployments.

Interim Milestone: Site Deployments Complete

At the completion of this milestone, all targeted users have access to the solution. Each site owner has signed off that the solution is operating, though perhaps with some issues.

Stabilizing the Deployment

Stabilizing the solution is a joint venture between the project and the operations teams. Stabilizing usually begins in the later part of the Stabilizing Phase and continues throughout the Deploying Phase as each solution component is put in place.

It is important to include time in the master schedule for deployment stabilization because it gives both teams an opportunity to fine-tune the solution, resolve any issues that might arise, and monitor the solution to ensure it continues to work properly after going live. It also allows the project team to assist the operations team after the transfer of ownership.

It is to be expected that some issues will arise with the various site deployments. These issues should be continuously tracked and resolved.

At the Deployment Stabilized Interim Milestone, the customer and team agree that the entire solution is operating satisfactorily.

Disengagement Considerations

It can be difficult to determine when a deployment is complete and the team can disengage. Newly deployed solutions are often in a constant state of flux, with a continuous process of identifying and managing production support issues. The team can find it difficult to close out the project because of the ongoing issues that will surface after deployment. For this reason, the team needs to clearly define a completion milestone and criteria for the deployment rather than attempt to reach a point of absolute finality. Usually one or two members will remain on the project for a short period of time (agreed to by the two teams) to follow through on any problems or undocumented instructions.

If the customer expects members of the project team to be involved in ongoing maintenance and support, those resources should transition into a new role as part of the operations and support structure after project close-out. At this late stage, team members and external stakeholders will likely begin to transition out of the project.

Part of disengaging from the project includes transitioning operations and support functions to permanent staff. In many cases, the resources to manage the new systems will already exist. In other cases, it may be necessary to design new support systems. Given the scope of the latter case, it is considered as a separate project.

The Quiet Period

The period between the Deployment Stabilized Interim Milestone and Deployment Complete Milestone is sometimes referred to as a "quiet period." Although the team is no longer active, team resources will respond to issues that are escalated to them. Typical quiet periods are 15 to 30 days in length.

The purpose of the quiet period is to measure how well the solution is working in normal operation and to establish a baseline for understanding how much maintenance will be required to run the solution. Organizations using Microsoft Operations Framework (MOF) will measure the number of incidents and downtime and collect performance metrics of the solution. This data will help form the assumptions used by the operations Service Level Agreement (SLA) on expected yearly levels of service and performance. For more information on SLAs, see the MOF Operations Guide for Service Level Management that is available at https://www.microsoft.com/technet/itsolutions/cits/mo/mof/default.mspx. It is listed with other Service Management Functions under Microsoft Solutions for Management.

Transferring Ownership to Operations

The point in the Deploying Phase when ownership of the solution is transferred to operations may vary. In large enterprises, the point will occur well before the solution goes live because the operations and IT teams completely own and manage the production environment. However, a smaller company may see the development team owning the solution well after it goes live. Another possibility of differing transfer times is when solution hosting, such as in an Internet solution, has been outsourced to a hosting vendor, and the hosting company owns many of the operational issues.

Whatever situation occurs, there is a time when ownership moves to operations. At that agreed-upon time, the project team must complete its final tasks, gather all produced collateral, and transfer it and the technology to operations.

Transferring the Solution

Both teams will be very busy during this time. The project team will be closing any open issues and handing off maintenance activities to the operations team. The operations team will be initiating procedures and validating all collateral and equipment received from the project team.

Project Team Tasks

The project teams closing tasks might include:

Verifying that the operations team has the proper resources to maintain and manage the new solution. Some companies have an operations department ready to immediately take over. However, some companies may have to secure and train employees to manage their operations and support teams.
Confirming the final transfer of the knowledge base to the operations team.
Reviewing operations logbooks and ensuring that the procedures are being properly performed. The development team should clarify and correct any irregularities that were logged and ensure that these activities are being maintained and monitored on a daily basis.
Reviewing configuration management data for the deployed solution to ensure that any changes in deployed components are accurately reflected.
Confirming that all project sign-offs are correct. Once the signatures are secured, the transfer of ownership starts, and the operations team is solely responsible for the solution.

Operations Tasks

During the transition period, the operations team will work closely with the project team and complete the following activities:

Activate all reporting systems.
Validate and publish all collateral.
Validate and publish the knowledge and databases.
Review training materials provided by the project team.

After these activities are complete, the project team transfers the solution and documentation ownership to the operations team. However, a member of the development team will usually remain available for an agreed-upon time to assist the operations team in its early maintenance endeavors. The development team will sometimes remain on the support list and, should a crisis occur that requires additional support, the development team might be called upon to assist support (help desk), the operations team, and management personnel.

Interim Milestone: Deployment Stabilized

At this milestone, the solution is deployed and has reached a quiet period where the operation of the solution is under control, users have started to receive business value from the solution, and the project is transitioning to closure.

Project Review

The product manager and program manager take the lead in compiling the closeout report. The team and customer can use the closeout report as a quick reference to the work performed during the project and as a basis for future planning.

Signing Off on the Project

Once all the deploying tasks are complete, the team must formally agree that the project has reached the Deployment Complete Milestone and that the projects work is finished. By approving the milestone, team members signify that they are satisfied with the work performed in their areas of responsibility. As before, project teams usually mark the completion of a milestone with a formal sign-off. The sign-off document is a project deliverable.

Obtaining Customer Sign-off

Upon project closure, the product manager obtains the final sign-off from a representative of the customer, signaling approval of the solution and permission for the team to disengage from the project. Although, at this point, the team is busy informally closing outstanding tasks and wrapping up deployment, the sign-off should be a formal acknowledgement that the project is complete.

Producing the Closeout Report

The closeout report is the final physical deliverable of the deployment. It includes:

Final versions of all the major project deliverables (for example, vision/scope document).
User information summary.
Project review meeting summary.
Sign-off by the team.
Sign-off by the customer.
Summary of next known steps.

Conducting the Project Review

When the project is complete, the team should hold a review meeting to discuss the project and identify what went well, what did not go well, what to replicate in future projects, and what to change. Without assigning blame, team members conduct the project review with the goals of learning from mistakes and improving future projects. Often called a postmortem, or post project review, the review meeting sometimes takes place shortly before the end of the project rather than afterwards, because team members might be required to leave the project before it ends.

Closing the Deploying Phase

Closing the Deploying Phase requires completing a milestone approval process. The team needs to document the results of the different tasks it has performed in this phase so that the customer and other key stakeholders have sufficient information to sign-off on completion of the phase.

Key Deliverables from the Deploying Phase

A deliverables checklist for the Deploying Phase includes:

Final versions of all solution documents, code, and test cases
Training documentation
Service Level Agreements
Operation and Support Information
Customer/user satisfaction data
Project close-out report
Definition of next steps
Updated risk management
Milestone review report
- Team member project progress report
- Team lead project progress report

Key Milestone: Deployment Complete

The Deploying Phase culminates in the Deployment Complete Milestone. By this time, the deployed solution should provide the expected business value to the customer. The customer must agree that the team has met its objectives before it can declare the solution complete and close out the project. This requires a stable solution, as well as clearly stated success criteria. In order for the solution to be considered stable, appropriate operations and support systems must be in place.

Reaching this milestone means the project team has successfully transitioned the solution to operations. There may be ongoing work that certain members of the development or project team continue to be engaged in, but as a whole the team has officially made the transition to close the project.