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”.
—–