Gaining buy-in to develop an effective Operational Support Model

In our last blog we discussed how validating Business and Release Readiness can make or break project success. Which is why the team here at Tribal has worked with customers to develop a best practice readiness validation tool. Used effectively, this tool is proven to:

• save time – it comes with pre-populated categories and criteria based on industry best practice
• give earlier oversight of potential gaps and risks to go-live
• give assurance that all items have been reviewed
• present accurate information to governance groups to enable a go-live decision
• help the Project Manager understand who needs to know what and when.

Using the tool, you may have validated that you are ready for go-live, but does this mean you are ready for BAU? Development of an operational support team is covered in the Release Readiness process. However, identifying an appropriate model and getting approval of the resources required can be a significant undertaking and should start early in the delivery phase. 

We commonly find in software implementations that the existing system has been under invested in – meaning the ability of the solution to meet current market demands and strategic outcomes have, over time, drifted apart.  To minimise this ‘strategic drift’ the new solution will require a well-resourced and skilled BAU team to be put in place.  A case for this level of investment can be a difficult sell when the business case for implementing the new system is likely to have been built on reductions to staff numbers and not growing team sizes. A case should be made to retain the skills developed during the project into a BAU team that can continue configuring and optimising the system for future business needs.

In addition to obtaining buy-in for this investment, the project will need to make decisions around the type of operational support model that best fits the institution.  The first decision that needs to be made is:

• Is the operational support model designed to best handle changes through transition and continuous improvement phases? Or
• Is it a support model for ‘operational’ incidents and problems?

Specifically the SITS:Vision solution requires changes by people with functional area expertise, so the model needs to address:

• How to manage changes so they are appropriately assessed, controlled and tested; and
• Where the first point of call should be to provide best service to users.

There are three models we most commonly see, each of which has their respective advantages and disadvantages.

1. Conventional ERP support operation – Central IT/ICT Service Desk with application support knowledge within IT/ICT. Here there is a single responsible group enabling ease of communication and resource/task allocation.  However, application support knowledge is not associated with the business function, making it difficult to assess the impact of changes made.
2. Business focused – Dedicated application support function. In this model support is routed most quickly to the appropriate resources that can make the change, but it creates another service desk within the institution requiring division of responsibilities and the possibility of grey areas.
3. Hybrid – Central IT/ICT Service Desk performs triage and directs appropriately to either application or ICT/IT support. Here we have the benefit of a single service desk with those responsible for making transitional changes working alongside the support operation. Again, in this model division of responsibilities is required and there can be a higher possibility of incorrectly routed incidents than the other models.

In our experience the hybrid model is the most commonly implemented approach, bringing together the benefit of a single service desk but appreciating the need for a specific business focused application support team.  But there are things to be weary of.  Pre-existing ‘silo’ mentality in the units has the potential to turn the handover of issues for further investigation, into more of a grenade throwing exercise. Co-location can help avoid that.

The other thing that can be missed, or perhaps ends up sat on the periphery is Training. It’s not uncommon to see the training team/person as a key individual during implementation, but post go-live they’ve been edged further out of the core. They then play second fiddle to the operational support team and are on a constant catchup rather than working with them. The knock on is they are less informed, potentially leading to unclear or inaccurate training, leading to further support calls…and repeat.

So the key learnings…

• Start the conversation and business case early to support the resourcing of your BAU application support team – don’t wait until experienced project resources have found other options.
• Decide on the support model and work closely with ICT/IT support to have a clear understanding of divisions of responsibilities.
• And ensure your Training resources are effectively integrated into your support model so they can have the greatest impact.