Most enterprise IT departments seem to guide the success metrics for any software deployment by how their helpdesk staff lives through the exercise.
You want them to appreciate you, so include them not only in pilot teams, but include some success metrics for the number and type of tickets you expect them to handle and still call this deployment a success.
Consider the following categories of trouble tickets as examples (with accompanying possibilities for metrics on each and estimated time to resolve):
•
Conflict with other software— Metric: Medium caseload.
— Average time to resolve: Short (depending on complexity of policy changes needed to resolve issue).
— What is this: This could be as simple as a query that CSA presents to users when they start their software packages, or as complex as a conflict between another software package and CSA. This conflict could arise when CSA or the software package presents an error or does not start (although the latter is rare, it does happen but there are ways to quickly work around it).
•
Feature Request— Metric: Low caseload.
— Average time to resolve: Short-to-long (short for simple policy updates or changes to your deployment, long for product suggestions that need development time from Cisco).
— What is this: Everyone has their own opinions on how software should look, react, and behave in this environment. Set aside something to gather up requests for changes to your deployment of CSA, or to the product itself, and handle them appropriately.
•
Policy Modification Request— Metric: High caseload in the beginning, lowering over time as things settle in.
— Average time to resolve: The time is usually brief but it depends, of course, on the complexity of the change requested, and the level of CSA policy development understanding by the administrator. It could be long if you end up arguing over the business versus nonbusiness aspects. Or the time could
be too long, in which case you should help yourself and your helpdesk staff.
Have good definitions of what software is required for business in contrast to software used for nonbusiness (personal) purposes. You should then set your users’ expectations accordingly, based on those definitions—how long can they expect to wait for an answer to a question about business software issues versus personal software issues?
— What is this: This is the bucket for all requests for changes to your CSA policies whether the request is due to conflicts that cause undue headaches or just changes to make things run more smoothly. Expect quite a few of these up front if your environment is diverse, but they will settle over a short period of time as users become accustomed to your policies.
NOTE To save the time of you and your helpdesk, you might want to categorize policy
modification requests as business-related and nonbusiness-related. Just be sure to clearly define what you mean by business and nonbusiness-related. For example, is Microsoft Word business-related? Are computer games business-related? You might wish to define Service Level Agreements (SLA) with your users up front to set expectations on how often business or nonbusiness policy-related changes occur.
The following looks at an example to clarify the preceding discussion. You could define rules for handling business-related changes as follows:
• Impacting changes (meaning changes that stop the business from operating normally) are analyzed and handled within one business day of receipt.
• Normal business-related policy changes that do not immediately impact users but are perhaps annoying are analyzed and handled within one week.
• Nonbusiness-related policy changes within one business quarter (they do deserve an answer eventually).
•
CSA Questions— Metric: High caseload in the beginning, lowering over time as users become accustomed to the presence of CSA.
— Average time to resolve: Very short—if you do your homework ahead of time and write up those frequently asked questions for your staff and the helpdesk groups.
— What is this: At first glance, this seems to be a catch-all category. However, the better you write your documentation and train your staff before the deployment, the quicker they can answer questions and cases in this category.
Pre-Planning 55
NOTE Frequently Asked Questions (FAQ) web pages or e-mailed documentation can help the most. Users who work with CSA for the first time need to understand why you are installing it. They ask themselves this question: What benefits do I get as a user for the pleasure of installing another software package on my desktop? They also need to be aware that in most configurations, they will see popup queries and messages from CSA. The more prepared they are for these popups and messages and the better they understand how to use CSA to secure their machines in the most unintrusive way, the happier they are.
•
Installation/Uninstallation Questions— Metric: Shoot for a low caseload in this category, although installation at most sites proves to amount to medium caseloads.
— Average time to resolve: Medium to long. These issues usually are not resolved in five minutes. It takes a bit of log file reading, and perhaps some reading of CSA documentation ahead of time to help develop instructions on how to resolve these issues. They are handled quicker over time as your helpdesk staff becomes more comfortable with issues and possible resolutions. Again, develop documentation early in the process and keep it up-to-date as you discover new things in your pilot.
— What is this: This is the category for all installation and uninstallation questions about CSA (yes, sometimes users have an issue and need to uninstall or reinstall). Hopefully, with good piloting and quality assurance testing, this category will have a low caseload. Good documentation for your helpdesk and technical staff is the key to keeping this as
straightforward as possible. Cisco has documentation available on http://www.cisco.com that can assist you in developing break-fix
documentation, which outlines what happens when there are problems with the installation programs and you need to manually uninstall CSA. The document outlines the steps you need to take.
The preceding list has outlined nurmerous possible categories to help you develop topics for both helpdesk cases and metrics to measure them by. You need to decide what makes sense for your environment as far as an acceptable SLA for each of these categories. If you have a medium-to-large site, you likely have similar categories worked out for other software packages and do not have to reinvent the wheel here. In this case, you can use the preceding list as primary categories to work from and develop your categories and metrics based on them. The better you develop these categories ahead of time, the easier it is to develop case metrics to measure the comparative difficulty of installing and operating various software packages.
Typically, customers who install CSA in their enterprise have found graphics and office document-handling packages to be more helpdesk-intensive than CSA.