co-dependent pieces to be developed together, tested, and operate effectively prior to the release date. The key is to identify all items that need to be coordinated, managed, scheduled, and planned. These may include (but are not limited to):
· Ensuring requirements that impact other projects (internal and external) are submitted to the other product release’s requirements list(s)
· Ensuring requirements from other products (internal and external) that impact this one are included in this product release’s requirements list
· Tracking changes to requirements and communicate impacts to externally dependent product releases
· Ensuring the tasks associated with parallel and external deliverables are included in the project plan (build time, run time, merging, etc.)
· Ensuring items released in a parallel branch are merged and tested into this release as appropriate
· Ensuring training and/or guides are developed for the external functionality that works with this release
· Managing the deployment of the deliverables to the test environment and ensuring that the external dependent items are also available at test runtime
· Managing the deployment of deliverables into production (e.g., ensuring all internal and external pieces are collected for distribution and the distribution occurs to the correct group of potential users and targeted locations)
· Validating the release notes
· Validating the release is operating as expected
The Planning of Future Releases
The third consideration for release management is establishing a long-term planning aspect to recognize future product dependencies. This includes a combination of understanding the product road map (which should be created by the product manager) and understanding the product road maps of the externally dependent products that your product must work with to make the release a success. There are numerous reasons for this because any change in a dependent product infrastructure or architecture may have a significant impact on the product.
As a product develops through its lifecycle, there may be many levels of dependencies which must be managed to ensure the co-dependent products are being developed with the product in mind and that the development of this product considers the other products. Some of the product level dependencies that may be considered (but not limited to) are the:
· Architecture: Is the product evolving with the same type of architecture as other co-dependent products? Communication and collaboration between release managers or product managers of dependent products is recommended to ensure architectures are compatible. If an architecture or technology of a co-dependent product changes, this may have serious ramifications to the functionality of the product.
· Deployment: If the installation process changes for a co-dependent product, then the product may be looking for runtime items in the incorrect location.
1. Development: If the development platforms change and there are build-time dependencies, this will cause issues.
2. Test and production: If a co-dependent product ends its support on your client platform, then issues will arise.
A discussion on release management would not be complete without a review of the roles. With that in mind, it is important to distinguish the role of the release manager from the roles of project manager, development manager, and product manager. It should be clear that many of the tasks associated with these roles may overlap. For example, on a small project a project manager may play the role of a development manager. On larger projects, a project manager may share development tasks with a development manager. Another example might be that while a product manager needs to ensure the project manager has