You’ll face numerous challenges when you manage by release. I have learned over time that if you “get it right” with three key design areas, the rest will fall into place and reduce risk.
In fact, instead of calling them challenges, let’s call each of them a success factor.
First success factor
Clearly define an acceptable “business as usual” or BAU change, compared to a “Release change”. Defining those two categories is crucial.
If you leave gray areas, users will push requested changes (“we need a new line in the user form ASAP!”) into the BAU list for quick action.
The BAU list will quickly bloat while the Release list shrinks and you’ll find you’ve undermined your own Release strategy.
Second success factor
Get the process right. A solid process with formalized steps to plan, schedule, control and approve releases ensures they will be in tune with business requirements.
Enforcing the process prevents changes being inserted or taken out of a release after its deadline. Maybe you organize releases around an application, or a date, or some other criterion.
To accelerate delivery, use your process to limit the number of components, so your testing doesn’t have to go so broad and deep. Your changes will move into production faster.
Third and final success factor
Manage your parallel changes closely. That relates to both change definition and process. Simultaneous changes within BAU and the release can result in overwriting BAU change when the release moves into production.
Such errors can be very difficult to track down and can reflect badly on the quality of the release or even the strategy itself. Good process control and enforcement can prevent such problems.
Once you set up and debug decision criteria, establish process enforcement, and control parallel changes, you’ll face many other decisions – but you’ll have a solid basis for them.
For example, should you deploy an N+1 development landscape? You can settle these sorts of issues by answering key questions such as:
- How many changes will each release contain (size of release)?
- What types of change will be included per release (impact of release)?
- How often releases are to be applied to production (release frequency)?
- How much and what types of change will make up the steady volume of BAU change?
This chart may help you decide on delivery methods.
| Considerations | DEV – QAS – PRD (N) | DV1 – QA1 (N+1) |
| Size of Releases | Low – Medium | Medium – High |
| Impact of Releases | Low – Medium | Medium – High |
| Frequency of Releases | Quarterly – Bi Annual | Fortnightly – Quarterly |
| Steady state BAU volume | Low – Medium | Medium – High |
As one example, if you put small-to-medium changes into your BAU stream and save the quarterly release for major enhancements, you might forego N+1 development processes and manage releases through your standard process instead.
Which approach works best for you is your decision. Just ensure each “must get right” success factor supports your decision.
To learn more about how Rev-Trac can help you to better manage releases and get each success factor right, please feel free to reach out to our SAP change management experts.
