Release Management Strategy

Release Management Strategy Before — Each business stakeholder will come to the table with their unique needs developing a “Release Management Strategy”

Over the last several years I have had the opportunity to work on various global IT projects. One subject that comes into play and is critical to success is an effective release management strategy. I have witnessed release management strategies which work well and at times not so well. Most if not all of the issues were based on some basic ground rules that should be in place and followed prior to laying out your fiscal IT release calender. Here are my general guidelines to consider when putting together a solid release/change management structure for a global IT application.

Get all the key stakeholders at the table – You can’t simply put out a release calender in a ‘vacuum’ so to speak. This will include the business (all segments and regions), IT, testing, interlocks (systems impacted by your changes) and occasionally as required, you may need legal. All impacted parties should have a seat a the table and know what the plan is for change management in your IT system. This will be crucial in starting your release management strategy.
Know your company’s moratorium calender – Most companies (for or non-profit) have an IT release calender in which new changes can be introduced into critical systems. This is not unusual as you don’t want to deploy big changes the week of a major sales holiday or end of a sales quarter. Know this and consider as a key factor when coming together with a plan. Make sure you are not releasing new functionality during an IT corporate moratorium. Your actual release calender should start with all these ‘moratorium’ dates plugged in.
Agile, Waterfall or both? – A common question asked is “how will you deploy the changes”. Most cloud applications / tools allow for quick config changes work well with Agile, however integration with legacy systems may dictate Waterfall release management or both. My suggestion is if you can, use Agile, you get benefits quicker to the business and you can course correct your project more effectively. Later in another blog, I will discuss how to best empower the business to do some of the actual change management themselves.
Funding – This is key, you can not build out a massive release schedule with a lot of work to be deployed only to realize you actually don’t have any or simply not enough funding. With larger IT practice’s you can estimate budget based on last year’s budget and start from there (given some room for flexibility), but know you are funded in some capacity.

The above four areas certainly are not all inclusive, but they should dominate your discussions as you come together to put out a release management strategy for your team/company. In the end each company is different, but the above are some core considerations to look at as you prepare for you release schedule. My last bit of advice from my years of working on areas like this is to PLAN AHEAD. Time is your biggest asset when plan ahead for a robust release management strategy. If you wait until the last minute, you will be ‘spinning your wheels’ trying to come up with a plan, while the actual fiscal year has started and money is possibly left on the table.