release stakeholders

Release Manager

When covering dominant release stakeholders or stakeholder groups we should always start with the most dominant stakeholder: the release manager. Release manager is the responsible role for consolidating all the different interests and focuses of release stakeholders for the overall benefit of a successful release.

The below chart does not include all possible silos or stakeholder groups of a release cycle rather serves as an example of the different forces that cooperate or collide while working in a release. 

Business 

Business is the primary source of change requests in any release processes or SDLCs. Not always but usually they are also the sponsors of changes/projects/programs/transformations. Their motivators usually are TTM (Time-to-Market) and TCO (Total Cost of Ownership). These considerations are shaping forces in every release decision. The challenge for release management is to clarify with business requestors that their individual projects are part of a bigger unit, called release, and sometimes their projects need to compromise for the greater good of the release. (typical example if a project needs to wait for other changes to GOLIVE together)

PMO 

Demand management and the whole Project Management Office have a special relationship to releases (or release trains). Project managers are responsible for everything happening in a train car: budget, resources, delivery due dates, etc. but that train carriage is connected to many other carriages and all those wagons constitute the release train. So PMO and Release Management are complementary departments that are to support each other and are also tightly knit together for the success of a release.

Design

The design team of business analysts and solution architects have a unique relationship to projects and releases. Business analysts try to understand business requests the best possible way and translate those requests precisely to solution architects. Architects' focus is to create or follow the best software architectural solutions for the IT infrastructure and the architectural strategy of the organisation. For the first look they don't interfere with release processes much but in reality they are the very source of all future issues and difficulties that a release can face, so it is important to involve all other stakeholders in the review and approval of their work products hence avoiding future issues usually in build or in operation. The design team is also a great help (or approval entity) for QA to create effective test plans with the lowest possible resource needs (test case amount) and the highest possible test coverage.

Vendors/developers

The Build phase of a release is the 'factory' where the actual software development takes place either in-house or delivered by third-party software vendors. In a good release process developers and vendors are participants of previous gate-decisions (entry and exit approvals) hence they are familiar with all change requests/HLDs/LLDs/projects that are arriving to their 'workshop'. As the name DevOps suggests, the most effective SDLCs are the ones where developers and operation have good channels of communication. From release management point of view it is the release's responsibility to maintain those channels for the interest of the release. (good examples are the testing support and GOLIVE support where good cooperation of developers and operation is critical)

Quality Assurance

Testing must have a unique point of view of the release process. If we consider static testing and dynamic testing together then we can surely say that testers are the guardians of the gates between release stages. At the beginning release units/projects/changes must pass static testing to enter and later exit the Design stage and be able to be scoped into a release. And once a change is scoped into a release the release gates and any other decision points are all based on test results.

Operations

In a good release process operations are involved in release decisions as early as possible. The best release scopes are formed when the opinions and considerations of operation is also considered. As operations usually has huge amount of empirical data of the difficulty of running specific applications and the risks of introducing possible changes. Not to mention the fact that an average IT org it is the operations building and supporting test environments for releases.

Security

Security as an upcoming, ever-strengthening group in an IT org has deal-breaking decision making power. Obviously patching is their primary domain in IT but beyond patching there are EOSL (End-of-Software-Life) decisions and even architectural approval rights in the hands of IT Security. So their involvement in all and every release decisions is crucial.

Others

There could be other departments, business units or stakeholder groups mentioned specifically as release stakeholders but such structure always depends on specific IT organisation. This is the reason why the customisation of any release playbook is necessary. (In release methodologies there is no one-size-fits-for-all soultions.)

 
Honourable mentions of possible release stakeholder groups are: 

• Legal

• Compliance (GDPR/DPO)

• Sales/Marketing

• Strategic Planning (M&A office)

• R&D