Skip to Content

Release Management in SAP –A structured Approach –Part4

In the context of previous three blogs http://weblogs.sdn.sap.com/cs/junior/view/wlg/22804-Release Management in SAP –A structured Approach -Part1
http://weblogs.sdn.sap.com/cs/junior/view/wlg/22805-Release Management in SAP –A structured Approach -Part2
http://weblogs.sdn.sap.com/cs/junior/view/wlg/22814-Release Management in SAP –A structured Approach -Part3,this is a conclusive blog focussed on Governance,Roles and Responsibility as well Communication

Governance

The following are the Release Management governance principles.

  •  Release Scope will be confirmed and frozen at the start of each Release cycle.
  •  All key stakeholders involved in a Release will be communicated the detailed Release Plan, appropriate checkpoints, and sign-off points at the beginning of a Release lifecycle. (Timing of Release phases may vary depending on the contents of the Release.) 
  •  All Release approvers are required to provide signoff within the appropriate timescales. Failure to so do will move the relevant object to the next available scheduled Release.
  •  Failure to pass a checkpoint in the Release Lifecycle will automatically move the relevant object to a future Release.
  • Where appropriate, business sign-off of EUT will be required prior to the migration into Pre-production.
  • Where appropriate, business sign-off of Regression testing will be required before the migration to Production.
  • The Release Manager will be responsible to approve the movement of transports into Pre-Production and Production for all Releases – Major, Minor, and Emergency.
  • The Release Manager will have the final approval prior to any migration to Production.

The following chart provides an overview of the different release management governance forums.

Governance Group

Purpose

Who

Frequency

Change Approval Board

To approve change requests into a Release.

As defined

Release Manager

As defined

Architecture Board Meeting

To confirm:

  • Monthly maintenance windows and any expected impact on Project.
  • Review of any other upcoming activities which may impact Global Template.

Release Manager

AMS SDM

Lead Architect

Weekly initially moving to Monthly

Release Planning

To confirm the scope of each Release before it is initiated and to conduct Release forward planning.

Release Manager

AMS SDM

Project SDM

Manager Operations

Monthly

Release Status Meeting

To manage the Release through the various phases, checkpoints, environments, and to confirm that all required sign offs are in place.

Release Manager

AMS SDM

Project SDM

Others stakeholders as required (e.g. 3rd parties, Operations, Process Owners, etc.)

Weekly

Governance Meeting

To communicate

  • The upcoming release schedule
  • The planned content of the releases
  • Country required actions (e.g. regression sign off)
  •  To allow countries to communicate any local plans which could impact the releases.

Release Manager

Super Users

Super Users

Global Template Super Users

Global Operations Reps / Process Owners

Monthly

Approvals

Below is a high level overview of the approval inputs into the Release Process.

Approver

Area

Responsibility

Change Approval Board (CAB)

Country Go-lives,

Major new functionality,

System enhancements,

Support Packs

Responsible to approve and priorities across Releases.

AMS

Incidents

Responsible to priorities incidents into Releases.

Release Manager

Release Scope

Responsible to finalize the combined Release list. Where conflicts arise, the Release manager is responsible to escalate to the CAB for resolution.

 Once a Release is frozen and in progress, the Release Manager will be responsible to ensure that the checkpoint criteria is met prior to releasing transports for Minor and Emergency Releases into the next environment. For Major Releases, the current project managers will be responsible for approving the release into the next environment, up to Pre-Production. The Release Manager will be responsible to approve the movement of transports into Pre-Production and Production for all Releases – Major, Minor, and Emergency.

Major and Minor Releases must pass the Release checkpoint criteria before they will be accepted for migration into the pre-production and production environments.

 The Pre-Production environment is owned by AMS and will be used for regression testing.  The pre-production environment will be refreshed from the Production environment prior to every full regression run.

Pre-Production Environment Checkpoint Entry Criteria include the following points:

  • Functional specs complete and signed off
  • Build and Unit Test complete
  • Technical specs complete and signed off
  • String test complete and signed off
  • EUT complete and signed off by the business
  • KT to AMS complete

Production Environment Checkpoint Entry Criteria include the following points:

  • Regression Test complete and signed off
  • Operational Readiness complete
  • Go/No Checklist complete

Release Management Roles (Critical)

Release Manager

The role of the Release Manager is critical to the planning and execution of the Release Management processes and governance. The purpose of the Release Manager will be to plan, manager, and co-ordinate all changes to the production environment by Releases.

 The Release Manager will be responsible for the successful completion of all of the release management related activities. This includes the planning, preparation, implementation, and post implementation support.  They will not be responsible for implementing the developments and changes themselves, but they must ensure that each activity is completed to plan.  Therefore the Release Manager will rely on a number of individuals to execute the details and report back the status.

 The Release Manager responsibilities include the following:

  • To act as the ‘Gatekeeper’ to the Production environment.  Nothing should pass into production without the Release Manager final approval.
  • Liaison with Change Approval Board to provide input into the decision making process, input into prioritization across countries, impact assessments, release process capacity information, etc.
  • Liaison with direct and indirect stakeholders.
  •  Freeze release scope (enhancements from Change Approval Board and incidents from AMS)
  • Define, maintain and communicate the detailed plan for each release.
  •  Co-ordinate integration where necessary.
  • Owner of Release Management checkpoint signoffs.
  • Approve the release into pre-production and production environments. Communication final release contents to appropriate parties and post to agreed central location

Service Delivery Manager

The AMS Service Delivery Manager (SMD) is a critical stakeholder in the release process as this role will manage and provide status updates on a significant portion of the release process. The AMS SDM will be responsible for the following areas as part of the release management process.

  • Input of incidents and prioritization of incidents into Release Schedule and detailed planning
  • Input of enhancement estimates into Change Management Process
  • Management of development of enhancements via AMS
  • Management of resolution of incidents
  • Regression execution and sign off

Operations Release Manager

The purpose of this role would be to ensure that all relevant operational readiness activities associated with a particular release were complete within the appropriate timescales. The Operations Release Manager would be responsible to provide regular status updates into the release management lifecycle and to provide the Operations go/no go for each release.The Operations Release Manager would be responsible to liaise with all relevant parties to ensure that the following activities with regards to each release were complete within the appropriate timescales.

  • Functional requirements confirmed and signed off
  • Processes updates
  • EUT complete and signed off
  • Procedures and Work Instructions updated
  • Communications and Change Management activities complete

Stakeholder

Relationship with Release Manager

Change Approval Board

To provide the approved, planned enhancements, country go-lives, and major functionality into the release schedule
Release Manager to provide input into decision making and prioritization process including estimates, capacity, cross-country considerations, etc.

Project Operations

To work with Release Manager through the release lifecycle providing updates and the relevant checkpoints.

To be responsible for managing the contents of the Major Releases through the lifecycle and ensuring that the checkpoint criteria is met prior to the handover into the regression environment.

3rd Parties

To provide input in the Release schedules and considerations and constraints into the Release Plan.

To work within the Release timeframes and provide updates and issues to the release manager.

AMS Service Delivery Manager (SDM)

To provide input into the Release scope (e.g.  incidents)

To develop the incident fixes and minor enhancements.

To work with the Release Manager to manage the Releases through the release lifecycle

To provide updates into the weekly Release Status Meeting.

Operations Release Manager / Process Owners

To ensure that all appropriate training, portal content, process updates, work instruction updates, etc. are complete within the communicated Release timescales.

To provide status updates into the weekly Release Status meetings.

Communications

Communication of release contents to the team, wider stakeholders, and the business end users will be essential.  The contents of a release may differ from the point at which the release scope is frozen to the point at which the release is transported into production.  Therefore the final communication of the contents of the release will be critical to business operations. 

Principles

The following general Release communication principles will apply.

  • The Release Schedule will be published to the business in order that the business many plan for complete system outages during the release windows.
  • The business will be given as much advance warning of any unplanned system outages as possible.
  • The final scope of all Releases transported into the Production environment will be published to an agreed central point.
  • Operations will be responsible to translate the Release scope into business language and to communicate to all Global Template users as appropriate.
  • Emergency Release notifications will be communicated to users as appropriate by Service operations.
  • Operations will be responsible to ensure that all appropriate training, portal content, process updates, work instruction updates, etc. are complete within the communicated Release Plan timescales as defined by the Release Manager.
  • Releases will be communicated to the countries as part of the current monthly governance process via a monthly Governance Meeting.

 Each Release must be carefully planned and the key dates communicated to all relevant stakeholders.  Each release requires a detailed timetable of the checkpoints and cut-offs leading up to the transport into production.  A detailed Release plan must be communicated to all relevant stakeholders as far in advance as possible in order that the appropriate activities may be planned and the appropriate updates and signoffs may be gathered. Stakeholders involved in each release will be expected to provide the relevant updates to the Release Manager at a weekly Release Status meeting.

 Hope this series of blogs will give some insight to release management process as this approach yielded great benefits to us in couple of projects spanning multiple geography as well multi country roll out.

1 Comment
You must be Logged on to comment or reply to a post.
  • Good document ..

    It will be more helpful if this can be supported by examples like release calendar, tools integration , outcome/success story with gains.