Establishing a Successful Support Arrangement – 4 Key Process Steps

Custom application support arrangements these days seems to share the following characteristics:

1. Highly commoditized with high offshore ratios
2. Poor levels of quality and meeting Service Level Agreements

To some, the first would seem to beget the second. Specifically – IT organizations have seemed to come to almost expect very little from their on-call support other than having a warm body pick up the phone or call back in the specified time.

But commoditizing a service doesn’t imply that the service has to lack quality. To break out of the quality trap without breaking the bank, simply requires a higher degree of process rigor, constant improvement and repeatability. These things are necessary because unlike a development project – where creativity and innovation are built into the fabric of the team, on-going support efforts typically run best when everyone operates in a consistent manner day after night after day.

To emphasize this point – in a 24×7 scenario, you want to make sure that the team member resolving an incident at 3pm EDT will operate in the same way a different team member working on an incident at 3am on the eve of a holiday (EDT). The operational fact that both resources may be working on different shifts and even different continents should be transparent to the customer. And this degree of consistency demands rigor and repeatability.

For this reason, support arrangements need to adequately prepare and mobilize prior to ‘opening the phone lines’ so to speak. A typical process from initial assessment to launch looks something like this:

Figure 1 – Steps 1, 2 & 3

These processes define the first 3 ‘key steps’ to launching a successful support arrangement.

Notice that before we jump into support, some necessary infrastructure and process needs to be adequately defined. Without this, support organizations rely too much on individual heroics. And while heroics are certainly admirable qualities for team members to possess, they should be called on infrequently and certainly not relied on to provide consistent on-going support services.

Choosing a Global Software Development Partner to Accelerate Your Digital Strategy

To be successful and outpace the competition, you need a software development partner that excels in exactly the type of digital projects you are now faced with accelerating, and in the most cost effective and optimized way possible.

Get the Guide

Of course, some customers may want to jump right into the launch phase with a very short ‘pilot phase’. In some rare cases, the proper infrastructure may already be in place and this is appropriate. Here’s a sample checklist of common deliverables from the second step as a quality gate to enter into a pilot phase. If both customer and provider feels that all of these are in a sufficiently defined state, then by all means, jump ahead to the pilot phase.

Operational M&Ps (based on ITIL guidelines)

• Incident reporting
• Incident response
• Prioritization
• Incident tracking
• Resolution (synopsis/root cause analysis)
• Escalation and collaboration
• Reporting and measurements (daily, weekly, monthly)
• Proactive monitoring
• Release support
• Post resolution knowledge capture
• Post resolution improvements (scripting, proactive monitoring, etc.)
• On-going problem management and resolution

Baseline SLA’s

• Documented severity definitions and criteria
• Hours of operation, call back, updates, time to resolution, % compliance

Knowledge Management (KM)

• Establish repository
• Baseline assets (design docs, user guides, trouble-shooting guides, contact matrix, technology guides, etc.)
• Update / management processes

Connectivity / Tools

• Connection and security requirements, bandwidth, communication tools, etc.

Pilot and Launch Schedule and Sign-off criteria

• Detailed schedule, with key milestones and go-no-go decision points / criteria

On-going support SOW

• Go-forward ‘contractual’ arrangement concretely defining committed SLA’s, exceptions and financial tie-backs to metrics as appropriate

The above just represents a high level description of each deliverable. It would consume a considerable amount of time to talk through the sign-off criteria for each check-list item above, but you can almost write it yourself by considering the previously cross-shore scenario as a litmus test to completeness of any deliverable above.

The third process step is termed a ‘pilot’ – however, for all practical purposes, the pilot is indistinguishable from on-going support with the following exceptions:

1. The initial first few weeks are ‘bumpy’ as processes and the organization ‘gel’. This doesn’t just apply to support team members, but also to the users and collaborators (tier I, tier II, managers, etc.) that tether the support offering to the overall IT organization. During this time, an extra margin of error is expected with regard to meeting SLA’s. Some missed SLA’s are ‘forgiven’ with regard to consequences and back-up plans remain in place (with an emphasis on escalation) from a contingency perspective.
2. Because of #1 – support hours during this period are often ‘discounted’ as efficiency gains traction and the organization starts to ‘hum’

There are benefits to both the customer and vendor to make this pilot period as short as possible. But there are also consequences to both if the pilot is rushed to launch. Generally, it’s not that big of an issue to have both agree when the organization is truly ready. This can be as short as two (2) weeks or as long as eight (8) weeks. Four (4) weeks is typical and should be the baseline expectation.

The final step is not a ‘step’ at all, but rather a key requirement of on-going support. In the fourth step, we are applying a high degree of rigor and review to generated support metrics and using these metrics to ensure constant improvement.  Through reporting and dash-boarding, support quality remains front-and-center to the discussion.

One final key thought with regard to ensuring a high degree of quality to support. Part of ensuring quality is dependent on proper distribution of roles and responsibilities between the various support tiers. For example – Tier II support is not a replacement for having key development team members on call to trouble-shoot particularly troublesome code related issues – especially those issues that may have slipped to production due to inadequate testing / QA of the application. Well tested applications are well suited to tiered support models. Poorly tested applications will generally result in continued escalation to tier III development team members (causing frustration on all team members).

Part of initial piloting as well as on-going metrics monitoring should be to focus on application stability – especially after new releases or rushed ‘hot-fixes’. Planning additional tier III escalations post a particularly complex release will avoid the situation of confusion and 3 hour ‘SWAT’ resolution calls with all hands on deck.

That’s all for now – happy to talk more if anyone has questions or comments!