Release Milestone and Its Deliverables

Achieving the Release Milestone is the final goal for the project team. It marks the point where the team has finished all work on the product, so the product, product elements, and product artifacts are ready to be shipped. This is also the transition point at which the team relinquishes ownership of the application and the operations and support organization takes over for deployment, maintenance, and ongoing product support. At the project level, the Release Milestone signifies that the team has accomplished the project-level vision for the product. Don't forget, this milestone is also a time for celebration—the goal has been reached.

When the Stabilizing Phase is complete, the project team reaches the Release milestone. The deliverables of this milestone provide valuable information for the deployment and use of the application in the production environment.

The six deliverables required to meet the Release Milestone are:

• Final product release The source code and executables, as described above.
• Product release notes The documents containing release information and late changes.
• User and support performance artifacts The final release of supporting information.
• Testing results The bug status and database for future projects.
• Project archives All relevant product information created during the development process, whether or not it shipped with the product.
• Project documents All stages of the product documentation including the major milestone releases.

Release Notes

Every product seems to have a set of last-minute changes or issues that the customer, user, and their support teams should be aware of. Creating a simple document that outlines these issues and acts to communicate important application or compatibility issues can help to alleviate problems that may be encountered by the product deployment team.

User and Support Performance Artifacts

The user performance artifacts can take many forms such as Help files, wizards, how-to guides, and training materials. The primary focus of these user performance artifacts is twofold: to prepare the user community for the product release, and to assist the user community after the product release. Creating and releasing a product that the user does not know how to use, does not know how to learn to use, and does not know who to learn from can turn even the most successful project into a disaster. The following sections discuss some of the primary responsibilities of the User Education team:

Application Documentation

The key to a well-accepted deployment lies in the documentation an organization provides for its users. The project team might want to announce in advance that the application is nearing completion and to give those curious users a location where they might find some preliminary material to read. It's crucial that documentation is in place and ready to be accessed when this location is announced. The documentation may be in paper form, or it may be posted on a Web site for easy accessibility.

It's a good idea to precede the full documentation with a page highlighting the application's main capabilities. When the project team is about a quarter of the way through deployment, it might want to post a Frequently Asked Questions (FAQ) document to the Web site. The FAQ should be updated on a regular basis. When compiling the FAQ, the team might want to ask users to submit samples of documents they intend to use with the application and then gear the FAQ to those samples. This involvement gives users a feeling of participation in the process.

Training and Training Documentation

As part of the stabilizing process, the project team can implement a training plan with documentation. This training may be self-paced training, formal classroom training, or informal one-on-one training, depending on the size of the deployment and the complexity of the application. Whether the initial training is formal or informal, additional training should follow after the user community has used the application.

Support Documentation

System documentation can have multiple parts, depending on the application. Server-based documentation may be required if the application consists of a database engine and data. This documentation can be broken down into specific documents containing the changes and updates to the installation, system configurations, and ongoing configuration. For example, a document describing the disaster recovery process for the database should be created. (Disaster recovery might consist of an automatic process that stops the database engine during low access periods and copies the data to a backup location.) It is also appropriate to document the usage of an enterprise utility to back up the database. Waiting until a failure to verify a backup and restoration plan is highly inadvisable.

Depending on the architecture of the application, tuning opportunities may arise on multi-tier systems as the application enters the production environment. These tuning parameters should be tested during the interim releases, and the tuning suggestions and methodology should be incorporated in the system documentation. The team should provide a matrix or table format in the documentation to summarize these tuning parameters.

Client documentation should also be created that contains the specifics of how the application installation on the client is performed and the default settings made during the installation. This support document should be created during the Developing Phase and finalized during the Stabilizing Phase. Any modifications to the default installation should be noted in this documentation. Additionally, for a multi-layer application, it may be advantageous to create a high-level document describing how the three layers interact.

Testing Results

The application's testing results should be collected and stored in a permanent archive. These results may be used to determine new features for new product versions, as well as to lend help to the support and maintenance teams.

Project Archives

The project's artifacts as well as the final deliverables for each product milestone should be permanently archived. These artifacts may be used to set guidelines for future projects and also to provide a historical record of this application's development process.