CM: THE NEXT GENERATION of Release Management

  Develop the same progress curve for field trials as you did for verification.   Build confidence that you're ready to release.

What Are We Delivering - Traceability

Now that you're ready to release, you need to tell the industry what features you're releasing with this release.   If your ALM tools are adequate, this should be a push-button task, at least down to the details - the formatting may require a technical writer or graphics designer.   But having an accurate list of what has gone into the release comes from knowing what build you're releasing, how was that build built and from what source, by tracing your build back to the changes that were made (and peer reviewed to ensure that the changes covered exactly what they said they would - physical audits), by tracing the changes back to the specifications and by verifying that your product conforms to these specs (functional audit - basically, for software, a verification run record).

Some ALM tools span several databases and building the complete picture may be non-trivial and even error prone.   That's not good.   Often this results from gluing things together yourselves, but without the experience that shows you where the glue doesn't really hold up.   This is where you really find out if your processes are bullet proof and simple enough to completely and correctly capture the data.  
If not, you'll find out from one or more of your customers.

Then your tools need to support you in packaging your release.   Whether it's done over the internet, directly to your in-house customer base, placed on a DVD, whatever.   Your tools need to ensure that what you intend to deliver gets properly packaged, and delivered.

What Does the Customer Have

It's one thing to tell the customer what's in a release.   It's another thing to tell the customer what changes they will see.   Perhaps they're using an older release or a
specific service pack level. Maybe you've done custom builds for the customer
to get them the features early or to fix a pile of urgent problems.

Every build that goes out the door needs to be tracked in your ALM tool.  
Furthermore, you need to know which build (or builds) every customer is using.   It may be fine to have some basic rules, but then you have to at least track both the rules and the exceptions.   When you deliver to your customer you need to say:

• This is what you currently have

• This is what we're delivering to
  you

• Here are the requests you've
  asked for, by problem and by feature request

• Here's the requests we're
  satisfying

• Here's the requests we're not
  satisfying and their current disposition

• Here's how to upgrade from where
  you are to the new release (ideally this is fully automated, but that's not always realistic).

• Here's the incremental training
  that will most benefit your users

You'll gain customer  confidence.  That will give you reference  customers and that will increase your sales.   Make sure you can go to your customer site and identify exactly what  they have installed.   Maybe one release,  maybe several.   Maybe old releases, maybe  new releases. What variants, etc.   Don't trust that what you sent them is what they're using.   Your product should be able to report it's  exact contents, preferably in terms of one or more build identifiers that you  inserted into the deliverables, which you can use to trace exactly which lines  of code they have.

Don't fall into the trap of thinking release management comes at the end of development.   It starts before development does and it persists after delivery.   Think about it up front and you'll design your development processes appropriately.