Bare Necessities for Success in Production Support

After coming back to India of late, I have developed this interest to play Table Tennis at the recreation room of my work facility. I always land playing a game against the pros, at the end of which I end up loosing. On pondering over my loss, I concluded that these pros were playing “Table Tennis” while I was just trying to keep the ball back on the table, but without any strategy.

I would like to draw an analogy of this reference with Production Support Management for software applications.

Just as any player would concentrate on the game with a strategy behind his moves, we need to check if our support teams are simply solving issues as they get them (like I play table tennis) or are they really servicing the customer with a strategy to ensure that they do not get this issue again.

When I talk of a strategy to succeed in Production Support the five key ingredients that I can think of are:

1. Fixing Issues at the Root.
2. Proper Communication Channel (within teams)
3. Support Artifacts
4. Infrastructure & Monitoring
5. Customer Satisfaction.

I am keeping “Customer satisfaction” at the bottom of my list because if we are able to force a compliance on the first four attributes then that would in turn ensure Customer Satisfaction as the end product.

1) Fixing Issues at the Root.

‘Every ticket that is hurled at the Production support team to look at, arises due to a cause behind the same’

Allow me to explain this with an example:

There was an instance when a monthly report execution failed, as there were multiple hung processes on the server executing these reports. The instinct to provide an immediate addressal to this issue would tell me to simply kill the hung processes and get going with the reports. However in doing so, I would miss the ‘big picture’ in understanding the activities on the server that led to hung processes.

Having given the above example I would like to highlight that it is equally important to understand the root cause behind any request and fix it at the origin (on priority). Doing this would avoid the resurgence of similar issues in future and would simultaneously improve the health of the application.

However to do so it is required to have proper development procedures in place, to take on the fixes arising due to root cause identification. This defined process in any organization needs to be flexible enough to absorb such adhoc development requests, as prioritizing these fixes can get chaotic at times. (May be I would comment more on this subject in my following Blog).

2) Communication

The support structure of an organization depends whether the software growth in that firm has been organic or inorganic. An inorganic growth will only add to multiple layers being identified in support with multiple teams supporting various modules of an application. However it would be ideal to flatten this structure. Multiple layers of hierarchy in support would only add to complications. This would lead to tickets bouncing back and forth between various support teams and in turn agonizing the end user.

I would say it is rather impossible to have a completely flat support structure in any organization. Given this fact, communication plays a major role for success stories in support. Below listed are a few pointers we need to consider wrt communication.

• Communication between internal support teams to be complete and crisp.
• All support TMs should have a list of who’s who in different support teams.
• All teams should have the latest updates regarding scope of work of different support teams
• List of SMEs pertaining to the application.
• User should always be in loop in case of multiple teams handling an issue. Also the user should have a single point of contact in such cases.

3) Support Artifacts

What are the basic artifacts that a support team will need to run the daily show? This depends on the application complexity and the technologies involved. The right proportion of technical and functional documentation required should be a call of the support team. But what every support team could document is a FAQ Document or a learning document that would encrypt the procedure to resolve frequently occurring tickets of similar nature.

Apart from these, a support team should always have the list of Upstream and Downstream application wrt the system they support. The list of users tagged to the applications would prove to be an added bonus.

The support teams need to ensure that all documentation consumed by the team are stored at a central location accessible to other teams as well.

4) Infrastructure & Monitoring

Application monitoring by all means has to be proactive rather than reactive. This would help the support team to jump to issues and fix them even before the users get to know of them. A novel idea that I heard in one of the discussions was to have a dependency GRID for software products. A dependency grid illustrates which servers host which databases, and then which databases are used by which applications, and finally the names, numbers, and email groups of the business users that are affected by that server/database failure. If any of the components in the defined Grid fails then all corresponding impacted components turn RED. This will enable your team to proactively manage your customers expectations. There are tools available in the market that offer this kind of feature.

Apart from this infrastructure management plays a crucial role in the support structure of an organization. It would be advisable to have a dedicated team focus on the health (performance included) and maintenance of servers.

And as stated earlier, Customer Satisfaction which would be the to the success of any production support team can be achieved by effective blending of the 4 key attributes discussed earlier.

So, think about it…is your Software Production Support team playing table tennis as champions do (with strategy), or are they just trying to keep the ball back on the table?