Available for Consulting

Need a job? I might be able to help you find one. Need help? I'm available for consulting engagements. Send me an e-mail. Or you can contact me via Google+ or Linked In.
Showing posts with label Key Processes. Show all posts
Showing posts with label Key Processes. Show all posts

Monday, November 11, 2013

A Recap of all Critical Support Processes (Part 1)

This blog centers on Support processes which are critical. There might be more, but I've compiled a list of those which I consider key. This first part focuses on the top 10. Doing these will make your team good. The second part will cover all others. If you do those in addition, your team will be great!.

So without further delay:

Process NameDescriptionWhy you need it
Major Incident ManagementManaging issues with the appropriate communications level.This is how you fight fires.
Monitoring & AlertingIdentifying the health of your applications from a hardware, middleware and business level.This is how you identify issues with your applications.
Capacity PlanningIdentifies whether applications can handle increasing volumes.You're able to predict how volumes will affect your applications.
Problem ManagementAfter root cause analysis, this process tracks follow up actions.This is how you get proactive and prevent issues from happening again.
Change ManagementTracks all changes going into the environment.Changes bring instability.
CRMThis is how you track and manage your customer relationships.You know who to contact/tell about issues.
Stability ProjectsThese are short-term projects that help resolve recurring issues.These supplement your Problem Management program.
HandoversTeams finishing a shift transfer accountability to those on the next shift.Ensures that work is done following-the-sun.
Production TransitionsProcess to keep the Support team up to speed upon new releases.Ensures your team's application knowledge doesn't become stale.
Disaster Recovery PlanningProcess that outlines how to recover applications during a disaster.Ensures you can continue to do business during a major disaster event.

Monday, September 9, 2013

Four Key Areas your Support Team Needs Training In

Everyone knows their staff needs training, but have we given any thought into what training should entail? Let's start with answering WHAT training should entail.
There are four key areas your Production Support Staff needs to be trained on:
  1. The Application: You cannot be successful unless your Production Support staff knows the application they're supporting. You can have all the process in the world, but if your Support guys don't know the application, they won't be able to support it. I've seen very few Production Support teams who have staff training plans, especially for new hires. With the way Production Support teams are budgeted for, this is a mistake. Typically the reason you're hiring someone is because you have some urgent need: someone left or you're taking on Support for a new tool. However, if no staffing plan is in place, it'll take six months to a year, depending on the complexity of your application, before that new joiner is truly productive.
  2. Your Processes: Your team needs to know what they need to do to ensure your processes are being followed. A good portion of the posts on this blog so far have been focused on the necessary Support processes. For example, unless your team members know how to enter a ticket (and why this is necessary), they won't do it correctly. This could mean that your metric tracking will be off, as perhaps you won't have a record of key issues or all Support effort. Not following correct change management process could mean a botched release, or even worse, some really uncomfortable meetings with auditors.
  3. Your Releases: Just because someone knows the application, doesn't mean they know all about the new features being pumped into it with every release. You can consider initial Application training to be more like you providing your staff member a snapshot of it. But keep in mind that the Application will continue to evolve.
  4. Your Stakeholders: Again, we Support a business. Support staff need to know who their business is, who the key players are and how it's organized. What things are urgent to the business should also be covered.

Now, let me provide you some ideas into HOW you can train your staff.

In the simplest case, put together a list of topics starting with an architectural overview of the application, moving into the key areas of the app and concluding with who the business is (and how they're organized). Use that as a template to put together a PowerPoint deck that will cover key highlights of each topic and have one of your staff members provide an overview to any new staff arriving.

In order to make the process more efficient, as you cover the slides, do it in a tool like Webex. Use Webex to record the session and the information being presented. Now, you'll be able to distribute that out to new staff without the need for a presenter.

For your processes, you can do more scenario-based type training. For example, you could use some of your previous incidents to come up with a scenario to train people in your Incident Management process. You can try to mimic the situation and allow the person being trained to explain what they would do to resolve the issue. It's important that this be detailed enough to determine gaps and provide suggestions for improvement.

Finally, for releases, it's important that your team has a forum with the Development team, for at least an hour, if not more. At a basic level you can go through the release notes and have a Q&A session. Ideally, however, your Development staff is coming up with more polished training decks that they want to cover with you for every release. Find a way to get buy-in from your Development team to ensure that if there is no training they will have to help you support any issues related to new features. At least have them understand that you will fire call them (in the middle of the night, if needed) if they don't train you.

In any case, never underestimate the need to train your staff. There is nothing more discouraging to a Support team than having someone who cannot contribute to the Support effort. There's also nothing more frustrating for a Support analyst than not being able to help. So, you have to give all your team members a fighting chance at success.

Tuesday, August 6, 2013

The 6 Managements of Prod Support

There are many processes that support teams must follow. But if you can do these 6 things correctly, you'll have a solid base to build on as a Prod Support group:

Application Health Management: This is also known as Monitoring and Alerting. At any given point, the support staff needs to know how the application is doing and taking proactive measures to ensure continued availability. At the low end of the spectrum, this can be done by sending e-mail alerts when something isn't right in the environment. A more ideal solution is to develop graphical dashboards that provide a Red/Amber/Green status for the various components of the application.

Capacity Management: This is also known as Capacity Planning. Capacity Planning goes hand-in-hand with Application Health Management. By being able to correlate Key Performance Indicators in the hardware and software with transactional volume, a Prod Support team can know how stable an application will be during periods of high volume.

Change Management: Many, if not most, of the problems arising in Production, from my experience, can be traced to changes in the environment. Whether it's a botched release or someone fat-fingering an IP address in a configuration file, changes expose applications to instability. Managing who can make changes and how those changes are done can significantly help application availability.

Incident Management: Things will go wrong. Otherwise, there would be no Production Support teams to worry about availability. When things do go wrong, a speedy recovery focused on service restoral is critical to mitigate impact to business users.

Problem Management: This is how stability improves. Incident Management should logically segway into Problem Management. If Incident Management answers the question of how service will be restored, Problem Management answers the question of how the outage will be prevented from recurring.

Customer Relationship Management: Production Suppor teams should be intimately aware of who their stakeholders are and how to communicate with them. A solid documentation set describing how system outages affect stakeholders and how to contact them, enables Production Support teams to prioritize recovery steps. It also helps contact business users to let them know an issue has occurred, so that business users can execute workaround steps if needed.

Underlying all these processes is Staff Training as well as Metrics and Reporting.

Why training? You can have all the process in the world, but unless the support staff is knowledgeable about their application and how to apply those processes, they won't be effective.

Metrics and Reporting, on the other hand, is how you track that each of these processes is being followed. With metrics you identify improvement areas for the entire team and the suite of applications they support.