No organization has unlimited budget so you have to make conscious (and maybe unconscious) choices on technology.
• You might think your network is “fine” but if you have poorly performing equipment, would you know how to determine performance? You might think your disk space is “fine” but if you are about to run out of disk space on a server or workstation would you rather know a couple months in advance instead of when it happens? Do you have a way to gather performance counters on the 4 main bottlenecks of your technology processing speed, available memory, disk capacity and network speed?
• You might think applications are “fine” but do you know if you are accidentally running 2 different versions and it is causing minor issues today? Can you identify what version of an application is installed on each individual PC and do you have a way to update it?
• You might think your network security is “fine” but most hacked organizations don’t know they were hacked until after the fact. The Verizon 2015 data breach investigations report of organizations determined that in over a quarter of the cases, it took days or even months to discover a breach. Do you have security logging configured for your main systems and a way to gather details on status and compliance?
The 7 cheapest cars in the US all came in under $15,000 this year. Do you drive a Nissan Versa, Chevrolet Spark or similar vehicle? They all will handle several passengers, get you where you need to go and are mechanically reputable. Why do you choose to drive something different? Likely because you recognize not all cars are equal and some deliver results slightly differently, and that difference is something you want for yourself. You want to avoid crashes, but may not want your people to waste time working with vendors on support issues. You want to save money on services but reduce possible risks to your business and be able to respond to issues quickly. You want to minimize up-front capital costs but understand if it offsets true lifecycle costs in longevity, performance or disposal.
This is why we suggest you evaluate your computer networking and security in a similar way, finding what is appropriate for your business need. You need a network that consistently operates without users experiencing slowness, outages or issues during the business day. You need security tools configured to reduce the possibility of a breach, able to alert you to potential issues and the auditing periodically needed to discover vulnerabilities and comply with industry standards such as HIPAA (healthcare) and PCI DSS (credit cards). You need “executive”-level discussions about the entire lifecycle of your technology and that is usually not a discussion you can have with a solitary IT person trying to be an expert in everything – or the neighbor next door, who works on computers part-time, after-hours.The best performing IT and management teams work hard to align business goals with technology purchases and activities. Our Business Alignment Report (BAR) is designed as a two-page report card outlining common elements of a healthy network, potential concern areas and suggestions for mitigating risks. We use this as part of our Quarterly Business Review (QBR) process. During the quarterly meeting we talk about your business and discuss your BAR. Are there concerns? What is our priority? Are we in alignment? Are there new goals or competitive concerns? To help us drive success in the projects that might come out of these meetings, we utilize the project management framework called Scrum which is based on an agile development philosophy, meaning the team works together, adapts well and works to deal with changing requirements. This agile project management is a great fit for our smaller projects where there is only a basic set of requirements known at the start and third-party delays might present bigger problems for more sequentially-oriented implementations. Our Scrum board is used for the vast majority of our projects with only our largest projects being more waterfall method, with more distinct planning, development and testing phases. An organization can probably be successful with either method, but we find that the daily sprint process of Scrum tends to deliver the benefits our clients need sooner, rather than later.
In addition to the proper design and implementation aspect of technology, a service team should drive itself towards a structured approach of the service and support aspect of technology. A good Help Desk centralizes requests and triages incidents based on time sensitivity, business impact and easier to resolve incidents. When you don’t prioritize, your service efficiency shrinks from spending time doing the wrongs tasks first.
Our service organization measures itself with various service key performance indicators (KPIs) to ensure quality operations. In managing your service team, you should think about what and results are most important for your technology to be successful. Some of our top KPIs used to manage our service team include:
• mean time to respond- we internally track the length of time from when the ticket/call/alert comes in until we respond to it. Our response is usually the dispatcher or an engineer making changes to the incoming ticket to begin work on it.
• mean time to restore/resolve- we’re looking at how long it takes for us to resolve the client issue. Not all technical issues can be resolved quickly, as they may require some research or testing one change at a time, but understanding how long on average it takes for us to resolve an issue helps us measure our team.
• customer satisfaction rating- getting honest feedback in a timely fashion is sometimes a challenge for service organization, but extremely valuable. We currently try and earn feedback by various methods, but in general, when a ticket is closed we send the ticket owner a survey and ask a small number of questions for feedback.
The top two metrics are part of our service level tracking and the third relates to customer service. We also have some technical metrics for our client sites, including an executive summary rating based on uptime, patching compliance and network utilization. We have other internal-only metrics that would only have value to a service organization such as calls in queue, backlog, resource utilization and so forth. Suffice to say that like any other aspect of your business, we are firm believers that we can only manage what we measure. This is especially useful for IT or other service teams.
Another great metric referenced in the section above that warrants its own discussion is our customer service surveys. These surveys are reviewed at our monthly engineering meeting with the low scores discussed for feedback from the team. Engineers earn part of their compensation based on survey scores and can be terminated for consistent scores below our desired threshold.We also review our clients for their aggregate feedback survey score over time (to gauge every engineer’s success at achieving technology goals for a client) and review our engineers for their average score across all clients (to see if there are additional department or person specific training or soft skills needs). We also discuss the survey feedback in our client Quarterly Business Reviews since client management may have different opinions than surveys or may have heard different feedback. We’ve found the key is in asking for, and truly hearing, feedback so we can find opportunities to continue to refine our services.
As part of our service management process we depend on these nuggets of gold to help make us better. In the past year alone we’ve gotten some great suggestions or tips that we’ve turned into changes to our operations and processes.• We amended our ticket closure process so after an engineer marks the ticket as COMPLETED, another Fulcrum Group team member attempts to contact the client to make sure the issue is fully resolved and then the ticket is marked CLOSED.
• We already have a corporate goal of a live body always answering our phones. But, we got feedback that our Help Desk was falling behind during a period of company growth and we have now switched to a centralized dispatch model. One person takes all incoming Help Desk calls and gathers the right details but does not work the ticket himself.
• We have also arranged engineers into a structured system by skill level. After the dispatcher takes a call, he then assigns and transfers the ticket to the first available Level 1 resource, the organizations designated Level 2 primary engineers for site specific needs or to a Level 3 subject matter expert for the tougher issues.
Grade your IT infrastructure or use to measure your technology successes. Here’s how to start.
This whitepaper provides guidelines on how to grade your organization's IT. Fill out the form below to read those guidelines.