Saturday, January 31, 2015

What To Do with Unsolvable Problems

What To Do with Unsolvable Problems

Solving problems can be a very rewarding job. Few things beat the feeling of accomplishment after getting rid of a particularly nasty problem, causing lots of incidents over a long period of time. There are times, however, when countless hours spent on analysis seem to go to waste. Either you do not have a solution, or you have it, but it is unlikely it will ever be implemented.

Such situations can happen if a problem of low impact for example. Few incidents that happen do not warrant continuation of analysis due to costs involved. Another example would be a problem turned to known error -- with identified root cause and a workaround. It could potentially stay that way for a long time if the workaround is cheap to implement and sustain and the permanent solution - expensive.

So what to do with your problems? You do not want your Problem Management KPIs to start degrading by keeping the problem open of too long. There are a couple of ways to handle it. One way, which I personally do not prefer, is to close the problem. Some organizations do it, but I feel it is like swiping your dust under the carpet. The problem does not disappear because you close it. You just lose visibility of it.

Another approach would be to keep the problem open. This way you have the visibility, but the issue is, that you will continue to come back to this problem much too often. You will get frustrated with your lack of ability to resolve it. You will also get frustrated that it influences your KPIs and you have to explain why that is on every single meeting with the management.

So, there is a third way. Create an additional status for problems which are not resolved, but which you deliberately have stopped working on. Call it a "dead end" for example. This way, you clearly differentiate between solved problems and those "put in the fridge". You may choose to revisit your hibernated problems in half a year, or even later. You will have an easy way of filtering them out from the rest. You will also be able to exclude the dead-end problems from your ongoing reporting of problems in progress.

Successful Problem Management

Successful Problem Management

  1. Find a motivated person, eager to take on the challenge. Or become that person.
  2. Organize weekly meetings to review progress.
  3. Don't limit Problem Management to root-cause analysis only. Own problems end-to-end, until final change installation and problem resolution.
  4. Follow up on overdue changes which solve your problems. Get them implemented.
  5. Publicly announce next steps, owners and deadlines. That includes your next steps.
  6. Think of yourself as a detective.
  7. Become best friends with your Service Desk people.
  8. Become friends with everyone else in IT.
  9. Get expert help for root cause analysis.
  10. Learn from results of root-cause analysis. Relate facts quickly.
  11. Research other ways to analyze problems for root causes. Become better at what you do.
  12. Provide feedback on quality of incident records.. Be constructive and get your point across.
  13. Don't put off your work. You will never get it done this way.
  14. The root cause can be a human error. Be persistent, but sensitive.
  15. Learn how to approach people. Don't get them defensive.
  16. Get a soft-skill training course. It will make the previous point easier.
  17. Go beyond your job description. Be willing to do something extra.
  18. Solve problems, don't just identify them. That should be obvious.
  19. Be concerned when you have too few problems.
  20. Form a Problem Management Community. Share experience and best practices.
  21. Organize a training course for prospective Problem Managers. Teach them or hire someone to do it.
  22. Set some time off for quality RCA. Don't interrupt yourself.
  23. Deal with unsolvable problems gracefully.
  24. Get involved in major incidents.
  25. Deliver quality reports of your work.
  26. Become a role model. Make others aspire to become Problem Managers.
  27. Elevate the status of Problem Management on IT career path in your organization.
  28. Be mindful of time. Use it to its full potential.
  29. Quality analysis over hasty and inaccurate results.
  30. Use good tools to aid your work. ITSM Software actually helps a lot in this case.
  31. Learn enough about your technology to understand reports of your specialists.
  32. Don't be discouraged by setbacks.
  33. Keep asking "why" until you get a satisfactory answer. Most likely you will not have to ask more than 5 times.

Problem Management KPIs

Problem Management KPIs

Measuring effectiveness of the problem management process can be a challenging task at times. This is because you often do not have enough data if your other processes are not mature enough. Also, expectations of senior management can push you to the limits of your analytical skills. For example, what would you do if you had to provide the "number of incidents prevented last month due to problems solved"? I am sure you see my point.


Here are the problem management performance indicators, which I find useful:
  • number of problems registered,
  • number of problems solved,
  • number and percentage of problems with root cause identified,
  • number and percentage of problems with workaround available,
  • average age of a problem, per business impact,
  • percentage of incidents related to (caused by) problems in relation to all incidents in a particular time period,
  • update frequency of open problems.
Update frequency is the KPI I like a lot, especially in the early stages of Problem Management implementation. It shows the regularity of work performed by Problem Analysts. In order for the process to be effective, work on it must not be put away forever. It tends to happen if you have your people doing other, more time-pressing activities in parallel. Many businesses cannot afford the luxury of having dedicated Problem Analysts and/or Problem Managers. Since Problem Management puts more focus on quality of analysis than the time of its completion, you might have issues with people focusing on the job if you don't have a KPI to monitor it.

The above KPIs should be looked at collectively to determine the quality of your Problem Management activities. You should be concerned if you open few problems the way the police should be concerned if they detect few crimes. They are there, the question is if you can detect them or not. You should also react if any other KPI starts deviate significantly towards its highs or lows. Frequently, if that happens, you can get an idea of what is going on by looking at the other KPIs. Few problems solved? Check your problem update frequency, for example.

Tip for improving all those KPIs: work closely with your Service Desk. After all, they feed you data. Good incident registration process is key for subsequent  root-cause analysis.

Pitfalls of KPI Reporting

Pitfalls of KPI Reporting

Everyone in the business of IT Service Management is measured by a set of KPIs. People's performance is measured this way, process efficiency as well. There are some common pitfalls of reporting that you should be aware of and try to avoid.

Inconsistency

The need for reporting in many companies drives every department to prepare a set of reports showing their performance. Problems arise when those reports are produced in isolation. Different layouts, which make it difficult to compare results, are a minor problem if you take a look at other inconsistencies.

Various departments may have their own set of criteria for data selection, which makes comparison of results impossible. What happens if various departments need to provide the single version of truth to senior management? Numerous reporting consolidation sessions take place, taking away time from other important activities.

It would be much easier to drive consistency on a regular basis, wouldn't it? Establish certain ground rules between teams and follow them.

Manual Effort

The hunger for data can grow so large, that it will eventually exceed the capabilities of standard reporting available within the company. People will begin dumping data from databases to spreadsheets and manipulate it in every possible way.

This becomes purely individual effort. The company may even fund Excel trainings to make the users more "advanced". Long live excel macros. The effort is very solitary, isolated in various parts of the company. No integrated reporting, no consolidated requirement gathering. Report generation is very labor-intensive.

That is expensive, but it does not seem so at first glance. Having a good reporting tool seems to be an unnecessary overhead. In reality, the reverse is true in many cases. Also, manual process drives further inconsistency.

Impact on System Performance

There is a direct correlation between lack of good reporting solutions and number of performance incidents in transactional systems. The more your organization relies on reporting directly from the live databases, the more incidents you are going to get. The more distributed and ad hoc the reporting, the less stable are your systems.

Do you still consider a good reporting solution (and a process) a "nice to have" requirement? Well, think twice. There are companies which have reclassified some of their reporting systems as mission critical. The management needs data to make vital day-to-day decisions. Apparently, sometimes it is as important as having the sales system up and running.

While normally KPI reporting is not a mission critical activity, it can impact your organization more than you think if done incorrectly.

SLA - The challenges of managing SLA's ( Service Level Agreements)

The challenges of managing SLA's ( Service Level Agreements)

Service Level Agreements (SLA’s) are fundamental to effective service provision. They provide the basis for managing the relationship between the service provider and the customer, describing the agreement between the service provider and customer for the service to be delivered, including how the service is to be measured. Basically, SLAs are intended to ensure the provider understands what they are supposed to deliver, the customer knows what to expect, and both can see (empirically) what is actually being delivered.
Regrettably, the ‘agreement’ role of the SLA is lost in many organisations, where SLA’s are used as ‘weapons’ to defend or challenge the provider or customer. The emphasis for SLAs must be on agreement, and the SLA should not be used to hold either side to ransom. A true partnership should be developed between the IT service provider and the customer, enabling a collaborative approach to quality improvement.
Metrics and Key Performance Indicators (KPI) are a core element of an SLA. Ineffective or absent KPI can cause a service to fall into disrepute and a blame culture can develop. KPI for the service must accurately reflect the expectations and perceptions of both the customer and service provider.
To manage service provision, we need:
  • Service metrics which reflect the end-to-end quality of service or ‘user experience’
  • Process metrics to inform the service provider and customer of the effectiveness (achieving goals) and efficiency (use of resources) of key activities within the service delivery function.
  • Technology metrics to inform the IT provider at the component level, enabling the identification of issues and improvement opportunities
When considering SLA KPI we must recognise that Customer perceptions are influenced by:
  • Attributes of service that are indicators of value e.g. relative performance, reliability or security of a remote workspace service
  • Present or prior experience of similar attributes
  • Relative endowment of competitors and other peers i.e. what they have
  • Customers self image or actual position in market (innovator, market leader, risk taker) i.e. do I expect leading edge solutions or accept / expect robust security requirements to access the service
When considering KPI from an IT perspective, we need to recognise that the customer is not excessively concerned with how the provider delivers the service and, as such, is NOT interested in visibility of the majority of KPI which the IT provider uses to manage the service e.g. component performance. On this basis, component and process KPI should not be included in the SLA. They are primarily articulated in Operational Level Agreements and Underpinning Contracts which underpin the SLA. Obviously, certain process KPI will overlap with customer expectations for the service e.g. “95% of incident which impacts more than 50 people in the organisation will be resolved within 4 hours” – customer expectation and Incident Management effectiveness KPI.
We also needs to consider the inclusion of Objective KPI (number of major incidents in a month) and Subjective KPI (Improvements in customer satisfaction).
Finally, we need to consider any scope or constraint measurements that may be required to provide context for current service levels. For example, incident resolution targets or service performance targets may be defined in the context of the number of user of the services (up to 500 concurrent users). In this case, we need to have visibility of the number of concurrent users at any time. It’s a possible discussion for another day but it is imperative that we always consider how we are going to measure each aspect of the service, before including it in the SLA. The mechanism, source and frequency of data collection, processing, analysis and reporting should be mutually agreed between the customer and IT service provider.


So, in summary:
You cannot have an SLA without measurements (KPI)
When selecting KPI, ask, what indicates value to the customer?
  • Enhanced performance in the business
  • Constraints removed from the business
  • Availability & Reliability of the Service
  • Performance of the service o Security of the service o Service Continuity (ability to recover from disaster)
Do not include IT ‘management’ KPI i.e. component & process metrics only used by IT.
  • Consider “How and how often, can I measure that?”
  • Consider Objectives and Subjective metrics
Remember scope measures that may be required for context.
Above all else, do not forget the #1 rule – Nothing should be included in an SLA unless it can be effectively monitored and measured at commonly agreed points.

SLA - Implementing Service Level Agreements - IT Service Desk

Implementing Service Level Agreements - IT Service Desk

Service Level Management is a formal way for setting customer expectations BEFORE the customer has the need to request service. It is a methodology for introducing and implementing reasonable expectations between you and the customers you support. These are most often contained in a document called a Service Level Agreement (SLA). The SLA establishes a two-way accountability for service, which is negotiated and mutually agreed upon. It is really a contract that documents operational and interpersonal relationships, establishes mutual expectations, and provides a standard to measure performance.
Without SLAs in place, you are effectively telling your customers that you will provide support to them, at any time, under any conditions, without any limitations to the systems and services they have. However, this is not the worst part. The worst part is that you cannot possibly ever meet your customers' service expectations because every customer will have a different expectation and that expectation will change every time they call.
Every day each one of us experiences the setting of expectations. The following are all examples of setting expectations: setting an appointment time, asking for a delivery time and asking for the wait time at a restaurant or car repair shop. Why should your IT support organization be any different?

The benefits of a SLA are many

  • Improves customer service. You will find that cycle times (time to resolve cases) dramatically decrease.
  • Facilitates communication. The IT service desk staff will be able to set customer expectations (i.e. your employees) in two ways. First, they can refer to the SLA document for definitions on how priorities are set and the maximum time the IT service desk has to resolve the case. Secondly, they can refer to periodic performance reports to inform customers how the support organization is actually performing. Average time to resolve is usually much less than the maximum time goal.
  • Negotiated and mutually accepted. Since customers and the support center jointly created the SLA all customers will more easily accept the SLA.
  • Documents agreements. With the SLA posted to your Intranet or in employee handouts, it becomes an "official" agreement.
  • Defines procedures. Procedures should be defined and followed by both the IT service groups and employees (i.e. your customers)
  • When there is a question or disagreement, the SLA can be used as a written reference.
  • Sets standards for customer service. This is a powerful tool. It says "Mr./Ms. Customer, this is how I am going to provide support to you and this is what you must do in order to receive my support. I am ready to be measured on how I do and I will provide everyone with a report on my performance."

Getting Started: Establishing An SLA

  1. Understand the time commitment. Do not underestimate the time and commitment involved in this process. Your entire organization needs to be committed to implementing SLAs. Once you start this process, you are clearly defining your service commitment to your customers. The creation of an SLA is not just the function of the IT service desk because it is not just an agreement between the IT service desk and customers that call there for help. Ultimately, everyone in IT supports the customer through the IT service desk. The IT service desk will not only be setting customer expectations for cases it resolves, but also for those cases elevated to 2nd and 3rd level support groups. Everyone needs to be committed to the service goals of the SLA.
  2. Understand your customers' needs. Become familiar with your customer's daily operations, processes, and business initiatives. Take time to develop a list of all services and products that require SLAs.
  3. Identify participants. Identify all the stakeholders that should participate in the IT service management process. This includes your customers, as well as any other internal/external organizations that assist the IT service desk in providing support to your customers. Be sure to include the decision-makers. While this task may seem daunting, this process is an excellent tool for building cross-departmental teams.
  4. Know your current support metrics. One of the biggest objections of those that provide service is an unwillingness to commit to service goals that cannot be met. The biggest objection of those receiving service from you is that you take too long in delivering the service. Both of these objections are based on "gut feelings." If you have actual cycle times (time to resolve cases) by severity levels, then both of these objections go away. That is the power of real numbers. If you do not have a process in place for setting severity levels for cases, it is better to postpone the start of the project until you have done this. Set up your own guidelines within your IT service desk team and then religiously assign severity levels for every case. You do not even have to tell anyone outside of the IT service desk. You will be surprised by how much informal severity level setting is already taking place. This is also a good time for a customer satisfaction survey. It will provide a baseline for measuring improvements.
  5. Team meeting. Hold a project team meeting to explain the goal and determine tasks and timelines. It is in the team meetings that many of the fears come out. If a support group says that the IT service desk cannot be accurate in setting the priorities, then ask them the following. Ask them to create a document with the types of cases they normally receive, the type of questions and documentation they need in the case and what the priorities should be by case types. This will be used to instruct the IT service desk on setting priorities. When the IT service desk does not set priorities correctly, you will want a process for notifying and training the individual who handled the case.

Gotcha! Service level management: Why it fails!


  1. Too Complex. The most common pitfall is that the SLA documents are too complex. These documents should be short and very precise in defining the services you provide and the level of service you and your customers agree on. If they are longer than 3-5 pages, then you are doing it wrong.
  2. No measurements. If you do not have the technology and tool sets to track and report the timed-service events by responsiveness and resolution for the various severity level classifications, then SLAs will fail. Without continuous feedback on performance, the loop is incomplete and the SLAs become documents and nothing more.
  3. Unrealistic management expectations. Often management does not acknowledge the amount of time needed to implement service level management, and therefore they do not staff it adequately. This cannot be a part time job! It must be managed full time.
  4. Unrealistic objectives and goals. Frequently, IT management and customers set unrealistic objectives and goals. This usually happens because there were inadequate measurements done prior to implementing the SLA. It is critical to baseline the current service performance prior to beginning to negotiate the SLAs with customers.
  5. No alignment and buy in at all levels of management. It is important that all levels within the organization understand the value of implementing a service level management culture. Without this commitment throughout the organization, it will be difficult for the line staff to understand it, want to participate in it and for the Support Center staff to enforce it.
  6. No existing Operational Level Agreements (OLA) within IT. Some organizations believe they can implement customer SLAs without first having established their own internal IT support OLAs. OLAs are basically a service level agreement between each service group. The IT service desk should have an OLA between each service department it sends cases to.
  7. Underestimating the scope. An organization implementing service level management must understand that this is a company-wide initiative. It will have impacts on staffing, technology, and the company's culture. This is NOT a project assigned only to the IT service desk.

Creating a rough draft

There are several components to an SLA. It is important that the language is familiar to your environment. Use a straw man to introduce the concept to your organization. This will help the rest of the project team understand the complexity and importance. The following is an example of the categories that should be included in your SLA. However, remember that it must be clear, well written, and easy to read and not very long.
  1. Introduction
    1. Purpose of the SLA
    2. Mission of IT (This is not just between the IT service desk and customers)
    3. Customers covered under the SLA
    4. Locations
    5. Owner of the SLA document and communications path
    6. Services covered. This is only a high level statement
  2. Service Goal
    1. Overall goal. Example: Resolve 100% of all severity level 1 and 2 cases in the timeframe specified. This is the first place that you are making a statement about what is important. You cannot be a success treating all cases equally. Level 1 and 2 are high severity level cases that directly impact the productivity of a number of customers/locations of the company. You must make sure these get done on time. Getting the others done on time is a bonus.
    2. Specific goals. List the severity levels and the time the case should be responded to and the time it should be resolved.
  3. Definition of terms. Do not assume that everyone will know what you are talking about. You need to define terms to the lowest common level. Be as specific as possible.
  4. Service delivery elements
    1. Service coverage times. State clearly what business hours are supported and what is supported after hours. Failure to do this will mean you can be called at any time of the night for the most minor of problems or requests. Be sure to consider the various time zones you cover. Keep consistent and list the time zone you are in (e.g., 7AM - 7PM EST).
    2. Environment(s) included. What do you cover? If you only support standard hardware and software, be sure to state it here.
    3. Environments excluded. If the IT service desk will take cases for non-standard hardware and will charge back costs to the customer, then list that here.
    4. Specific applications and network services coverage. List specific applications by name, the times they are supported and the times they are not supported. If there are maintenance windows for databases and servers when they will not be available, then make sure to list these windows.
    5. Methods for requesting service. For example, for all level 1 and 2 cases the request for service may be via the phone. For example, for level 3 and 4 cases the request for service shall only be via the Web.
    6. Customer responsibilities. Some examples are: How to submit a request, what standards are supported, and when customers should be available for the technician.
    7. Service tracking and reporting procedures. Some examples are: IT will log 100% of all requests, phone calls will be randomly recorded for quality and performance metrics will be posted on the web.
  5. Escalation procedures. State the escalation path and time for each severity level.
  6. Telephone, Web and Email response times. For example: Phone requests will be answered in less than 20 seconds, Web requests within 30 seconds and email within four hours.
  7. First contact resolution by the IT service desk. For example: The IT service desk will resolve at least 70% of all cases it receives.
  8. Reporting methods.
    1. Weekly management reports on the Web
    2. Monthly performance metrics on the Web
    3. Quarterly Customer Satisfaction Surveys results on the Web
  9. SLA contract period.
    1. When the current draft is effective
    2. When it will be reviewed
    3. How to request changes
  10. Examples of cases by severity level and case type.
  11. Sample of the customer satisfaction survey questions.

Obtaining IT support

If you have measured the actual case resolution times based on approximate severity levels and you have created a straw man SLA including this data, then you are ready to get the rest of IT involved.
  1. Meet with individual managers to explain how their department did on your test of priorities and response time.
  2. Explain how the SLA goals will impact how they are already doing.
  3. Use your existing allies within IT groups to prepare the way for acceptance.

Obtaining Customer support

At this stage you should have accurate performance metrics, IT support for the service levels and escalation procedures. Now you are ready to meet with customers to get their feedback. What customers should participate? As a suggestion, your most critical customers might be the best. They are great people to have in your customer task force because they really want to see IT meet their needs. They will not be afraid to give you their opinions. They will certainly question your current response time report. Their memories are long and they remember how hard it is to get the support they need to do their job. They will usually be fair. If you can get them to agree to the SLA, you can get anyone to agree. Also, it is better to get any arguments and concerns out of the way now before you go public with the SLA.

Marketing your SLA

No one likes to be surprised, including your customers. Once you have your project team working on the structure, wording and goals of the SLA, it is time to begin telling your customers about the project. You can do this while on the phone with them in the IT service desk. Another approach is to email periodic "Progress Updates" that explains the project, benefits and implementation plan. Sending these out every other week will get them prepared. They will be ready to support the SLA when it is approved.

Implementing your SLA

  1. Pre-SLA. Before you announce the SLA, practice as if you have an SLA. This includes the following: a. training the IT service desk, b. monitoring response time to ensure SLA compliance, c. resolving cases in accordance with the SLA, d. setting customer expectations, e. managing the work flow within the IT service desk and between the second level.
  2. Training the rest of IT.
    1. Weekly meetings. For the first month it is beneficial to meet regularly to find ways to improve communications and workflow, review Cycle Time Reports and exception reports.
    2. Service Group Feedback. Ask other service groups to review their cases for the proper Severity Levels. If they find discrepancies, ask them to provide a list of case types and the appropriate Severity Levels. This will be the basis for IT service desk training and documentation.
  3. Implementing within IT first.
    1. Apply appropriate Severity Levels.
    2. Escalate cases according to SLA rules.
    3. Report on performance.
  4. Send out the formal announcement to customers.
    1. Purpose of SLAs
    2. How Severity Levels are applied
    3. Responsibilities of support organization
    4. Responsibilities of customers
    5. Performance reporting

Measuring Success

Success of service level management can only be measured by reporting on what percentages of cases by Severity Level were resolved within the goals of the SLA. The reason that you want to measure each Severity Level is that it is absolutely critical to resolve high severity level cases consistently within the SLA. However, sometimes lower severity level cases can fall outside the goals. In other words, we would like to say that we resolve 100% of all Severity Level 1 cases and 90% of Severity Level 4 cases within the times stated in the SLA. Customers will appreciate the process more when they know that if they are really in trouble, there will be resources there to help them.

Checks and Balances

There is a tendency when first starting service level management to focus in on the response performance. It is easy to make the numbers look good. All you have to do is close a case within the time specified without doing anything. While this makes the numbers look good, in the end you will have customers upset. Customers do not really care about the numbers. They only want their issues taken care of to their satisfaction.
Customer Satisfaction Surveys are one way to provide checks and balances to the empirical numbers of SLA compliance reports. Another way to make sure customers are taken care of is to have a policy for re-opening a case if the customer calls in to say they are dissatisfied. You should then have a report that shows re-opened cases. Management should use this for continued training.

Periodic Surveys

Quarterly or annually a survey should be sent to all customers asking them their general opinions of the support they receive. You cannot ask for specific information when you do periodic surveys because customers only remember their last one or two incidents. Periodic surveys are not a good measurement of how your organization did for the year. Another limitation of periodic surveys is that survey responses will not be specific to each IT service desk group or person assigned the case. Customers do not really know, or care, what group handles their request. To customers they are just all part of the IT organization.

Incident Surveys

Incident surveys are surveys sent to the customer after each case is closed. The advantage to this is that you can capture perceptions immediately and you can link the feedback to both the service group and to the assignee. This is extremely valuable information because both rewards and training can be tailor-made based on the results. The disadvantage is that customers will get usually one survey a week and they might not respond with as great regularity. However, the advantages outweigh the disadvantages. Incident surveys are preferable to periodic surveys.

Conclusion

The effort to create a Service Management System is very significant. Organizations that have a system in place have higher customer and employee satisfaction ratings. After all, when every case is considered severity level one and every day is a fire drill, it is hard to enjoy your job for very long. That is why the turnover in support organizations where Service Management Systems are in place is lower than organizations where they are not. So, with higher customer and employee satisfaction, lower turnover, greater productivity and reduced cost, why would you not want to have a Service Management System guiding your organization?

SLA vs KPI: Service Level Agreements vs. Key Performance Indicators

SLA vs KPI: Service Level Agreements vs. Key Performance Indicators

What is the difference between Service Level Agreement measurements and Key Performance Indicators? Well, although sometimes they are referred to as synonyms, there are a few differences.
Service Level Agreement (SLA) is an agreement between two parties regarding a particular service. Apparently SLA must contain quantitative measurements that:
  • Represent a desired and mutually agreed state of a service
  • Provide additional boundaries of a service scope (in addition to the agreement itself)
  • Describe agreed and guaranteed minimal service performance
On the other hand Key Performance Indicators (KPIs) are metrics that target service providers organization objectives – both tactical and strategic. Usually these metrics are used to measure:
  • Efficiency and effectiveness of a service
  • Service operation status.
It should be noted that not all metrics automatically become Key Performance Indicators. KPIs must be bound to the organization or service goals and must drive continuous improvement and efficiency.
If you have many customers for a service then SLAs may vary from customer to customer; however KPIs usually are common for a service.
Let us take a few examples that outline the differences. Consider a help desk service.
  • SLA examples (for a particular customer): reaction time, resolution time, compliance to agreed deadlines
  • KPI examples (organization or service oriented): average reaction time for all customers, service desk employee load, incoming ticket volume trend, required capacity to fulfil SLA promises to customers
To sum it up – SLAs are about minimal, expected and agreed quality of a service provided to a customer; however KPIs are about desired operation efficiency and organization goals. It is important to measure both service level compliance and key performance indicators in order to keep promises and excel service quality.

SLA - 4 Basic Measurements

Four Basic Measurements

When negotiating a new outsourcing agreement, clients face the challenge of determining the service levels that are most meaningful to the business. The intent of a service level agreement (SLA) is to measure the provider’s overall performance by virtue of concise, unambiguous metrics with targeted levels of performance that are easily understandable by the client community and are simple to validate from a client’s perspective. As the outsourcing industry has matured, providers have developed a multitude of service level measures they can propose to their clients. Some are more relevant to the client’s business than others. Without the proper alignment of IT service levels to the needs of the clients’ business, companies can fall into the trap of “seeing green but feeling red,” meaning the service level measures are exceeding their targeted performance levels yet there are still IT delivery issues. Fortunately, there are several common service levels within the outsourcing marketplace that align nicely to the perception of lines of business and end users. The following four metrics serve as a guideline for defining your service level requirements.

Service Desk – In many companies the service desk is the primary touch point into IT, and therefore measuring its performance aligns nicely to the business perception of IT. For example:

First call resolution – Directly ties to the user base experience of how well the service desk is equipped to solve their problems during the initial call.
Abandonment rate – A low abandonment rate indicates users are not getting frustrated waiting for a live agent.
End-user satisfaction surveys – Collects direct user feedback on their satisfaction with help desk services.
Install/move/add/change/delete (IMAC-D) requests – Measures how well the IT organization provisions requests from the business community.

Other service desk measures, while important to the IT group, may not be as relevant from a business perspective.

Projects – Project work performed by IT is usually the work most aligned and most visible to the business. There are many types of project-related metrics, and the following is a good subset to use to communicate project performance to the business:

On-time milestone completion – The project manager, working closely with his/her business counterparts, should develop a set of key milestones as part of the overall project plan. Measuring the on-time completion of these milestones communicates the progress being made and the maturity of the project management discipline being used.
Estimating accuracy – Measuring the accuracy of estimates that are provided to the business, especially when you can show sustained improvement over time, is a great way to build credibility with the business. The estimations could be in terms of schedule, cost and/or resource utilization.

Percent of budget/cost spent on strategic projects – This is an excellent measure to communicate how IT is driving down the “lights on” costs and reallocating to work that adds tangible business value.

There may be other metrics that better reflect your environment and what’s important to your business partners. The important point is to somehow showcase the value that IT is providing towards the execution of projects that are adding business value.

Change Management – Measuring and reporting the volume and success of changes to the environment is a good way to showcase the volume of work being done by IT “behind the curtain” and to illustrate how much goes right. This can provide good “air cover” whenever a delivery issue does occur that causes pain to the business. For example:

First time successful changes – Measures the percentage of changes that are correctly implemented the first time.
Percentage of non-emergency changes – Measures overall system stability and the maturity of the organization’s change management processes.
On-time change implementation – Measures how well IT activities are planned in advance.

Change management SLAs are effective in measuring change management effectiveness and efficiency.

General – Several other measures are closely aligned with business perception. Among these are:

On-time reporting – Many business units rely on the on-time delivery of accurate reports. This can be measured by identifying the list of critical reports and defining the time at which they must be completed (and in some cases, delivered).

Problem resolution – Ironically some providers will initially balk at this, stating that there is too much out of their control to commit to targeted resolution time-frames. However many will eventually agree to resolving a certain percentage of problems within a defined time frame. This is obviously one of the most visible signs of IT performance, and is important to demonstrate that even though problems are bound to occur, they can be quickly resolved due to the resources, tools and architecture in place.

Application availability – Most providers will supply a standard service level called application availability, so the important thing is to ensure that it is a true end-to-end availability measurement that reflects the users’ experience. In other words, the metric should comprehend any IT issue that results in the application not being available to use as planned. This includes not only issues with the application itself but also the entire underlying infrastructure including the servers, databases, network and devices used to deliver the applications to the desktop.

There are literally hundreds of “typical” IT metrics that can be reported on. While true that some IT-specific metrics should be in place (especially to ensure that issues are identified and resolved prior to affecting the business community), most should have a focus squarely on measuring the delivery of services to the end users. This list, although basic in nature, provides a good framework to evaluate the service levels you are currently using or are developing as part of a negotiation.

Friday, January 30, 2015

SLA - Seven Steps to create SLA

Seven Steps To Create SLA

Define the Service

First, pick a service for which you want to create the SLA. That might be your sales application, or your logistics system. Pick the one of the most important systems in the company. Define one sentence which describes the nature of the service you provide. So, for a sales system the statement could be:

"Provision of IT sales system X to the company."


Find Out What You Can Measure

The next step is to determine what kind of service attributes can actually be measured by your team. This is a pragmatic approach. There is no point promising something, which cannot be measured and improved in a visible way. List all the parameters you can measure and prepare for discussing them with the business owner.

Identify the Business Owner

I mentioned the business owner, but how to find this person? Sometimes it is quite obvious. If a sales system is your subject, you should talk to your Sales Director. Sometimes, it might be more tricky. What if you have more than one candidate, like two Sales Directors responsible for two different sales channels? Do you talk to the General Manager? Maybe. You might also get your directors to agree and appoint one delegate manager from the team, who will represent them both. Or just talk to them both and reach a consensus.

Sometimes you might have a really hard time finding an owner. There might be cases, where ownership is deemed to reside in IT. Systems "should work" and if they don't, "IT should fix them". What's to talk about? In such situations, there are a couple of things you can do:
  • Pick another service, with more natural ownership within the business. Payroll system is a better candidate than email. You will later use it as an example in an attempt to instill more ownership within the business.
  • Consider a customer-based SLA, prepared for one particular department, but multiple services together.
  • Prepare a Service Level Standard. This is essentially an SLA provided unilaterally by you, without formal business sign off. It can be converted to an SLA later if a business owner emerges.
Define Business Needs and Metrics

Now, organize a meeting with the business owner. Present the service you want to provide and find out more about business expectations. Present the metrics which you can track, and allow the business owner to pick a few, which are crucial to business performance. Be ready to provide recommendations.

Those metrics could be really fancy, but for starters, I would recommend picking just two:
  • system availability during business hours (define what those are)
  • incident resolution time during and after business hours
If you cannot track those two, seriously consider upgrading some of your ITSM software, and for the time being propose some other relevant measures.

Prepare the SLA Document

Now you are ready to prepare the actual SLA document. Make it very brief and understandable -- not more than two pages. Bullet points are your friend. The simpler it is, the easier it is to get it implemented and improved upon later. I definitely advise to follow this rule for the first very SLA in your company.

Later on the documents tend to become more sophisticated. It goes together with the maturity of Service Level Management within the company, both on the IT side and on the business side.

Obtain Approval 

After you document is ready, hold another meeting to have it formally approved. You don't need to physically
sign it, although it has some symbolic touch to it. You could also have the approval done through email if both sides consider it a mere formality and there are no further questions to be answered.

Obtain Baseline and Set Targets

Notice that I have not mentioned any targets yet. This is because you need to measure your service for a some time (couple of months) in order to see what targets are realistic. After a set period of time, hold your first service review meeting, during which you will present results of your service provision.

On this meeting, you should also agree the minimum service levels with your business owner. Going below minimum causes your business owner's operations to suffer and should be avoided at all costs. If it happens, you should prepare and present an improvement plan on the service review meeting.

SLA - Why SLA Implementation Fail

Why SLA Implementation Fail

There comes a time where you want to take your IT maturity to the next level. So you take the challenge and decide to set up service level agreements with your business customers. Let's see what you and your partners should NOT do if you want to succeed.

You will fail in your attempts to create service-oriented organization, if you:
  1. Create the SLA, file it and never look at it again. Project completed.
  2. Look at the document, and then do nothing else. You can always say, you "have" the SLA, right?
  3. Turn the SLA into a 50-page contract, which nobody understands. Not even your lawyers.
  4. State what you can deliver comfortably and stop there, instead of asking the business what they really need.
  5. Agree to KPIs which are not achievable now or in the foreseeable future.
  6. Don't collaborate and negotiate. Argue and wrestle.
  7. Use the SLA as way to protect your back, in case IT is accused of "not delivering".
  8. Don't have a way to track and measure your KPIs
  9. Can measure your performance, but it is a tedious, manual and error-prone process.
  10. Don't build an understanding and don't obtain buy-in of your employees, both from IT and business departments.


SLA - How to Agree an SLA when There Is No Customer

How to Agree an SLA when There Is No Customer

There are situations, when it is difficult to agree an SLA because... there is nobody to talk to. There seems to be no ownership of the subject on the business side. Everyone uses the service, but nobody really feels he or she is the customer. Just users everywhere; no decision-making power. They seem to have varied and undocumented expectations and they rightfully complain when they are not met. How to avoid failure?

No Customer? How Is This Possible?

This specific problem with agreeing in SLA is mostly experienced for company-wide services. No single department feels the ownership of the business requirements. Everyone uses them, right? No department can make decisions for the rest of the company.

In theory this could be resolved on the board level. Sometimes it is. Often, however, the topic of email SLA (to use it as an example) is not the favorite subject of board meetings. For some reason, they tend to prefer sales strategy, cost control and other similar subjects. Email has to work. Order processing too. From the board perspective, all of that should be hands-off operation. Sounds familiar?

Customer Segmentation

Divide and conquer strategy has been utilized effectively throughout centuries. You do not have to become Caesar or Napoleon of ITSM, but it still has a lot of use for you. It can be applied to this situation by dividing your customers into distinct segments, and addressing them individually.

Talk to the manager of each department within your company. That is the starting point. It will help you understand what steps to take next. After that, you have two options:
  1. Service-based SLA with multiple service tiers
  2. Customer-based SLA
Service-Based SLA

This type of SLA focuses on a service (obviously). The trick in this specific situation is to build into it multiple tiers of service, e.g. gold, silver, copper. You could make them different particularly by the level of response to incidents. Knowing the requirements of all the departments, it should be possible to add additional factors that will differentiate each of the service offerings.

The next step is to agree, who within each of the departments will be eligible to each of the service levels. Each of those users should be marked appropriately in the ITSM tool. I would recommend a healthy proportion of 70-20-10.

Notice, that in this approach you define service levels and group them into standard offerings. The focus of the discussion is who is eligible to each of them, not what they are. The what has been standardized. The catch here is to have the gold service be very close to the higher end of business expectations. This way, you will make it clear that it is being offered, but only to a limited subset of the users.

Customer-Based SLA

An alternative approach would be to go for a customer-based SLA. It is focused on a particular department and addresses a group of services used there. It automatically creates clear accountability on the business side.

One clear benefit of such approach is higher level of involvement from the business side. The department head will be the sole decision maker which will make him much more interested in the results of the process. The key thing to keep in mind in this case is to focus on one SLA per department and include all relevant services in it.

SLA - Building Service Level Agreement - 5 Points

Building Service Level Agreement - 5 Points

A service level agreement (SLA) is a key component of an IT organization’s overall service level management (SLM) strategy. A good SLA functions as a communication vehicle for you and your customer(s) to manage each other’s expectations. By definition, an SLA is an agreement—not a contract. Whether you work with an IT department that is performing services for internal customers, such as a human resources department, or you’re a consultant who offers IT services to clients, your SLA should be a clear outline for those receiving services and those who are providing them.

SLAs can come in several varieties. An Enterprise SLA is an agreement between the service provider and all customers of an entire organization. A Customer SLA is an agreement between the service provider and a specific customer group of the organization. A Service SLA is an agreement between the service provider and the customers of a particular service.

Reasons that you, as an IT consultant, might advocate developing an SLA with customers include:
  • A newly implemented SLM strategy by the IT organization.
  • A new technology or product is going “live” from development or test stage.
  • Customer concerns regarding the delivery of IT services.
  • Customer desire to choose how much service they want IT to provide.

Regardless of the type of SLA you’re creating, you should include five sections: descriptions of service, service standards, duration, roles and responsibilities, and evaluation criteria.

First of two parts
In the next installment of this two-part series on SLAs, we’ll look at the five things that can derail a good service level agreement and how to correct them.

Descriptions of service
At the heart of your SLA are the services you provide. Writing specific descriptions of your services requires you to understand what you can offer your customers and affirms to your customers that you know what they need.

Service providers will often create a service catalog to make describing what they offer to their clients easier. The catalog should contain all of the services you provide, including applications, infrastructure, and other business functions.

Those of you who have not yet created a service catalog may find that the best way to begin gathering information for your catalog may be by talking with your customers—who know what systems they’re using—and your customer’s service desk, which knows what services your customers most frequently request.

One of my challenges as the SLM coordinator for my organization was explaining to my customers the relationship of the service catalog to the SLA. Since the service catalog is a separate document from your SLA, it’s important that you make them both accessible—your company’s intranet is a great place for your customers to view them.

Service standards
Once you have established the services that you’re providing, you’ll be ready to consider your standards, which would include concepts like availability and reliability as well as response and resolution times.

For example, availability should be defined within agreed-upon targets. If your customer’s normal business hours are from 7:00 A.M. to 6:00 P.M., it may be appropriate for the services you provide to support their business processes to be available during the same time.

Each of the services you provide will also have regular operating hours and scheduled time for maintenance. This information needs to be illustrated in your SLA.

You’ll also need to determine what you can offer to your customers if a disaster or emergency happens. Will you be able to provide the same hours of operation during one of these scenarios?

Other standards that you may wish to include involve response times and resolution times. Will these be the same for all of your services or will they be dependent on the business urgency and impact?

Regardless of what you decide, make sure that the IT employees who will be delivering the services to your customer have input and know at what level they are expected to perform.

Duration
Your SLA should specify when the agreement begins and expires. I mentioned that an SLA, by definition, is an agreement rather than a contract. Duration information is one concept that carries over from items you would find in a typical contract.

The start date of your SLA allows you to begin tracking IT performance on the same date (unless otherwise specified). If you’re providing a new service or simply revising the services you have been offering to your customers, allow enough time to communicate the details of the agreement to them.

Consider when your SLA will expire. When you negotiate maintenance contracts or equipment leases on behalf of your customers, you may enter long-term agreements with other service providers. Keep these facts in mind when negotiating with your customers.

For example, in an effort to keep costs low for your customer, you may have entered an 18-month lease for equipment that your customer uses. If your SLA expires after only 12 months, your customers may not be obligated to keep paying for your services and you’ll be faced with finding another way to fund the equipment lease.

Roles and responsibilities

Managing your customers’ expectations and those of IT can be tricky if you do not designate everyone’s responsibilities in your SLA. You and your customers have obligations to each other that must be well defined. Some of your customer’s responsibilities may depend on your corporate IT strategy. For example, some companies stress the importance of direct access or self service to maintain a low cost position. If this is true of your customer’s organization, you may want to request that your customers review self-help materials before calling your service desk.

Another basic requirement might be that your customers become familiar with company standards for PC software purchases and installation. Customers should also be expected to report incidents to the service desk when they happen and not hours or days later.

The customer representative
Typically, one person represents all of your customers for the purposes of discussing and negotiating the delivery of IT services. Additionally, the customer representative has the responsibility to communicate the information contained in the SLA to the customers he or she represents.

The customer representative should be from the middle of the organization—a director instead of a vice president or other senior officer—because at that level of the organization, a director will be aware of the business unit’s strategy and understand the concerns that his or her employees have regarding IT services.

Service level manager
Finally, the person who is responsible for IT service level management, usually referred to as the service level manager, is accountable both to the IT customer and the IT department. The IT service level manager is responsible for negotiating, maintaining, and reporting against the SLA with your customers. That person will also meet regularly with the customer representative to discuss performance and any service concerns; I suggest these meetings be held quarterly.

Evaluation criteria
Without evaluation criteria, you’ll have no objective means to determine how well your IT organization is performing. Use caution when you sit down with your customer representative to select metrics. Be sure that your IT organization has tools in place to track what your customer is asking for before you agree to the measurement.

One of the mutual benefits of an SLA is that you and your customer determine how you will judge the service they are receiving. By establishing objective measurements, you eliminate the guesswork.

Remember that your customers may still be unhappy or disappointed with your performance, even when IT meets target goals. If the motivation and attitude of your IT staff is poor, it will have a detrimental effect on your customers’ perception of how well you really performed.

Your customers will expect metrics to be meaningful and geared toward their view of IT service delivery. When I first entered the IT arena 12 years ago, it was common for an IT organization to publish performance metrics that touted the reliability of the mainframe, number of days without unscheduled downtime, and transactions processed per minute.

These metrics were meaningful to the IT organization, but they were less meaningful to our customers. They were examples of system-based metrics instead of what customers want nowadays, which is service-based metrics. As an example, for an availability measurement of an application to be meaningful, it should reflect the end-to-end service delivery—the application, platform, and infrastructure availability—not just the application. While these components are necessities in an SLA, you may need to include many other measurements because of your specific environment.

Is an SLA worth your time?
If you’re still not convinced that writing an SLA with your customer is extremely beneficial for both of you, consider these final thoughts. Writing an SLA with your customer will provide you with better understanding of your customer’s business, the effect the IT services have on your customer and their ability to carry out their business processes, and ultimately an even better relationship with your customer.

SLA - Service Level Agreement: Setting Rules

Service Level Agreement: Setting Rules 

It is often overlooked that ground rules need to be set up for a successful working relationship.  What needs to be done is to not focus on the agreement, but on the process for how the teams will work together to create the Service Level Agreement.

Subjects up for discussion include the division of responsibility for tasks, scheduling challenges and any constraints that need to be identified. By identifying similarities and differences right up front, you have a better chance of having an effective agreement in place.

The Downside of a SLA
Dissatisfied business users may hope to use an SLA as a hammer with which to club the IT organization whenever service slips. Before engaging in SLA efforts, the objectives must clearly communicate the impact of the faulty service and the changes needed. The organization must also try to understand what the IT organization can and cannot accomplish.

When a relationship is plagued by distrust and finger pointing, it is not the right time to establish an SLA. First fix the underlying problems, and then establish the SLA.

When Is a SLA Really Not an Agreement?
Defining the services and the managerial tasks are necessary if an SLA is to be effective.  Many times we miss the managerial elements in the SLA, for example: the business impact and revenues that are impacted as a result of a downtime.  This will result in having an SLA that really doesn’t add the value that both, the IT organization and the business, hope for.

A useful agreement requires more than entering the elements into an SLA template. The process of planning, establishing, and implementing an agreement is a time consuming process of information gathering, analyzing, documenting, presenting, educating, negotiating, and building consensus.  If your business users are not part of developing the SLA, it's not an agreement and will never be followed or honored.

SLA - Service Level Agreement

SLA -  Service Level Agreement 

SLAs define the formal relationship between IT and business-unit customers.  Without an SLA, the customer (or business unit) does not have any boundaries for demanding resolution to something they may be a problem or perceived as a problem.

How many times have we dealt with our business partners and the demands for solving minor to major applications issues?  Everyone wants it now but what we often fail to have in place is a Service Level Agreement to identify terms for solving our business unit customer issues.

The existence of a quality service level agreement is of fundamental importance for any services or product delivery.  It defines the formal relationship between the IT organization and your business unit customers. A Service Level Agreement is a contract between IT and the business that identifies the boundaries for repairing applications issues.  It is the negotiation between the two groups that records the understanding between organizations.  It usually is in measurable terms and lays out what services will be provided.

To be effective, a Service Level Agreement must incorporate two sets of elements: service elements and management elements. The service elements clarify services by communicating such things as the services provided, conditions of service availability, service standards- such as time frames within which services will be provided, the responsibilities of both parties, costs versus service tradeoffs, and last, escalation procedures.

SLA, some of the terms that should be specified include:
-- What percentage of the overall time services will be available
-- The number of users that can be served
-- Specific performance benchmarks to which actual performance will be periodically compared
-- The schedule for notification in advance of network changes that may affect users
-- Support response time for various issues

I have found that sometimes the business unit wants to create an SLA to suppress complaints; however, attempting to establish an SLA with complaining customers usually backfires because the IT organization will see it as just one more thing to complain about. Before engaging in SLA efforts, the IT organization should obtain customer feedback, seek to understand the complaints, and take some small, but visible, steps to resolve the complaints. The timing may then be better to establish an SLA. 

Thursday, January 15, 2015

The "Problem" with Problem Management

Few IT organizations are really good at problem management; it is often only used for managing the aftermath of major incidents. I think that one of the reasons for this is confusion in the way we distinguish incident management and problem management. We could do a much better job if we changed how we think about these concepts.

I see two big issues with the way we currently define incident and problem management.

1. Failures that have not yet impacted service to users are not well handled by either incident management or problem management.
The ITIL definition of an incident says it is:
"An unplanned interruption to an IT service or a reduction in the quality of an IT service. failure of a configuration item that has not yet impacted service is also an incident. For example failure of one disk from a mirror set."
Even though I wrote this ITIL definition, I really don’t agree with the final sentence. If there has been a component failure that has no impact on any users then we don’t need to follow most steps of the incident management process, and we don’t want the outcome of incident management, which is to restore service to users as quickly as possible.
We can’t use problem management to manage these failures, because ITIL defines a problem as:
"A cause of one or more Incidents. The cause is not usually known at the time a Problem Record is created, and the Problem Management Process is responsible for further investigation."
Something that has not yet had an impact on any users is definitely not a problem, and it’s not helpful to call it an incident either. I think that we should separate these kind of issues, call them faults, and manage them with a "fault management" process. Fault management is well known in engineering as the process that detects, isolates and corrects malfunctions, which is exactly what is needed for this kind of thing.

2. Analysis of incident trends is part of a separate process (problem management), rather than integrated with the underlying process as it would be in every other service management process.
The work that we define as proactive problem management has nothing to do with managing problems. Analysing incident records to spot trends, and proposing changes to resolve the underlying causes of incidents is really doing continual improvement for incident management. Separating this activity from incident management, and from other continual improvement activity, can lead to the following consequences:
  • The register of improvement opportunities is split between problem management and continual improvement; this makes it harder to compare the costs and benefits of all the potential improvements that could be made to ensure the right ones are funded
  • We take away responsibility for incident management improvements from the owner of the incident management process; this makes accountability and governance very difficult
If we create a fault management process, as suggested above, and we then move responsibility for continual improvement of incident management to the owners of that process, then we end up with a much simpler approach.
Changes to incident management that we would need are:
  • Only dealing with service affecting incidents; failures that have not affected service are no longer considered to be incidents
  • Taking responsibility for measuring, monitoring and improving all aspects of the incident management process – including detecting trends in the incident management data
The new fault management process would include:
  • Detection, correction and resolution of all infrastructure and application malfunctions and errors
  • Ensuring that information about faults is made available to other service management processes (such as incident management)
This has a much simpler split of work than the incident / problem management split that we currently use.

Monday, January 12, 2015

Service Desk Manager 101 - How you can be more effective leader/manager

Advice 1 - Hire the Right People 1

The best advice ever: hire people smarter than you.

1. Know what you are looking for to round out your team.

Understand the hole(s) you need to fill. Is it a technical leader, a report writer, someone

ITIL® certified? Understand exactly what you need, or you’ll never find it.

2. Understand your company’s, department’s and team’s culture and the support culture

you project to your clients.

Attitude is non-negotiable. Candidates don’t have to be an exact match, but their attitudes

need to synergise with the team and the support culture.

Communication skills are non-negotiable. Support team professionals must be great

communicators with especially strong inter-personal communication skills.

Advice 2 -Share expectations with your staff

Everyone needs a little direction.

People dread the appraisal process. Managers don’t like to give appraisals, and workers don’t enjoy

receiving them. But, it doesn’t have to be that way.

Appraisals are geared to help people improve. They are not a witch-hunt or a means to get rid of

someone. They are about individual, how he or she can improve and add more value to himself/

herself, the team and the company.

For each team member, you need to score, set objectives, review skills and put an action plan into place.

Step 1: Plan

Simple enough. Let everyone know when you are planning to conduct appraisals.

Step 2: Do the Appraisal


It is frustrating to be in a job for several years and not be reviewed by your manager—no objectives,

no direction, no knowledge of how well you are doing. Or the opposite, where your yearly review was completed on time, signed off and filed away in your permanent record—with no objectives, direction or knowledge of how well you were doing. You have a choice. You can utilise the appraisal process to truly build competent team members.

Step 3: DO THE APPRAISAL

If for no other reason, you may have a stake in the results and the outcome of the process (keep in mind that your own review and compensation may depend on your team’s performance).

Advice 3 - Always be communicating

One of the best ways to communicate with your team is through recognition and rewards.

But, this must be done correctly or there’s no point in doing it at all.

If you remember only one thing from reading this eBook, remember the word ‘must’.
Meaningful (and full of meaning)
Unique (to the individual)
Specific Reason (random ‘high fives’ don’t work)
Timely (Don’t wait until the end of the year or the person’s appraisal)

Advice 4 - Market your team

Marketing your team is serious business. You should do it at every opportunity. Market your team
as a group of professionals who excel at what they do and want to help.

1. Get out from behind your desk.
Make time every week to spend with managers in other areas. Ask questions, take notes, and learn.

2. Invite managers from other areas to visit and observe what your team does day-to-day.
Doing this has two benefits:

– It gives them a greater appreciation for what your team does; and
– It gives your team a better appreciation for the person on the other end of the phone/email.

3. Get involved outside of your department and find ways to relate it back to your team.
Serve on committees, speak at events, write articles for other departments, help set-up and use
various Web 2.0 efforts (such as wikis, blogs, etc.).

This kind of interaction, gives you a better understanding of your company’s business and that,
in turn, gives you more ammunition to show how your team can contribute to the bottom line.

Final Advice - Focus on metrics that matter

Metrics are one of the rare items we deal with that are absolute and incurable. Statistics don’t lie,
but how one interprets the data is another story altogether.

The most important metric isn’t a metric, it’s a shape.

I proudly present the one and only thing you’ll ever
need to know when it comes to metrics – a metrics triangle.

A metrics triangle forces you to take a balanced approach
and to not focus on one area to the detriment of others.

Ultimately, metrics are just numbers. 10 pages of daily metrics
do not add value just because you have them. Part of your
job, and your value, is identifying which metrics work,
which to dump and how to use them to build a stronger
team and achieve happier customers. Often a simple
one-page report consisting of four or five charts and
some explanations is your most powerful tool
when explaining to management
or your team what/how you are doing.



Your goal should be to balance - Productivity, Customer Satisfaction, and Effectiveness