Establishing an agile release process when implementing new functionality during a ERP-system implementation

During a global ERP roll out our clients faced a challenge, to cover future releases of new functionality after going live by implementing an agile release process. This initiative was driven by the release manager in the project and supported by the technical lead and project manager assistant who designed and produced the process maps.

In order to set up a release process, we initially had to realize 2 things.
1. Who to involve and who’s input was needed, in order to set the best way of working. We came to the conclusion that we had to involve the cut-over/release manager, environment manager, solution architect, test manager, process owners and also consultants from the system supplier in order to cover all stakeholders.
2. There where a need to specify a major (new functionality) and minor (bugs, smaller fixes, reports) release. We decided to consolitade the two of them in order to make one generic process map which covered both perspectives

Another important input we had to this initative, was that release management had previously been set up in our Azure Devops tool but the E2E process needed to be clarified. So the initiative was more or less based on the already existing way of working. The process map was supposed to make sure that when a release item in Azure Devops was to be handed over from person A to person B, it shouln’t be any discrepencies regarding e.g. the ownership, next action to perfom and any decisions that had to be made.

The release manager was the workshop facilitator and also in charge of making sure that all stakeholders perspective was covered in the process map which emerged live during the workshops

Another challenge we realized when we tried involving all stakeholders was trying to anchor how important this process was even though the release of new functionality was not in near sight in the project since we had not yet reached go-live. Their availabilitiy to contribute was therefore lacking due to prioritisation of other more crucial topics.

During a 3-serie workshops with the stakeholders presenting their perspective of how it should work. With a few iterations, we managed to generated a process in order to support the need of releasing new functionality directly after the Pilot go live of the ERP-system. But already then, we knew that the process map and supporting activities would change. Release management is still in development in order to match today’s need of the global ERP-system and all new functionality which is still to be rolled out. Below you can find the first version of the release process.

A challenge we faced when initially started mapping the process was how to cover the environment perspectives during the release process. We used Microsoft Visio to map the process which had its limits in visualizing all these different parameters. Since the swimlanes were occupied with the identified stakeholders we had to break down the process into three vertical stages which correlated with the environment that we used for releasing new functionality. These stages were also color-coded to easily be able to distinguish between them.
Stage 1: Test environment
Stage 2: Pre-production environment
Stage 3: Production environment