ITSM Release Management

(Please click on the hexagons for more information)


This tutorial explains in depth how to implement ITIL Release Management (RM) using the ]project-open[ project management system, how to comply with SoX and Basel II/III regulatory requirements and how to balance time-to-market with software quality. ]po[ Release Management is based ITIL V3.0 and is a part of the larger software development functional module.

Why Release Management?

Release management is the
process of managing software
releases from development stage
to software release.

(Wikipedia)

 

 

Please contact us for
a free online demo of ]po[
release management.

 

 

Software updates including extensions, updates, patches, new modules etc. need to be released at a production server at some moment in life cycle in order to be useful. Release management is the art of maximizing the value of these updates while reducing the negative impact of such updates:

  • Cost:
    Reduce the overall cost of maintaining software systems,
  • Time-to-market:
    Accelerate the time-to-market for updates in order to capture their benefit,
  • Reduce Interruptions:
    ... of the service being updated,
  • Improve Quality:
    ... of updates and avoid new errors in the updates,
  • Methodology Adherence:
    Ensure that required quality assurance (QA) steps have been performed,
  • Traceability:
    Allow for full transparency of the decisions underlying the release process and finally
  • Regulatory Compliance:
    Sarbanes-Oxley (SoX) and Basel II/III require organizations to "[...] document changes
    to their technical environment [...]" and to perform patches "[...] on a predefined schedule [...]" 

Release Management
Release Management process - Basic Steps (Source: Wikipedia)

]project-open[ Support for Release Management

]project-open[ includes packages and objects in order to store all relevant RM objects in it's database and to present these objects to the corporate stakeholders:

  • Request for Change (RfQ) or Change Request:
    A RFQ represents a user's request to modify the software. A RFQ is usually entered into the system using a customer portal or as a Problem or Incident ticket via the IT organization or a service desk.
  • Software Development Tasks:
    A task represents the action of actually implementing a RfQ. Tasks are usually assigned to a specific software developer.
  • Source Code or Configuration Changes:
    The developer above modifies the configuration or the source code of a system.
    These modifications need to be automatically tracked and stored for future reference.
  • Quality Assurance and Testing Workflow:
    QA testers need to perform various tests based on Test Cases. The QA results and acceptance decisions need to be stored for future reference.

 

Core Process Activities

  • Release Planning & Development:
    Collecting a number of Request for Change (RfC) and other release items that should be included in the release, analyze dependencies between configuration items and obtaining management approval.
  • Testing & Quality Assurance:
    Test the proposed release, possibly involving multiple parties and a formalized QA sign-off.
  • Release Deployment:
    Packaging of the configuration items to be released, informing users about the upcoming release, deployment of the package and preparation of the parties in service management for the new release.

 

Release Management Using ]project-open[

The core of ]po[ Release Management is a list of "release items" and their "release status":

  • Release Items:
    These are tickets or tasks that represent elements from the ]po[ IT services management and the ]po[ project management modules.
  • Release Status:
    Every release item has a release status that determines its progress from implementation to final deployment.

The screenshot below shows a graphical representation of release items and their release status. The status of release items can be modified by clicking on the green arrows.

Release Task Board


Process Input

 

Process Output 

   

Process Performance Incidators

  • Number of releases per year
  • Number of change items per release
  • Number of helpdesk issues per release (new issues because of the release)
  • New issues vs. fixed issues ratio per release

 

References 

Related Object Types

  • [Release Member] 

Related Packages

  • IT Release Management - The package implements a GUI for release items with support for an approval process using a status engine.
  • Dynamic Workflow - The workflow allows for an automation of the release approval process.

Related Modules

  Contact Us
  Project Open Business Solutions S.L.

Calle Aprestadora 19, 12o-2a

08902 Hospitalet de Llobregat (Barcelona)

Spain

 Tel Europe: +34 609 953 751
 Tel US: +1 415 200 2465
 Mail: info@project-open.com