CDC Home

Project Management Newsletter

Release Strategy

Newsletter Archive
Click Here to Subscribe

Volume 6 | Issue 3 | March 2012

Daniel Vitek, MBA, PMP

System development decisions often have deep strategic, business, and cost implications. If not planned correctly ramifications of incorrect decisions may be felt long after the decisions have been made. On the periphery of system development one very important aspect addressing this issue may often be under emphasized or overlooked all together. This is the implementation, execution, and management of an effective software release strategy. This becomes exponentially important when building a custom application because of the many challenges facing development teams:

  • Managing development activities
  • Managing integration of new development into the existing application
  • Managing application dependencies
  • Managing new feature/function requests
  • Managing compliance with departmental/federal regulations, mandates, and processes
  • Managing security requirements (vulnerability assessment testing [VA])

To illustrate how complex a development environment can be, and how important an effective release strategy is, consider the following example. A development team is building a custom application and might be required to release a major new feature or function multiple times a year to meet the demand of its clients. This environment is further complicated by the management of defects, issues, risks, change requests, etc. resulting in the distribution of multiple minor patch or emergency releases. The team uses an iterative approach to development and performs a test build at least once a day. Additionally, the application may have dependencies and interdependencies on other applications. Managing software in this type of environment is often done using a source control management software application (Microsoft’s Visual Source Safe [Visual Studio], IBM’s Rational Clear Case, Borland’s StarTeam, CVS, etc).

Deciding to release an application is often a tradeoff between early release and deferred release. Each alternative has its own sets of pros and cons that must be weighed against each other to determine maximum value for stakeholders. For example, rushing delivery benefits stakeholders with earlier release. However, it may reduce functionality and may decrease overall quality. As a result, future costs may rise in order to fix bugs and distribute patches. Deferring a release allows time for enhanced functionality and improved quality. However, this may incur additional development cost and may result in missed opportunities.

Release Strategy

It is sometimes difficult to accurately determine the most appropriate product release date, feature functionality, associated development costs, quality concerns, etc are all challenges needing to be considered. Proper development and implementation of a release strategy makes building and distributing software easier and more consistent for the performing organization and also outlines how and when product will be made available to the client. A release strategy includes information such as:

  • Producing the product
    • Development approach (Iterative, waterfall, etc)
    • Functionality defined for each planned release
    • Operating systems and Program languages used
  • Product testing
    • Quality requirements, measures, acceptable tolerances, and testing approach
  • Product documentation
    • Guides, release notes, and training material
  • Packaging and distribution
    • Physical or electronic distribution
  • Migrating data
  • Hosting the software
    • Requirements for internally facing systems regarding hardware, software, security, etc.
    • Requirements for externally facing systems regarding hardware, software, security, etc.
  • Providing training to end-users

Release Management

Release management approaches may vary from organization to organization. However, regardless of which approach is used a best practice approach to release management is comprised of activities that effectively manage the planning, organization, development, testing, and implementation of new features and functions, defects, change requests, market demands, client expectations, etc into the application being developed. Some of the stages that a software release may go through as it works through the release process may include:

  • Pre-Alpha - A pre-alpha release does not necessarily contain completed feature/function. This is often an interim product build, prior to testing, often to validate a particular piece of work or that development to this point hasn’t broken the build process.
  • Alpha - An alpha release does not necessarily contain all completed features/functions but does satisfy release requirements. An alpha release is often the first internal product build delivered to the testing group. It is often a preliminary build that is only partially complete and typically contains temporary code, comments, product breaks, etc.
  • Beta - A beta release is the first product version released outside the performing organization for the purposes of real-world testing. A beta release includes all features/functions but often still contains known issues and bugs.
  • Release Candidate - A release candidate contains all completed features/functions and is a product version that has the potential to be a final product. A release is called code complete when it is agreed that no additional “new” source code will be added to the release. However, there may still be changes to fix defects.
  • General Availability (Gold) - A general availability release is the final version of a particular product. A gold release is stable and relatively bug-free with a quality exceeding the client’s expectations.

For more information and tools related to the topic(s) covered in this newsletter, the CDC Unified Process, or the Project Management Community of Practice please visit the CDC Unified Process website at

Please also visit the CDC Unified Process Newsletter Archive located at for access to many additional newsletters, articles, and management related topics and information.


The CDC UP offers a short overview presentation to any CDC FTE or Non-FTE group. Presentations are often performed at your location, on a day of the week convenient for your group, and typically take place over lunch structured as one hour lunch-and-learn style meeting.

Contact the CDC Unified Process at or visit to arrange a short overview presentation for your group.


The CDC Unified Process Project Management Newsletter is authored by Daniel Vitek, MBA, PMP and published by the Office of Surveillance, Epidemiology, and Laboratory Services.

For questions about the CDC Unified Process, comments regarding this newsletter, suggestions for future newsletter topics, or to subscribe to the CDC Unified Process Project Management Newsletter please contact the CDC Unified Process or visit



  • January 27, 2012
    Topic: Leadership
  • March 01, 2012
    Topic: 2012 Project Management Summit
  • March 23, 2012
    Topic: Understanding Records Management
  • April 27, 2012
    Topic: Contracting
  • May 18, 2012
    Topic: Cloud Computing at CDC
  • June 22, 2012
    Topic: Project Change Management
  • July 27, 2012
    Topic: PM Best Practices - A Panel Discussion
  • August 24, 2012
    Topic: Enterprise Performance Life Cycle
  • September 28, 2012
    Topic: A conversation with CDC Policy Leadership
  • October 26, 2012
    Topic: The Value of Alternative Analysis
  • December 07, 2012
    Topic: Managing Risk


Add This Socialize the CDC Unified Process: The U.S. Government's Official Web PortalDepartment of Health and Human Services
Centers for Disease Control and Prevention   1600 Clifton Rd. Atlanta, GA 30333, USA
800-CDC-INFO (800-232-4636) TTY: (888) 232-6348, 24 Hours/Every Day -

A-Z Index

  1. A
  2. B
  3. C
  4. D
  5. E
  6. F
  7. G
  8. H
  9. I
  10. J
  11. K
  12. L
  13. M
  14. N
  15. O
  16. P
  17. Q
  18. R
  19. S
  20. T
  21. U
  22. V
  23. W
  24. X
  25. Y
  26. Z
  27. #