Hi Guys-

Here is a discussion that transpired recently with some of us at Evergreen related to advanced practices in Release Management. Note–this is not complete or polished--just some interesting musings.

David: Client A and Client B use Change Management to plan for the production ready releases of (applications). All other release activities from conception, design, test, QA, etc… are handled by individual groups outside of a singular control process. Based on my experience with both clients this is the case because the Operations team owns the change process and the Development team doesn’t believe Operations should be involved with the management of applications, other than installing, modifying, or removing production ready apps.

Don: David - a good discussion! I believe the approach you described is very common industry wide, and is not necessarily inappropriate. Most development teams have processes and software (Serena, Merant, Mercury, etc) supporting the development of an application or app modification.

Per ITIL, Release Management coordinates the many service providers and suppliers involved with a significant release of hardware, software, and associated documentation across a distributed environment.

Some thoughts from a business practical view - not an exhaustive list.

Some Good Release Management Practices

Have a defined set of change execution models for the 4-5 common types of releases - agreed upon with development (improves their alignment activities).

Set clear expectations with development on timing, lead times, risk, end user training, and infrastructure readiness state, ensuring smooth, planned launches.

Have agreed upon (and followed) development best practices - with the correct amount of emphasis on testing for quality, end user testing, and end user training.

Some Great Release Management Practices (add these)

Use one enterprise change management process for change planning and approval, which begins at the front end of the demand funnel - so all of IT works with one change planning system - Plan, Approve, Build, and Implement. This allows apps and infrastructure to weigh in on risk, impact, and cost?thereby getting a true picture of the value of a proposed activity. This can be the portfolio management tool or the IT change management tool, it doesn’t matter - but use one for IT.

This also allows infrastructure to understand the demand load they are facing in time to affect their strategic planning. So better decisions / tradeoffs can be made on infrastructure investments with longer range planning horizons.

Gear development lifecycle effort by type, according to the risk and materiality. Low risk, low impact projects can follow a lighter development set of activities end to end, using production as more of a litmus test.

Release Management is a really good 2 way bridge (just happens to be ITIL codified) between apps and infrastructure to begin working more as one IT organization.

Don’t forget to register for Evergreen’s change management webinar and learn how to Take Change Management from Firefighting to Fire Prevention

Also, check out our new White Paper on “Developing the Business Case for ITIL”.

—–