Enterprise Release Management Tools Group Test

The ITSM Review will be performing a deep dive review of Enterprise Release Management tools.

This article provides an introduction to Enterprise Release Management (ERM) and a high level summary of typical functionality.

Notes

  • This group test will be conducted by Rebecca Beach, our ITSM Analyst, and Rob Spencer, Change and Release specialist and vice-chair of the UK itSMF Transition SIG.
  • We’ve also included a few examples of providers who offer ERM capabilities – please let me know of any other suggestions.
  • If any suppliers wish to participate in our Group Test please contact us before 30th September 2014.
  • Learn more about our Group Tests.
  • Read our back catalogue of completed Group Tests.

Thanks, Martin


Introduction to Enterprise Release Management

By Rob Spencer

How do organisations plan tens or hundreds of releases a year across project delivery, vendor patching, infrastructure changes and more? How do they manage competition for access to test environments, ensure they spot colliding production releases in good time and avoid overbooking their test teams?

How do they articulate this enterprise-wide release roadmap to senior stakeholders, customers and IT staff?

Traditional answers to these questions usually take the form of project plans and spreadsheets. They rely on regular meetings between project office, operations & technical staff to keep them in sync, and are rarely, if ever, accurate in real time.

Today, a new breed of release management planning tools is emerging. Enterprise Release Management tools are agnostic of functional requirements or constituent change requests, and they don’t manage the actual deployment of code. They simply allow the entire IT organisation to track and manage the entire portfolio of releases across all environments. They have the scope breadth of a Change Schedule, but go into more detail.

At their simplest, they are a single source of the truth for the multitude of spreadsheets they replace, but most can pivot this data to provide people with the information they care about in customised and intuitive views – from CIO roadmaps to a test manager’s forward work plan.

Ultimately, they give Service Operations a reliable, realtime view of all upcoming releases with at-a-glance assurance that the right governance has been completed for each. And since they span both development and operations, many are starting to be called DevOps Release tools.

ERM

What does an Enterprise Release Management tool do?

  • Plans (and scopes) a release – Allows the construction of an end to end release plan following a user-customisable structure which could map to eg. an organisations’ project governance gateways. Should be able to record both governance activities/milestones as well as physical activities in multiple environments (deployments, test runs etc). Ideally should be templatable and re-usable.
  • Plans ALL releases – Takes the individual releases and plots them against a common timeline to spot resource over/under utilisation, go-live collisions and tells operations when to brace for action.
  • Manages environment & resource usage – Pivots the data from all releases and show an environment – or resource -centric view of the same data. Helps answer questions such as “what’s happening in our Pre-Prod environment next week?” or “can I deliver everything I promised?”
  • Presents data in various views depending on audience – The steering committee has different needs to those of a test manager, and the project needs to be able to see anything relevant with a few clicks. Does the tool allow varying levels of detail to be presented over user-defined timescales in a clean and coherent way no matter the format?
  • And not forgetting… – Role based access to stop people from seeing the wrong things (or changing them), the ability to dynamically import and update change requests from other tools (data exchange mechanisms such as XML and RESTful APIs are becoming the norm in service tools).

Methodology

To test these, we’re constructing an entire fictitious company with a busy year of releases including new system deliveries, infrastructure refreshes, monthly & quarterly patching to cloud and on-premise services. We’re covering both agile and waterfall development & delivery methodologies, and even introducing some DevOps practice. We’re sharing this case study with the participating vendors, and we’re also going to make our own spreadsheet versions of the plans (which we won’t share with the vendors in advance). Our case study also includes some fairly thorny problems which a typical organisation could encounter eg. scheduling conflicts, people not following process and people whose idea of planning is far removed from the reality of their customers’ needs.


Here are some tools we are aware of in this area.

If anyone knows of any others please leave a comment below or drop us a line. I will update the list as we find new suggestions. Thanks, Martin

Implement Enterprise Request Management in Five Straightforward Steps

 This article has been contributed by John Sundberg, Co-founder and President of Kinetic Data.

John Sundberg
John Sundberg

A new approach to service request management is gaining ground in companies around the globe. Called Enterprise Request Management, or ERM, this framework is finding favor with organizations because it allows them to take an incremental and evolutionary approach to centralizing and modifying business processes and service requests across the company.

ERM operates at the intersection of the three levels of IT service catalog maturity identified by Forrester Research:

  • Level one – organizations focused on “delivering IT services to consumers through a standard set of choices and/or requests”
  • Level two – service catalog automating enterprise services
  • Level three – service catalog acting as a “service broker”

Let’s take a look at five steps involved in implementing ERM:

  1. Design your business process;
  2. Involve your stakeholders;
  3. Identify gaps in technology;
  4. Test the processes; and
  5. Refine and build onto the processes.

Design Your Business Process

Every business has request fulfillment processes that employees would love to improve, whether it’s as simple as resetting a password or as complex as onboarding new employees. The first step is to identify and prioritize improvements in these processes in terms of what is both realistically achievable and what has the greatest impact on user satisfaction.

Next, break the process down into discrete tasks. What task is the easiest to improve in the shortest amount of time? Start there before proceeding to tackle the more vexing tasks.

Look at what types of phone calls are overburdening your IT service desk. Are most of them for password resets or are users having problems with software installs? Also, look at which other departments have common support request issues, like paid time off requests in the human resources department, or conference room reservations in the facilities department.

With a service request portal and a back-end process automation tool, ERM provides a simple solution to these types of calls. With an online self-service request portal, users can log and track common service requests themselves while the “back-end” system manages the approval and fulfillment workflow of the request.

It doesn’t stop there, however. The flexible and extensible design of ERM allows you to add more (and more complex) types of requests over time.

ERM is designed to automate most, if not all, of the tasks within the service request management lifecycle – including centralized request management, scheduling, approvals, analytics, Service Level Agreement (SLA) tracking, status, charge back, billing and reporting – by linking to and coordinating with the software systems enterprises already have in place (systems of record) to handle these tasks.

Involve Your Stakeholders

With ERM, fulfillment processes are customer-centric. In other words, they’re designed from the customer’s perspective rather than from what appears to be the most convenient or logical approach for internal service providers.

So, it’s important to involve the appropriate stakeholders by assembling a small project team consisting of a business analyst, a developer, the “owner” of the process, a representative from management, and, most importantly, the users themselves, who can articulate the desired outcome in their own terms.

Keeping the team relatively small is important, since larger teams are more bureaucratic and take longer to get things done.

By keeping an open dialogue, users will be accepting of — and possibly even eager for — the changes that ERM will facilitate in simplifying complicated or broken request fulfillment processes.

Identify Gaps in Technology

As with any project, it helps to take one step at a time. Don’t get mired in the current state of your technology or existing processes, which can be a recipe for inaction. Often you’ll find that if you “think small” by breaking processes down into realistically achievable goals and by building on the momentum from these small victories, your current technology may not be as inadequate as you first thought.

However, frequently new front-end “systems of engagement” and flexible process automation tools may be needed. But make sure they’re designed to interact with back-end systems of record with little or no modification.

Test the Processes

With the ERM approach, it’s easy to create and test processes with very little risk because the core programming code doesn’t get modified. Feel free to make changes as needed and then test again. Once the process is concrete, is can be cloned and modified for other similar needs.

Refine and Build Onto the Processes

With ERM, the best approach is an evolutionary one. Start with the low-hanging fruit — the broken processes that have the greatest impact on customers. Work from these successes and the experiences gained, and then expand efforts wider and deeper into other request fulfillment processes.

After making any desired adjustments, deploy a more efficient way of fulfilling requests by using ERM and determine the next processes that need to be fixed. By learning, iterating and improving, ERM can easily move out of IT and unify service request fulfillment across your organization.

As you can see, the benefits and ease of ERM simply are too good to pass up. After all, who wouldn’t want lower service delivery costs and happier customers? So, wait no longer – now is the time for your organization to join the ranks of those realizing the benefits of ERM:

  • An improved user experience
  • Centralization of business services
  • First-time and automated fulfillment
  • Leveraging of existing systems.

Regardless of your organization’s level of request management maturity, you’ll find that ERM is the “glue” that unifies service request fulfillment across your enterprise. You can learn more about ERM here. 


The ITSM Review are holding a series of seminars this year headed by ITSM superstar Barclay Rae. We will be starting in March with Transforming User Experience – Enterprise Service Management & Self Service. For more information click here