How to Ensure Your ITSM Toolset Aligns to Your Processes

An article by Mark Sykes, Principal Consultant at Fox IT. ‘How to Ensure Your ITSM Toolset Aligns to Your Processes’ available as a PDF download.  An article intended to highlight the key activities that need to be undertaken before jumping head-first into an implementation project

 

Once a toolset and vendor has been selected, there are a number of key activities that need to be undertaken before jumping head-first into an implementation project. These include confirming the organisation’s processes are fit-for-purpose (so that the toolset can be appropriately configured to ensure alignment with those processes as well as enforcing the correct operation of the process), and validating that the vendor has satisfactorily configured the toolset in order to make certain that it does indeed underpin the operation of the process.

The following key areas will be covered in more detail in this paper:

1. Defining or Refining Processes
2. Agreeing Toolset Configuration
3. Ensuring Suitable Toolset Configuration
4. Testing the Toolset

Defining or Refining Processes

As highlighted in my previous paper, any technology solution that is selected should support the organisation’s processes not dictate them. Unfortunately in Fox IT’s experience this is not always the case. Organisations sometimes let the tool force them to do something in a particular way – usually because they want the solution to remain as ‘out of the box’ as possible, but unfortunately the reality of this approach often means that the process solution being imposed by the tool isn’t always the best fit for the organisation.

Alternatively, and as is the case for many clients that Fox IT work with, organisations use the introduction of a new IT service management (ITSM) toolset as an opportunity to take a look at their existing processes and to refine them to better suit their needs; or they take the decision to start afresh and define new processes for the toolset to be aligned to.

When starting on this particular exercise, and especially where there is a lack of existing process documentation, it will be a case of having to define and document how the processes currently operate within the organisation. Having stated this though, whenever Fox IT has been engaged to assist a client the situation we find (more often than not) is that the client wishes us to help them define a ‘future state’ for their processes, i.e. enhancing their ITSM framework for how they want their staff to work going forward. This then becomes the ideal moment to use the toolset implementation exercise as a driver for introducing those improved processes and practices, and which in turn should better support the needs of the business.

So let me use the incident management process as an example to explain what will be required. First of all identify the key stakeholders that will need to be involved in helping to define or refine the process. Fox IT always recommends engaging with the process owner, the process manager (e.g. the Service Desk Manager), and process practitioners (i.e. those using the process on a daily basis such as a Service Desk Analyst or Team Leader, 2nd-Line Support Technician, user/business representative, etc.).

Once the participants have been identified then a workshop needs to be arranged so that all aspects of the existing or future state process can be captured. For clients that have little or no documentation available then Fox IT will present the incident management process as defined in their FoxPRISM™ tool, a process knowledge database featuring 32 separate (but integrated) processes.

The workshop should start with an initial walkthrough of the process to ensure a common understanding across all stakeholders, helping to make sure that everyone knows what each of the process steps represents and what activity is supposed to be being performed. (Note: This same principle will apply if reviewing an existing documented process.)

Having ensured a common understanding of the process, it’s then a case of walking through the process for a second time so that it can be enhanced or customised to fit the organisation’s current or future way of working. This may be a case of adding in additional activities, may be amending the role that performs certain activities, or even removing some activities that are redundant.

The output from the workshop is an accurate pictorial vision (i.e. a process flow diagram) of the incident management process that the new toolset needs to underpin the operation of.

The next step is to write a process narrative – descriptive text that provides an explanation for each step in the process, including the identification of the role performing the process as well as any interfaces to other processes. This narrative and the diagram then need to be distributed for review and sign-off. If necessary, a review session can be scheduled if there are any outstanding issues or queries that require further discussion.

Process documentation

Both the process flow diagram and accompanying narrative will be extremely useful reference material for the vendor when they come to configure the toolset. Indeed, if these are available early enough in the overall project lifecycle then they could be utilised as input for the vendor selection process (to supplement the detailed requirements that have been documented) and issued to prospective vendors to further assist in determining how well a toolset supports the needs of a particular process or processes.

Agreeing Toolset Configuration

Now that the process has been defined/refined and documented, it is time to sit down with the vendor to agree how the toolset should be configured to align and underpin the process. Whilst often clients state that they want to implement a toolset ‘out of the box’, there is still always some level of configuration (rather than customisation) that needs to be done. At the same time though, it should be remembered that the toolset should support the process, not dictate it!

Arrange a workshop with the vendor and other key stakeholders (e.g. process owner, process manager) to determine how the tool should be configured to support the process. For example, when looking at the incident management process, this may involve activities such as agreeing how many priority levels will be used, the categorisation structure that is required, how records are to be assigned between teams, what notifications are required, how major incidents and service level targets are handled, etc. This is also the opportunity to review the labelling on individual fields within the toolset and to capture any revisions that may be required.

When to compromise

Usually the intention is to minimise customisation of the toolset, however on occasion it may be the case that the toolset cannot perform every step in the process exactly as the organisation wants it to be done. This is the point where there will need to be some level of compromise.

To facilitate an agreed compromise there needs to be an open discussion with key stakeholders in order to give due consideration to all of the available options and to agree on the best way forward. These considerations need to take the following into account:

• Customisation of the toolset may be possible by the vendor to ensure process alignment, but this will cost time and money in the short term to get the work done, and may also increase maintenance overheads in the longer term.
• Changing the process to fit the tool may be a short term win, but at the same time this may affect the quality of the process operation and it may also cause issues with any policy enforcement that is required.

Often, one of the drivers is to align to ‘out of the box’ as much as possible, so in this scenario changes to the process will need to be agreed. On other occasions, adherence to policy may be a mandatory requirement that will override other less crucial factors. This is particularly true where (for example) an organisation must meet compliance or regulatory requirements; in this case the tool will have to be customised as a way of ensuring those auditing needs are effectively met.

Ensuring Suitable Toolset Configuration

The output from the previous activity will be a detailed set of configuration or customisation requirements that need to be made to the toolset. It is important to ensure that these have been captured correctly as the information will be utilised to validate the changes made by the vendor.

The next exercise will be for the vendor to configure and/or customise the toolset based on the agreed requirements. The vendor should then hold a ‘show and tell’ workshop whereby they demonstrate to the client how the toolset has been amended to support both the documented requirements and the end-to-end process itself.

This is a vital step prior to initiating any formal testing. The ‘show and tell’ provides a level of assurance that the configuration/customisation requirements have been correctly interpreted by the vendor and that the needs of the organisation are being fully met. Based on Fox IT’s experience, there is often a number of iterations this activity goes through (especially for the more complex processes like change management) before a client is completely satisfied that the requirements have been appropriately implemented and that the user experience is satisfactory before user acceptance testing can commence.

Testing the Toolset

On any engagement involving the implementation of a new toolset there will be a number of different phases and styles of testing to be undertaken, such as performance, functional and user acceptance testing.

For this paper I will focus on user acceptance testing. Test scripts will need to be developed that are aligned to how the tool should be used, which in turn should reflect the operation of the process. Key users will need to be involved in executing the test scripts, with these individuals having an important role in providing feedback in the form of test results – and in particular explaining in detail any issues that arose and what exactly was being done in the toolset at the time the issue arose. Sufficient levels of detail are required such that the vendor has enough information to be able to recreate the issue (if required).

The results from all testers will need to be collated and reviewed with the vendor in order to agree any remedial activities (i.e. changes to the toolset) that will need to be made. Once any revisions to the toolset have been made then a further round of testing can be performed. A number of iterations of testing and remediation may be required until such time as the organisation is satisfied that the toolset suitably supports the operation of the process. Testing may identify that a change to the process is required, but past experience shows that this would be a highly unusual circumstance.

Summary

Ensuring that any new toolset underpins an organisation’s processes seems an obvious statement to make, but experience shows that saying one thing and doing something completely different happens more often than it should! Following the key steps outlined in this paper will help any organisation avoid this scenario. Yes, there may be a time when compromise is necessary, but as outlined above these should be carefully considered and the ramifications assessed before making a final decision.

Finally, and just to recap:

1. Defining or Refining Processes
   • Identify key stakeholders
   • Hold a process workshop
   • Produce agreed process flow diagram and process narrative
2. Agreeing Toolset Configuration
   • Identify key stakeholders
   • Hold toolset configuration/customisation workshop
   • Discuss compromise (tool vs. process) where necessary
   • Produce agreed set of changes
3. Ensuring Suitable Toolset Configuration
   • Vendors undertaken configuration/customisation changes
   • Hold show/tell workshops
   • Vendor undertakes remediation activities
   • Agreement to proceed to testing
4. Testing the Toolset
   • Perform user acceptance testing
   • Collate and review the results
   • Vendor undertakes remediation activities
   • Re-test post remediation

 

About FoxPRISM™

FoxPRISM™ is a fully interactive web-based process knowledge database that assists in the design, implementation and management of service management processes. It provides a compendium of 32 processes (aligned to ITIL and ISO/IEC 20000) and enables Fox IT consultants and their clients to accelerate their deliverables and hence realise benefits that much quicker. Click here for more details.

 

Area of review	Req’ts	Area of review	Req’ts
General requirements	57	Change Management	75
Implementation Support	19	Release & Deployment Management	86
Business Relationship Management	23	Service Validation & Testing	37
Demand Management	68	Knowledge Management	78
Financial Management	56	Service Asset & Configuration Management	85
Availability Management	50	Incident Management	83
Capacity Management	44	Event Management	35
IT Service Continuity Management	62	Request Management	42
Service Level Management	45	Problem Management	78
Supplier Management	40	Continual Service Improvement	41
Service Catalogue Management	25	Service Reporting	33
		Project Management	29

 

When gathering individual requirements, it is important to highlight those that are ‘must haves’ or ‘nice to haves’. This can help later on if compromises have to be discussed when making a final toolset decision. When Fox IT meet with a client to discuss their individual requirements, each one is gauged based on the following criteria:

1. – Low importance
2. – Moderate importance
3. – High importance

These marks help to drive a weighting mechanism to the evaluation and enables the consultant to easily identify those ‘must haves’ and ‘nice to haves’, and the scoring mechanism is also utilised to facilitate a weighting system that is used to determine how well one toolset versus another supports a set of requirements.

Also, as mentioned when determining a toolset strategy, if business functions need to be supported (such as Human Resources or Facilities), then additional requirements should be gathered for these specific areas as well.

The exercise also helps clarify thoughts on functional priorities for inclusion in any phased toolset implementation and what could be possibly ‘parked’ for future enhancement.

Vendor Selection
There are obviously a multitude of ITSM toolset vendors in the marketplace, but it is usual to only engage with a subset of these when beginning the selection process. This subset should be determined by the strategy that was determined earlier – not just the vendor’s marketing material!

• Did you decide on (for example) a SaaS or On-Premise solution?
• Do you want to engage with a mature vendor or are you open to the latest ‘upstart’?
• Are you happy to engage with a company based overseas or would you prefer a locally-based vendor?
• Does PinkVERIFY™ come into the equation?
• Does a rating on Forrester’s WaveTM or Gartner’s Magic Quadrant need to be taken into consideration?

Other possible factors that may also come into play include:

• Political (e.g. strategic partnerships).
• Mergers and Acquisitions (e.g. ITSM technology solutions that are already in use).
• Recommendations (e.g. by C-Level managers with experience of a toolset elsewhere!).

All of the above can be used to produce a shortlist of vendors with whom to engage.

Once there is a shortlist in place, each vendor should be requested to provide details on how well (or not) their solution meets the organisation’s stated requirements. Again, Fox IT’s FoxSELECT™ tool takes this one step further and vendors are asked to rate individual requirements based on the following scale:

• 0 – No support at all
• 1 – Little support
• 2 – Moderate support
• 3 – Full Support

Taking these into account alongside the ‘must haves’ and ‘nice to haves’, provides the capability when analysing the results to determine an overall rating on how well a particular toolset supports the defined requirements.

Some of the other items that a vendor should provide details on will include:

• Costs – including set-up, on-going, and licensing model
• The future development roadmap for the toolset
• Upgrade mechanisms (how easy or complex, speed to market of changes, etc.)

Selecting the Most Appropriate Toolset
Only once all of the information from the vendors has been collated should a decision be made on which solution to select. Having all of the data available from the steps outlined so far, enables an informed decision to be made based on the following principle:

Strategy vs. Functional Requirements vs. Cost

Taking all three into consideration will ensure that the most appropriate toolset is selected based on all of the available factors and the information that has been collated. It may be, for example, that a vendor meets all of the requirements but costs too much. So there may have to be some compromise on functionality in order to remain within any budgetary constraints – but at least you have the data with which to make that informed decision.

Next Steps
Before heading off straight into an implementation activity, organisations should first take a step back and look at their processes and how they want the ITSM toolset to support those processes. Remember, the technology should support the organisation’s processes, not dictate them!

The next article paper in this series will take a look at defining a new process (or reviewing and refining an existing one) and then capturing the specific functional requirements of the selected toolset to support the operation of that process. The paper will also look at when to compromise – either with the process or the functionality.

Summary
Selecting an ITSM toolset is a big decision-making exercise, and needs to be given suitable thought and consideration to ensure that the chosen solution will serve the long-term interests of IT and the Business.

Want to speak to a Fox IT consultant today? Contact us now →