We spend our whole lives being measured, from beginning—babies are weighed and measured at birth—to end—when we’re weighed and measured for our coffins (or urns). In the intervening years, we measure our lives in milestones: birthdays and anniversaries, first days of school and graduations, first dates and weddings, births and funerals, and so on. These personal metrics are just as important as the professional metrics by which companies measure their success and supervisors measure their employees’ performance.
Sometimes, we don’t take metrics as seriously as we should. We get complacent. We fail to set clear objectives. But successful people and organizations aren’t satisfied with “good enough”; they set demanding targets and put all their effort toward reaching them. This isn’t just a characteristic of modern business, either. Look at the marvels built by past cultures and civilizations. They all had one thing in common: a shared goal. Whether it was religious, scientific, or political, it was something everyone could relate to and work towards.
Goals and metrics are two sides of the same coin. Without one, the other is meaningless. In this article, I will introduce you to two related concepts: Good Day Bad Day (GDBD) and service focal points (SFP). SFPs are overall goals or objectives based on specific metrics, KPIs, and CSFs. Whether your meet or miss your SFP targets will determine whether you’ve had a Good Day or a Bad Day, an indicator of daily performance. Armed with this information, you can make incremental adjustments to your processes to keep your service desk on track and performing at a level that meets or exceeds the organization’s expectations.
The Good Day Bad Day Concept
Consider baseball. Ask any die-hard fan how she knows her team is a success and she’ll rattle off a veritable alphabet soup of statistics. But what’s the one statistic that truly matters? Wins. The same is true for the service desk. SFPs distill many metrics down to one simple statistic that tells you whether the last twenty-four hours was a Good Day or a Bad Day. If you had a Good Day, you can relax and concentrate on the job in hand; if you had a Bad Day, then you had better find out what caused it so you can stop it from happening again. Note that having a Good Day doesn’t mean you can rest on your laurels. To stop your service desk from getting complacent, you should regularly review your Good Day targets and set more-challenging objectives.
Advantages to the Good Day Bad Day Concept
There are many advantages to the GDBD concept, but right at the top of that list is that it enables the service desk to focus its attention on ITSM and how successfully its principles and processes have been applied over a given period. For example, GDBD is particularly germane to continual service improvement, one of the main stages of the ITIL lifecycle (though it might be more accurate to call it continual service quality management). Even if the service desk had a Bad Day, by reviewing its GDBD data, CSI can make recommendations for improving quality, service, and performance.
Start each day with a short GDBD review. This will get everyone, from IT to the business, on the same page. Create a GDBD webpage on your intranet and update the service desk’s GDBD status every morning. Encourage all staff members, throughout the organization, to visit the page regularly. You’ll be surprised how many people access the site, even on Bad Days. Publishing your GDBD status and sharing the underlying metrics can help you create a new and deeper bond with your internal customers; if your service desk has struggled to overcome the us-versus-them barrier, GDBD can give you a boost. Above all, have fun with it. GDBD is an example of what I call “metricity” (metrics + electricity); done right, it can electrify your metrics program and galvanize your service desk’s overall performance.
Approaches to the Good Day Bad Day Concept
To make a success of the GDBD concept, make sure your approach focuses on the departments, processes, and resources that are most important to your organization.
-
Service Desk: This is an example of GDBD being aimed at a single function, application, service, or facility. Even if you can’t get your entire IT department to buy into the concept, you can implement GDBD narrowly, to a single resource.
-
Service Level Agreements: Good SLAs should cover all aspects of a service. Thus, they should reflect the performance of all of the departments and individuals who contribute to meeting those targets. Whether it’s one SLA or a group of SLAs, you will still need to distill these down to a single SFP.
-
Service Level Management: This entails a much broader application of the GDBD concept. If GDBD has one weakness, it’s in trying to distill too many components down to a single SFP. If you intend to apply GDBD to SLM, you may need to create a number of SFPs and view each one as an independent GDBD target.
-
The Business: This GDBD approach is broader still, concentrating on the services that are vital to the organization as a whole, instead of IT and ITSM exclusively. However, this doesn’t mean that you can’t (or shouldn’t) measure and report on individual services as secondary SFPs for internal use.
-
ITSM: Another approach is to apply GDBD to a few key service management processes or functions. If you aren’t responsible for all of the ITSM processes your support organization uses, your performance may be negatively affected by the contributions of other process owners. This localized application of GDBD will draw your organization’s attention to you and your staff, which may, in turn, inspire reluctant process owners to participate.
The key to success with the GDBD concept is starting small. For example, don’t be afraid to start with one SLA, introducing a new SLA on a regular basis until you have a full complement. That said, selecting the right SFP is also imperative.
The right SFP makes all the difference. To define your SFP, look to your critical success factors and key performance indicators; they should feed and be fed by your SFP. The graphic on the previous page illustrates a simple approach, where three KPIs feed into a single CSF. This relationship can be much more complex and comprehensive. In the example below, nine KPIs feed three CSFs, which in turn feed one SFP.
As you can see, it’s possible to meet your overall GDBD target even if you miss your individual KPIs and CSFs targets. This does, however, indicate that you need to take some corrective action behind the scenes to address these anomalies before they cause trouble.
How It All Works
Executing the GDBD concept is fairly simple. The diagram below illustrates the basic process.
-
Collate your metrics. Ideally, this data should be collated electronically, though it can also be tracked manually using a simple spreadsheet.
-
Enter your GDBD data. Whether this is an automatic or manual process, always double check the data entry or collation. It would ruin the creditability of your initiative if a Good Day was declared a Bad Day, or vice versa.
-
Determine whether you’ve had a Good Day or a Bad Day. Again, don’t forget to double check your numbers.
-
Initiate the Bad Day procedure. You should have your Bad Day process worked out in advance. For example, you may need to inform senior management so they can get involved and prepared for any fallout from the Bad Day.
-
Prepare a GDBD report. This brief report summarizes the previous twenty-four hours and highlights the key points to be discussed during the GDBD meeting.
-
Publish the GDBD report. Send a copy of the report to the scheduled recipients using the delivery method of their choice. Encourage as many people as possible—IT and non-IT—to review the GDBD report. And don’t be afraid to use graphics in lieu of lengthy description; bold colors and illustrations (i.e., a smiling or frowning face) are often better for drawing attention to a single piece of data or information.
-
Prepare the GDBD presentation. Like the report, this should be brief. Make sure at least one representative from each key IT unit attends, whether they’re there in person, via Skype, or on the phone. (Which units are key? Any unit that can turn a Good Day into a Bad Day!)
-
Run the GDBD meeting. Again, keep this short and sweet—don’t get distracted by other business. If the previous day was a Good Day, focus on any anomalies that could cause future outages and appoint a representative to own their remediation. If you had a Bad Day, then the meeting might run long. But just as they would for a Good Day, one of the attendees should take responsibility for the Bad Day and pledge to either correct the fault that caused it or, if it can’t be corrected, make sure it can be resolved more efficiently in the future. At the end of the meeting, review the latest corrective actions report. (If you’re an ITIL shop, you could use the continual service improvement register as your corrective actions report.)
-
Who owns the GDBD meeting? The owner could be anyone in IT, but the ideal choice is the service desk manager, as he typically has a close relationship with internal customers and the key IT units. Whomever you choose, it needs to be someone who is available to manage Bad Day issues, but not someone ho owns one of the IT units responsible for correcting those issues.
-
Prepare the GDBD summary. After the meeting, the meeting chair should write up a brief summary.
-
Publish the GDBD summary. This report should be distributed to those who requested a copy.
-
Update the corrective action report (CAR). This simple report itemizes the outstanding actions required to address previous or existing anomalies, and identifies the owner and status of each action.
-
Take action. Make sure the actions itemized in the CAR have been or are being taken.
To ensure the long-term success of your GDBD program, set quarterly or annual targets (i.e., “XYZ, Inc. will have 350 Good Days in 2013.”) This is another place where bold graphics and illustrations can call attention to your achievements. Don’t be shy!
* * * * *
Without clear objectives, metrics are just a pile of numbers. The good is when we beat our Good Day targets, the bad is when we fail to hit those targets, and the ugly is when we fail to set challenging objectives. Remember, like baseball, the only thing that really matters in the end is whether or not your team wins.
Malcolm Fry is an industry luminary with more than forty years of experience in information technology. He has authored many best-selling books, articles, and papers on IT service management, including
Building an ITIL-based Service Management Department . In 2009, Malcolm was awarded the coveted Ron Muns Lifetime Achievement Award for his work in the service management space.