The Next Generation of Release Management is for Everyone

strategy education exercise).  When I do a workspace comparison, the context is implicit.  Anyway, you get the picture. I hope.

With respect to the second function, user interfaces must be defined to allow traceability information to be captured.  So, for example, I don't add a new file. Instead, I add a new file to a directory (i.e. by right-clicking or otherwise selecting the directory object).  I don't link files back to a problem report at check-in time.  Instead, I start a change/update from my problem to do list by clicking on the problem I'm going to fix in order to fix the problem, and then I check out files against the change/update.  I don't create a test case and then associate it with a requirement.  Instead I right-click on a requirement and select "Add Test Case" or something similar.  

When the user interface is arranged in this object-oriented fashion, it allows the tools to automatically identify the traceability.  And of course this is all easiest when a single integrated ALM tool, on a single repository, is used.

If these two critical functions are not provided by your tool(s), you will likely be missing data, have erroneous data, or be missing crucial traceability information.  Ultimately, all of this information is needed at release time.

Querying Release Information
Release management with appropriate tools and data capture will allow easy identification of the following information (not exhaustive by any means).

1. What problems were addressed by the release?
2. What new features are there in this release as compared to the current customer's deployment?
3. Which pre-existing features are currently not working?
4. What are the outstanding problems?
5. How does the new release quality compare to the previous release?
6. Is problem X fixed in this release?
7. What problems must be addressed before then release goes out the door?

The list goes on and on, as I'm sure you know.  But if this information, though present, is not readily available, then the value of the information is reduced.   Information that takes 3 days to compile, cannot be used in the same way as that which takes only 30 seconds.  You can't explore within the context of a meeting if every question you have is going to take days to answer.  You can't answer customer queries in a timely fashion if you can't get at the information quickly.

So it is not sufficient for a solution to have the information that can be mined.  It has to be readily presented in its various forms (graphical, detailed, metrics, etc.).  It must also be possible to identify and navigate traceability links in an intuitive fashion.

Release Management for Everyone
The above questions may be important to the release team, but they are also important to the development and support teams, as are dozens of other queries.  And not just at the release level, but for any build that is produced from the CM repository.

A developer finds a problem that wasn't there a week ago.  He needs to identify the changes that have gone into the code since then.   The quality team wants to know why the problem wasn't detected earlier - is there a missing test case or was testing not completed?  Similarly if a developer finds a line of code that she doesn't understand, she needs to trace it to the reasons that it was introduced.

These examples require the same product information that the release management functions require.  Instead of comparing releases, developers are usually comparing builds.  Instead of identifying the full set of features, they want to know if