Guardian News & Media: "Our SLA is to ensure the paper is published"

Guardian News & Media

Guardian News & Media (GNM) publishes theguardian.com, the third largest English-speaking newspaper website in the world. Since launching its US and Australia digital editions in 2011 and 2013 respectively, traffic from outside of the UK now represents over two-thirds of the GNM’s total digital audience. In the UK, GNM publishes the Guardian newspaper six days a week, first published in 1821, and the world’s oldest Sunday newspaper, The Observer.

theguardian_rgbGNM is a dynamic and pioneering news organisation across all departments. Amongst all this cutting edge transformation, GNM’s IT service desk has been going through its own upheaval. Over the last year the team has experienced arguably the most transformative change any service desk is likely to face—that of insourcing from a third-party outsourcer and rebuilding from scratch.

So what is life like for IT service management (ITSM) folks at GNM? How do they handle delivery of IT services for one of the world’s leading brands?  How have they insourced the service desk? These are all questions I was keen to ask when I met the team in London.


Note: SysAid commissioned this case study. Thank you to Vicky, Louise, and Steve from Guardian News & Media for being so candid and sharing their views. 


Meet the team

Left to right – Steve Erskine, Louise Sandford and Vicky Cobbett, Guardian News and Media
Left to right – Steve Erskine, Louise Sandford and Vicky Cobbett, Guardian News and Media

Insourcing the service desk

GNM has around 1,700 staff working for them globally. Roughly half of GNM staff work in commercial teams, the other half are in editorial teams including worldwide journalists and bloggers. The 60-member IT team supports 1,200 Macs, 800 PCs and twin mirrored datacentres in London and Bracknell.

The service desk was insourced from the 1st August 2013 when a team of six service desk analysts took over the front line of IT service and support.

The insource meant choosing a suitable solution to underpin its service management processes. Previously, the IT team was provided with technology as part of IT outsourcing contracts, such as Remedy or ServiceNow. With ITSM now firmly the responsibility of the in-house teams, there was a requirement for a smaller system that suited their needs. Flexibility and value for money were key drivers. Following a review of the market, the team chose SysAid.

A GNM version of ITIL

The IT support team at GNM records 600–650 incidents a week, working core hours of 8am until 6pm, with extended cover until 3am to support publication of the printed newspaper.

“We resolve as many calls as we can on the first line, not just log and flog, we try to do as much as we can and only escalate to second line if we get stuck,” said Vicky Cobbett, Service Desk Manager.

Incidents arrive in the way of system monitoring, email, telephone and walk ups. The team has not yet implemented any self-service options with SysAid, as they wanted to build up a reputation and confidence in existing channels first.

Third line teams are arranged by technology stack or competence area, such as business applications, networks, integrations, multimedia, AV, Oracle applications and so on.

“Our technology base is really quite broad,” says Steve Erskine, Technology Supplier Manager. “We are digital first. It’s a very different company than the newspaper I originally joined.”

“GNM is at the cutting edge of the media industry, it means we are constantly changing. We are constantly being brought new things to manage,” added Louise Sandford, Application Analyst.

Like most organizations that refer to best practice frameworks, GNM has cherry picked guidance from ITIL to suit its requirements.

“We’ve adopted a GNM version of ITIL,” says Steve.

“We have a Change Advisory Board (CAB) every Monday and use SysAid to manage all of our changes. If you look at the ITIL book, we’re not quite doing it the way ITIL suggests, we’ve taken the bits that are appropriate for us.”

“For example, we don’t have a change manager because of the diverse teams in our IT staff, but we make sure we follow a change management process and follow ITIL where appropriate.”

“Individual teams get direct calls too. We work in a deadline driven environment so things need to be resolved quickly. Sometimes you need to resolve the ticket before logging it,” said Louise. “We try not to get too caught up in process protocol – publishing the paper comes first.”

Our SLA is to ensure the paper is published each night and that our website remains online

Publishing the newspaper and keeping the website up in total alignment to business requirements was a recurring theme during our conversation. There is no time for navel gazing about service desk metrics at GNM. Its focus is on deadlines and the key priorities of the business seem familiar to the old fable about President Kennedy visiting the Space Center.

It is said that the President approached a man sweeping and said “Hi, I’m Jack Kennedy. What are you doing?” to which the janitor replied “I’m helping put a man on the moon, Mr President.”

I found their customer focus refreshing. I asked the team: “How do you know if you’re doing a good job? How do you measure success?”

“The newspaper gets printed. The website is always up,” said Vicky.

The team monitors call volumes, call open times and escalates where appropriate – but the main focus of meeting customer requirements is via the personal relationships developed by Business Relationship Managers (BRMs) who go out to the business and listen for requirements, help prioritize projects and develop a medium term plan.

“Success for me is if we can put processes and procedures in place without slowing the business down,” said Steve.

“We don’t get too caught up with measuring statistics. The company knows we work hard to close all tickets as quickly as possible and are focussed on helping the company print the paper and keep the website up,” said Vicky.

“In terms of statistics and metrics and comparing this year with last year – that’s not what we’re about… and I don’t think we’ll ever get to that point,” added Steve.

“We work in a vocal environment, if we’re not doing the right thing people will soon tell us. We also have our BRM team who are going out to the business to ensure we are doing the right thing and meeting their requirements.”

“We don’t really work to formal Service Levels. We might be working on something quite important to one person, but if something happens, which means we can’t get the paper out, everything gets dropped to fix it and that person will have to wait. If we’re going to breach a Service Level Agreement (SLA), we’re going to breach it. We’ve got to get the paper out.”

“Everyone in the company has this focus. It’s our purpose for being here,” added Louise.

Why SysAid?

As Application Analyst Louise is the main owner of SysAid. She has looked after the application since insourcing back in August and works with their account manager Yair Bortinger at SysAid.

GNM learnt from working with previous tools that despite all the bells and whistles on offer they would only end up using a small fraction of the features available. So a reason for choosing SysAid was that it is a smaller system and easier to customize to their own requirements.

“We find it user friendly,” says Louise. “With other systems we’ve worked with you have to stick to the templates or labels issued by the software company. SysAid is a lot more flexible to customize to your own requirements so you can label things the way you want them and in a way the whole IT department will understand. We use the cloud version so we can use it anywhere, we can use it at home.”

A quirky bunch

I asked the GNM team about their experiences with SysAid as a company. They were extremely complimentary. Specifically, the team stated that customer service was their strongest asset.

“They’re a quirky bunch,” said Vicky, “very, very friendly.”

“They are amenable and get back to you quickly,” added Louise.

“Sometimes when you work with software companies, you’ll deal with the salesperson and they are the friendliest person in the world, but once you’ve signed the contract the relationship changes. With SysAid, when we phone them up, they’re as friendly as the day we signed the contract,” said Steve.

“…And that’s not just one person, that’s everyone you speak to, the account management team, professional services, senior management,” said Louise.

“We sometimes ask the professional services team to do something completely random and weird and they say, yeah ok, we’ll do that for you,” said Vicky.

“I hope they don’t get bought and stay as they are. We are doing this case study because they are good not because of some commercial arrangement. We want to give something back in exchange for their great product and great service,” added Steve.

IT Service desk bar

The IT service desk ‘walk up’ desk. Situated away from the main IT department in a central position within the business.
The IT service desk ‘walk up’ desk. Situated away from the main IT department in a central position within the business.

The GNM IT team has built an “IT service desk bar” as a concierge desk for walk-in IT support enquiries. It is situated adjacent to a main stairwell and thoroughfare of the business and is intentionally separate from the rest of the IT department. Three service desk analysts work at the service desk bar, which accounts for around 15% of all incidents.

“It’s meant that we’ve built better relationships within the company. They see IT as having a face rather than being a voice at the end of a phone,” says Vicky

“But around 15%–20% of incidents come from the service desk bar. 50–60% come in via email and around 20–25% are phone calls.”

Customizing to requirements

Louise estimates that the split between in-house customization and development from SysAid is around 70/30.

“I do as much of the customization myself and liaise with Yair and the SysAid professional services team to do everything else,” said Louise.

“One of the great things we like about SysAid is that it’s so configurable and it’s very flexible. It is also quite user-friendly, so without a huge amount of configuration knowledge you can pick it up and use it quite effectively.”

User account creation, which was previously managed in Lotus Notes, is now handled by SysAid.

“That was a custom project they built for us. SysAid is used to automate the account creation of logins for new users. It’s completely out of scope for what SysAid is designed for but they’ve been very ‘can do’ about the whole project. It feels like a partnership,” said Vicky.

Future plans

Having embedded change management, the team aims to look at problem management in more detail and also plans to build an asset register to record laptops and desktops using SysAid. Knowledge management is also on the agenda, done at a steady pace with issues ironed out as they go.

“It’s such a small system in the grand scale of things in terms of all the systems we use. But it’s such an important one,” said Louise.


Guardian News & Media

  • The Guardian first published in 1821
  • Offices in UK, USA, Australia
  • Headquarters: King’s Cross, London, UK
  • Revenue Guardian Media Group Plc. £210M
  • Over 100million monthly unique browsers for theguardian.com
  • 1,700 staff, 60 IT Team staff
  • www.theguardian.com

Overall Review of SysAid by Guardian News & Media

“It’s a great tool, with great service,” said Steve.

Strengths

  1. Customer service from the SysAid team
  2. Ease of use
  3. Customization

Weaknesses

  1. Reporting – doesn’t have the depth we’d like but SysAid is addressing this in Q4 2014.
  2. Reverse customization – when you’ve built something by configuring it and need to undo it, it is not always straightforward. Some elements aren’t as friendly as others. Some of the workflow elements could be improved.

Ratings

  • Customer Service 9.5/10
  • Product 8.5 / 10
  • Reporting 5/10

The secret to change success – understanding multiple perspectives

People
People are both the problem and the answer

A recent Forrester consulting study (commissioned by automation vendor Chef and downloadable from their website at the link above) found that 40% of Fortune 1000 IT leaders report first time change success rates below 80% (or they simply didn’t know what the first time change success rate was at all), with another 37% stating their first time change success rate was between 80% and 95%.

In the same study, 69% of these same Fortune 1000 IT leaders report it takes them more than a week to make infrastructure changes, and an equal 69% report that it takes them more than a week to release application code into production (mind you that’s not to develop, test, and release the code, but just release code that’s already been written and tested!). Finally, 46% report that more than 10% of their incidents were self-inflicted from IT changes and, shockingly, 31% say they don’t even know what percentage of incidents are caused by changes!

Why Otherwise Capable IT Leaders Struggle with Change

What is going on in these IT shops to produce such bad numbers?  Based on my experience with a number of Fortune 1000 IT organizations, I’d like to think that these study participants are  just as smart and capable as the IT leaders and professionals I regularly meet with. They are well educated, very experienced (as are their teams), and nearly all of them have some form of change process, changes management software and a change advisory board to assess risks before changes are made. So, why isn’t this enough to produce better results?

I submit that there are two problems, which are actually related to each other.

Problem One

Our environments have become extremely complex. The dependencies and relationships across multi-tiered applications / business services are way more than what one individual can know fully – no matter how talented and how long they’ve been working there.

Trends like virtualization, agile development, cloud, mobile, big data, etc. are also making this even harder as IT moves faster and faster to respond to business needs and as innovative new technologies proliferate.

Problem Two

We aren’t effectively capturing the input from multiple perspectives during the change planning process so we aren’t effectively identifying and mitigating risks.

Think about how a typical change and release planning process goes. It starts with a request for a change and a change planner filling out an electronic form about it. They assign various people to review and approve the change and this step might include consulting with a spreadsheet, perhaps looking at Configuration Item (CI) information in a CMDB, and maybe calling a meeting or sending out an email or two.  In a lot of cases, those selected to participate in the review will include managers or more senior roles who don’t have a very good working knowledge of the operational environment, so they consult with their teams (or at least we hope they will) and eventually the change gets brought forward to the Change Advisory Board (CAB) for a formal approval. It may have taken a week, two weeks, a month or more just to get to this point.

Then the CAB, which is often made up of even more senior people, reviews the planned change. Often one of the CAB members will recognize that a key team or expert wasn’t included in the review process and “kicks it back” for further input and the change approval is rescheduled to a future CAB meeting.  Equally often there’s a lot of pressure from the business to make the change happen right away (it could be a new application release the business has been waiting for), it could be a security fix and “we just can’t allow ourselves to be exposed by delaying it”, or maybe it’s just a firmware upgrade to a router and the vendor has said “it’s no big deal”.   So the CAB says “go” and hopes everything works out okay, but a lot of times it simply doesn’t.

People Are Both The Problem And The Answer

By now you may have guessed that the way we engage people in the change process is not only the problem, but it’s also the solution. There’s a great quote from the MIT artificial intelligence expert, Marvin Minsky, that I think is very relevant here: “You don’t really understand something until you understand it more than one way.”

This is, in effect, what we try to do by assigning multiple reviewers and approvers to a change request, but the problem is that we often guess about whom the best people are to involve so we end up oversubscribing the list and inundating people with emails and meetings or we undersubscribe and leave out key individuals.

The information these people have to work from is also very fragmented. Yes, we have our CMDBs and CI information, but they’re often incomplete and not always trusted, so people fall back on their tribal knowledge, which may also be incomplete and out of date.  A lot of the time, we might intentionally leave out groups because we think that will slow things down, “Do we really need to involve the network team on a SAN upgrade? Why do we need security involved in a database patch?” The network might have a direct impact on the success of the SAN upgrade, because we might need to optimize network device settings to handle additional load to the SAN. That database we’re patching might contain sensitive customer data and the right patch procedure better be followed or we’ll create a compliance problem. So if we leave out people that may be necessary, we create unexpected ripple effects from our changes too.

Engaging Relevant Experts to Collaborate Is The Key

I suggest that there are two things we need to do in order to better engage the right people so we can improve first change success rates, speed the time to execute changes, and reduce incidents from changes:

  1. We need to know up front who the right people are to involve (and who not to involve as well), so we can be sure we include all the right perspectives (and don’t unnecessarily pull people off of what they are already working on as well)
  2. We need to arm those we involve with accurate information about upstream and downstream dependencies so they can make informed and quicker recommendations

As an industry, this is what we should be focused on rather than whether a strict approval process alone was followed. By enabling our experts to opt-in to the things they are responsible for and care about, they can be automatically identified and engaged when it comes time to plan a change .  We also need to take a lesson from academic journals and apply a peer review process to our CMDB data so we can increase trust in its use and fill in the gaps with the tribal knowledge of our experts, validating that both sets of information are accurate and up to date. With this type of an approach, we can have a much stronger basis for smarter change decision-making. This is exactly the type of approach we’re taking in my organization, and I invite you to check out what the ITSM Review team has to say about it.

Image Credit

Change Management – Surviving Implementation

253914822_f34c961bd6_z
The super power of a change manager is an “invisible shield”, just like Violet from The Incredibles

One of the things I’m getting asked about most this year is about getting the basics right – how to actually do change management in the real world. We all know that having good processes in place protect us all, ensures we meet regulatory guidelines and are generally just common sense, but what about using them so that we can build a better, stronger IT organisation? In this article, I’m going to talk about getting started and surviving the implementation phase. I’ll then follow it up with another article on how to actually run your change management process.

Let’s start from the beginning. change management sits in the transition stage of the service lifecycle. ITIL states that the objective of change management is “to ensure that changes are recorded, evaluated, authorised, prioritised, planned, tested, implemented, documented and reviewed in a controlled manner. In a nutshell, change management is about putting things in, moving things round or taking them out, and doing it safely and without setting anything on fire.

When describing the change process, I call change managers the guardians or protectors of our network. They ensure all changes are sanity checked, tested, reviewed, approved and scheduled at a sensible time. Their super power is an invisible shield (like Violet in “The Incredibles”) that protects the rest of the organisation from the adverse impact of change.

Getting started: Common Excuses and Ways Around Them

Change management is an incredibly important process because it enables you to manage, control and protect your live environment. Since the credit crunch, I’ve had more and more people coming to me saying that their change departments would either have to endure massive cut backs or stop improvement works. Here are some of the most common excuses I’ve come across for this along with some possible ways around them.

Excuse number 1: “We don’t have the time”. Ok, what about all the time wasted dealing with the impact of failed or unmanaged changes, firefighting incidents and dealing with the big angry mob camped outside the IT department waiting to lynch us for yet another mistake? Let’s be sensible, having a strong change process in place will lead to massive efficiency savings and the use of standard changes, models and templates will make the work involved repeatable.

Excuse number 2: “We don’t have the resources”. What about all the time spent going cap in hand to the rest of the business explaining why a key service was unceremoniously taken out by a badly executed change? Spin doctoring a major incident report that has to go out to external customers? I’d argue that you’re wasting resources constantly firefighting and if you’re not careful it will lead to stressed out departments and key individuals burning out from the stress of trying to keep it all together. Instead of wasting resources and talent – why not put it to good use and start getting proactive?

Excuse number 3: “We don’t have the money”. What about all the money spent on service credits or fines to disgruntled customers? Then there’s the less tangible side of cost. Reputational damage, being front-page news, and being universally slated across social media – not nice and definitely not nice having to deal with the fall out. Finally, what about compliance and regulatory concerns? Failing an audit could be the difference between staying profitable or losing a key customer.

Excuse number 4: “We can’t afford expensive consultants”. Ok, hands up. I used to be a consultant. I used to work for Pink Elephant UK and for anyone out there looking for an amazing consulting / training company then go with Pink – they rock. That aside, if you can’t afford outside help in the form of consultancy, you still have lots of options. Firstly, you have the itSMF. Again, I’m biased here because I’ve been a member, as well as a speaker for, and chair of, various sub groups and committees, all in an attempt to champion the needs of the IT service management community. Here’s the thing though, it’s useful war stories, articles, white papers and templates written by the members for the members. There’s also ISACA which focus more on the governance and COBIT side of things. There’s the Back2ITSM movement – lots of fantastic help support and information here. There’s the ITSM Review and blog sites from the likes of The IT Skeptic – lots of free resources to help you sort out your change Management process.

Excuse number 5: “I’m probably going to be made redundant anyway so what’s the point?” Yes, I am serious, this is an excuse I’ve come across. There’s no way to sugar coat it, being made redundant or even being put at risk is (to put it mildly) a rubbish experience. In that situation (and believe me, I’ve been there) all you can do is keep doing your best until you are told to do otherwise. Having a strong change management process can be a differentiator on responses to bids. Tenders as SOX compliance, or ISO 20000 accreditation can set you apart from competitors. Bottom line, we have to at least try.

Planning for Change Management

So how do you get started? First things first: you need to get buy in. Most management guides will tell you to focus on the top layer of management as they hold the purse strings, and that’s very true, but you also need buy in from your guys on the front line – the guys who will actually be using your process. Get their buy in and you’re sorted, because without it you’re stuffed.

So, starting with the guys at the top, you need to speak to them in their language and that means one thing – a business case! This doesn’t have to take forever and there are lots of templates out there you can use. The key thing is to explain clearly, in their language, why change management is so important. Things to cover in your business case are introduction, scope, options, deliverables and benefits. Now get your techies on board. There’s no “right” way of doing this. As someone with a few war stories to tell, things that have worked in the past include:

  • sitting down with your techies
  • templating everything
  • using the umbrella argument (more on that later)
157147622_3b79fa7cab_z
Krispy Kremes can help

I’ve also found that bribing support teams with doughnuts can be very effective, as a former techie I can confirm that Krispy Kreme ones work particularly well.

Once you’ve got your buy in, gather and confirm your requirements.  At the risk of playing management bingo here, a good approach is to set up workshops. Engage with both IT and the rest of the business so that there are no surprises. If you have an internal risk or audit department now is the time to befriend them! Using the aforementioned donuts as bribery if necessary, get their input as they will have the most up to date regulatory requirements you need to adhere to such as SOX or Basel 3.

Define the scope otherwise it will creep! Plan what you want to cover carefully. Do you want to cover all production equipment? What about test and DR environments? Whatever scope you agree, make sure it is included in any SLAs, OLAs or underpinning contracts so that you have documented what you are working to.

Keep your end users in mind

When writing your policy, process and procedures, keep your end users in mind. Don’t try to cover everything in red tape or people will find ways to circumvent your process. Let’s start with your policy. This is your statement of intent, your list of “thou shall” and  “thou shall nots”. Make sure it’s clear, concise and is in alignment with existing company standards. I know this might sound counterintuitive but also, prepare for it to be broken. It might sound strange but there will be times where something will need to be fixed in the middle of the night or there will need to be an urgent update to your website. It’s important that changes are raised in enough time for them to be reviewed and authorised, but exceptions will pop up so plan for them now when you’re not under pressure. Examples of when an emergency process could be used are:

  • Something’s broken or on fire (fixing a major incident)
  • Something’s about to be broken (preventing a major incident)
  • Major commercial reasons (in response to a move by a competitor)
  • A major risk to compliance has been identified (e.g. base rate changes, virus patches)

When looking at your process, make sure you have all the bases covered. This will include:

  • Recording and processing the change
  • Change assessment
  • Change Advisory Board (CAB)
  • Build and test
  • Implement
  • Review and close

I’ll talk about these in lots of detail in part two of this article.

Training & Communications

You’re about to go live with your sparkly new change management process and you want it to be a success so tell people about it! First, attend every team meeting, management huddle and town hall that you can get away with! Get people onside so that they know how much help change management can be and to reassure them they won’t have to go through lots of red tape just for the sake of it. Another way of getting your message out is to use posters. They’re bright, cheerful and cheap – here is one that I’ve used often.

2650056763_2a7cd6b746_z
Pelt front line teams with coloured balls if necessary! Not too hard though!

In terms of training you need to think about your change management team and your stakeholders, the people that will be raising changes using your process. For your change management team there are lots of practical courses out there that can help – a few examples could include:

  • ITIL Foundation
  • ITIL – Service Transition
  • ITIL – Release Control and Validation (RCV)
  • COBIT
  • SDI Managers Certificate
  • ISO 20000

Other important considerations include:

  • On the job training
  • Shadowing

But what about your front line teams who will be raising the changes and carry out the work? Again put some training together – make it interactive so that it will be memorable – in the past I have been pelted by brightly coloured balls by a colleague in the name of explaining change management so there really is no excuse for death by PowerPoint!

Things to cover are:

  • The process, its scope and the definition of a change
  • Raising a change record to include things like implementation plans, back out plans, testing, risk categorisation (“no it is not ok to just put medium”) and DR considerations
  • Templates & models
  • Benefits

I’ve done a fair few of these in my time so if you would like some help or examples just ping me on my contact details below.

Go Live

So you’re good to go. You’ve gathered your requirements, confirmed your scope, got buy in and have written up your policy, process & procedures. You’ve socialised it with support teams, ensured everyone has been trained up and have communicated the go live date. So deep breath time, go for it! Trust yourself, this is a starting point, your process will improve over time.

Metrics

I’ve written lots about metrics recently and have spoken about the basics in a previous article on availability, incident and problem management but in short:

You need to have a mission statement. It doesn’t have to be fancy but it does need to be a statement of intent for your team and your process. An example of a change management statement could be “to deliver changes effectively, efficiently and safely so that we put the customer at the heart of everything we do”.

Next come the CSF’s or critical success factors. CSFs look at how you can achieve your mission and some examples for change management could include:

  • To ensure all changes are carried out effectively and safely.
  • To ensure all changes are carried out efficiently, on time and with no out of scope emergency work.
  • To work closely with our customers & stakeholders to ensure we keep improving while continuing to meet their needs

Finally, we have Key Performance Indicators or KPIs. These give you the detail on how you are performing at the day to day level and act as an early warning system so that if things are going wrong, you can act on them quickly. Some example KPIs for change could include:

  • More than 98% changes are implemented successfully
  • Less than 5% of changes are emergency changes
  • Less than 10% of changes are rescheduled more than once
  • Less than 1% of changes are out of process

So you’ve survived your change process implementation – smile,  relax and take a deep breath because now the real work starts! Come back soon for part two of this article which will give you some practical advice on running your new change management process.

Image Credit 1

Image Credit 2

Image Credit 3

Assessment Criteria – Change, Config and Release

Today we begin our competitive analysis of Change, Config and Release.  As with previous reviews our goal will be to highlight the key strengths, competitive differentiators and innovation in the industry.

Widely recognised as key to the successful preservation of production systems, the ITSM processes of Change, Config and Release are perceived as pivotal to maintaining the integrity and stability of the IT environment.

Flow diagram showing the five areas of Change, Config and Release.  These will not always be used in order and Auditing and Reporting should be ongoing.
Flow diagram showing the five areas of Change, Config and Release. These will not always be used in order and Auditing and Reporting should be ongoing.

In a nutshell:

Change Management is the process used to track and communicate any changes in service that may impact the customer such as when systems are taken offline for updates.

Configuration Management is the process used to track individual CI’s (Configuration Items) and the way in which they interact with one another.

Release Management is the process of managing software releases from development right through to release.

Each process can be used individually but more often than not you will find these processes intertwined.  When considering either a Change or Release you will need to know the CI’s that will be affected before you begin.

E.g: Your organisation needs to upgrade your in-house software package to all of its desktop pc’s, tablet devices and kiosks.

Release Management is used to track the in-house development of the software in question, Config management is used to scope the number of devices, number of people and types of people affected while Change Management is used to ensure the changes take place on a date that will cause the least disruption and that the why, how and when the changes will take place are communicated to the relevant people.

The criteria we will be using for our assessment is published below.


Identification

  • Ability to maintain a detailed record of each system’s configuration
  • Ability to interface with all internal Management Data Repositories (MDR) allowing the tool to compare reported configuration with actual configuration stored in the MDR
  • Ability to define dependency relationships between CIs
  • Ability to assign maintenance windows to CIs
  • Ability to auto discover CIs
  • Ability to interface with Inventory Control tools (to automate gathering of asset and inventory information) and barcode scanners
  • Ability to create automated alerts when a CI is found to be in an unauthorised state
  • Ability to link Release records to Change records
  • Ability to provide a Change/Release calendar with scheduled change viewing by group, and to customize the sorting and filtering of calendar views and link to existing calendar products

 Assessment/Approval

  • Calculate an objective risk assessment considering business impact and affected services
  • Show logical links between components included in a service in order to carry out business impact analysis
  • Ability to automatically create a Change Request when unauthorised changes are made to CI’s
  • Ability to schedule recurring events and maintenance
  • Ability to create and select pre-approved Change/Release from a pre-defined list
  • Pre-determined fields to auto-populate when Standard Change/Release from list used
  • Ability to capture the Change/Release date and time and who will be responsible for implementation
  • Ability to automatically send approval requests to the appropriate approvers
  • Ability to notify the assignee of the task and due date
  • Ability to link resources/approvers to Changes/Releases
  • Ability to assign tasks to individuals to be accomplished within specific time frames
  • Ability to alert Change/Release managers when approvals are past due
  • Ability to change status of Change/Release approvals
  • Ability to easily identify scheduling conflicts and reschedule appropriately

 Implementation

  • Ability to attach and store documentation with a Change/Release record
  • Ability to authorize and schedule Release deployments in conjunction with Change Management processes
  • Ability to change status of Release and linked Changes
  • Automatic notification for scheduled start/end and when the status of a Change associated with a Release changes
  • Ability to build, bundle and schedule different types of release packages for deployment
  • Ability to change status of Change/Release documentation
  • Ability to create sub activities or tasks for separate assignment to an individual, group or vendor
  • Ability to version release components and packages
  • Ability to assign tasks to teams/resolver groups

Accountability

  • Ability to track the physical location of contracts and agreements, and identify the individuals responsible for them
  • Ability to define Change and Release Windows (including freeze windows)
  • Ability to document back-out procedures
  • Ability to ensure that Release deployments are subject to scheduling and approval requirements managed by the Change management process
  • Ability to provide proactive notification to stakeholders and Change Advisory Board (CAB) members for Changes with critical business impact and provide fully configurable filtered views of scheduled changes to multiple stakeholders
  • Ability to designate back up approvers
  • Ability to set thresholds for automated approval process
  • History of approval requests logged

Auditing/Reporting

  • Ability to easily identify affected CIs whenever a change is made
  • Ability to maintain an audit trail of changes made to a CI
  • Ability to track Asset status and lifecycle management
  • Support of multiple software audit options
  • Ability to perform software license management including automated notification of license expiration and non-compliance
  • Ability to create and publish a Master Release Schedule
  • Ability to associate the Master Release Schedule with Service Level Agreement information
  • Ability to store approver comments with the approval, and store approval history for a Release
  • Ability to track and trace post deployment activities
  • Ability to trace implementation to the authorized version in the Document Management Library (DML)
  • Bulk import of licensing data
  • Ability to track costs of CI’s

General/Other Criteria

  • Alignment with industry frameworks
  • Ability to support a “virtual” CAB (i.e. approvals/issues stored electronically)
  • User-configurable forms, tables, workflows, dashboards
  • Role-based access for approvals, retracting or rescheduling RFC’s/Release
  • Open system for real-time integration with financial management and other monitoring tools
  • Provision of templates and pre-filled forms and structure to act as basic starting point
  • Vendors should provide expertise and guidance in the implementation of the tool and relevant processes

If you would like to comment on the above criteria or if you are a vendor and would like to be included in this review please comment below or contact me via email.