At the beginning of a project we often stub out interfaces to shared services – such as security, persistence, or even reusable legacy functionality – so technically still have some clean up to do before it ready to release to production.

The first production release often takes longer to deliver than subsequent releases; in the first release of a system likely need to get a lot of the “plumbing” . The first production release may take twelve months to deliver, the second release nine months, and then other releases are delivered every six months. An early focus on deployment issues not only enables to avoid problems it also allows to take advantage of experiences during development.

Take an agile approach to planning: Keep the plans high-level at first, focusing on the major dependencies. The people doing the work should plan the details, don't need to worry about the details until its about to start the work.

Reduce the pre-production testing efforts safely over time: It’s of little value to deliver working software on a weekly basis if there is a three-month pre-production testing process which it must go through each time. Agility can reduce the amount of time invested in pre-production testing efforts, and thereby speed up deployment. Why is this? Agilists produce high quality artifacts and have the regression test suite to prove that their system actually works. This higher level of quality implies that, to do less testing during system deployment.

Update the deployment plan regularly:This helps to set realistic expectations by both project team and deployment audience.

Have go/no-go decision points during the installation process: A good deployment plan includes go/no-go decisions points during the installation process. If at defined times during the installation have not reached a certain point in the overall installation process , will rollback the efforts and try to install again at a future date. This is a critical concept for projects that have very stringent deployment requirements, typically software that is replacing existing mission-critical systems that currently run the business.

Develop "de-installation" scripts: The ability to back out becomes critical with this approach, requiring investment of additional resources to develop and test de-installation scripts. In fact, many deployment efforts fail miserably because the development team didn’t bother to consider how to back out their new system, and then discovered that they had to do so because of an unforeseen problem during installation.

Remember the data: Data conversion is often a key task for the deployment of a new software system, a complex effort that should be started early in the project.

Announce the deployment: Announce the anticipated deployment schedule, including both the expected training and installation dates.

Hold regular release meetings:The closer we get to deployment, the greater the need to hold regular release meetings with key players involved in the actual deployment. This includes quality assurance staff to advise everyone of the testing status of the software, developers to advise the current rework status, operations staff to inform current production issues of the existing environment, and support and user management to inform their training statuses.

Training is an important part of deployment: Remember that the stakeholders may need training beyond that of learning how to work with the application.

Develop supporting documentation: Another important effort is the development of operations, support, and user documentation

Release Planning "Don't Forgets"

Successful releases, particularly for complex projects, are planned almost from the very beginning of a project. The following are issues need  to consider long before you get to the release iteration:

Involve operations and support (O&S) departments early in the project. O&S people are critical stakeholders, so need to understand their requirements and how to work with them effectively.

Identify the legal and/or regulatory compliancy issues. Food and Drug Administration (FDA) guidelines or the Sarbanes-Oxley (SOX) act may be applicable to the system, increasing the required levels of documentation and internal auditing.

Identify potential release windows. Operations department may have strict rules as to when a system may or may not be released, and  need to compete for a slot within their overall release schedule .

Identify anyone who must sign off that the system is ready for deployment. This includes end-user management, internal audit groups, and O&S management