Regardless of where you work, false alarms have likely caused frustration. I remembered this one day as I searched for the source of an electronic alarm, warning me that something was awry in my house. Since the beeping was intermittent, finding the source was comedic.
With each alert I would move in the direction I thought it was originating from, come to a stop, cock my head, and attentively wait, scarcely breathing so that I could take in its next iteration. I darted around the house in a haphazard zigzag pattern, often overshooting my mark. It was as though I was playing the childhood game of “hot or cold” with the electronic gizmo taunting me with “you’re getting colder.”
Eventually, I found the culprit: a carbon monoxide detector. In addition to the beeping, the power light was flashing red – even though the only documented options were solid green and solid amber. Pressing reset didn’t help, so I unplugged it for a few minutes; that always worked in the past. After an hour of futile troubleshooting, I began to consider that maybe it was working correctly and there were actually unsafe carbon monoxide levels in my home.
What a novel thought. I never experienced a smoke, fire, or carbon monoxide alarm that signaled an actual problem. In fact, I was conditioned to assume that any alarm was the result of a malfunction. Smoke detectors were high on that list, with their low battery beeps and false alarms. When I would test them, no one ever left their office to evacuate the building; no one ever asked if there was a fire. The response was always one of irritation: “Make it stop so we can hear our callers.”
Uninterruptible Power Supplies (UPSs) also seemed to do more harm than good. It’s confounding for a malfunctioning UPS to take down servers when perfectly good utility power is available. Yet it happens. For a while I kept track. The UPSs were actually causing more downtime then they prevented. Generators also fit that category. Regardless if there was an automatic transfer switch or a manual bypass – that is, initiated by technology or by people –inevitably something would go wrong. Despite employee training and trial runs, nothing seemed to prepared staff to deal with an actual power outage.
Spare parts and backup Internet connections were another cause for frustration. You have them in case of an emergency, periodically testing them to make sure they are functional. Unfortunately, it seems that efforts to do so invariably result in unexpected side effects and problems, including system crashes.
All these areas give one pause to consider if such efforts actually accomplish a net benefit or do more harm than good. Regardless, it would be irresponsible not to do all that can be done to keep staff safe and systems functioning. The frustrations and false alarms are merely a side effect that one must accept in the process.
As far as my issue at home, I ended up buying a new detector. The replacement unit did not alert; apparently it was a false alarm after all.
Have you ever locked yourself out of an account with a misspelled password? Perhaps you have undergone the agonizing moments when you think you have lost a document or watched the once perfect formatting go from really good to really terrible all in one press of the spacebar? Every day business professionals face these situations and logically would then dial their company helpdesk for assistance. Or would they? If your helpdesk is not perceived as helpful, you employees may not be calling at all, or only calling when there is absolutely no other way around it. They might actually keep the number or email of a particular person in the IT department to call because they don’t want to have to deal with the helpdesk at all.
If your helpdesk team has great technology skills, and less than good communication skills, they may be hindering and not helping your flow of business.
1) Document: This time intensive and tedious task of writing down who called, why, and what the resolution was is the bane of many helpdesk staff. On the end user’s side, frustration mounts when they find themselves saying things like, “I called when this happened this twice before. X person fixed it. Why don’t you know how?” This creates distrust in the abilities of your helpdesk staff, and word spreads like wildfire. Unfortunately, many technical staff have had the experience of poorly managed IT departments which use incident documentation numbers to track and rate staff productivity. I.e. The number of “tickets” equals the worth of the staff member. While arguably statistics from ticketing systems could indicate performance, documentation is the primary way your helpdesk staff can track issues and provide consistent knowledge back to users in an efficient manner. If you don’t have a documentation system or method, get one. Emphasize quality of documentation, not quantity. Make sure everyone knows how to use it, even those not on the front lines of user support. Review the new additions and solutions periodically at your staff meetings.
2) Build a Non-Technical Vocabulary: Some of the most brilliant people at your organization may not have the same vocabulary as your helpdesk when it comes to technology. They might refer to their remote access as “dialing in” or their mouse as a “clicker” or any number of other outdated, or perhaps just descriptive phrases when they call seeking help. No matter what “flashy thingy” they are calling about, they need to be communicated to with concepts they understand and treated with the exact same urgency as a caller who uses all the right words.
3) Get the Big Picture: Many of the mundane tasks of helpdesk can easily be diagnosed, but if your helpdesk isn’t listening, they might be solving many little tasks to the detriment of the person calling who is trying to accomplish a big task. Say for example a secretary calls and needs to know how to get a list of contacts. Your helpdesk says to print the contacts from outlook. But they didn’t ask what the purpose for getting that list was. If the secretary needed to share that information to put into a marketing email blast system, putting them in a .csv would be a lot more helpful. Either the secretary won’t call back because she didn’t get the help she needed, or there will be countless more calls to actually resolve what she needed to do. Take the time to get the big picture. Understand the purpose of what the user is trying to do. Providing the right solution once will always be more helpful than providing partial solutions that might not work towards the users end goal.
4) Create Clear Expectations: Providing your end users clear instruction on how, when, and where to contact the helpdesk and what to expect can help temper frustration for users who are not receiving the service they expect. On your company intranet or phone list, clearly state the hours of helpdesk operation and provide information on how to best contact the helpdesk for their particular issue. Should they call? Email? Enter a request on a webpage? If you offer after-hours support, provide clear instructions on how to initiate that service. Is it sending an email with a particular subject line or calling a toll free number to leave a message? If possible include this information in your employee manuals and as part of on-boarding training. Create a poster to stick in the copy room or break room.
5) Focus: When your staff is assigned to the helpdesk, no matter if it is a rotation or a fixed position, they should focus on the helpdesk. It sounds simple, but often helpdesk staff are tasked with other technology related work in their “down time.” Not only does this divide the attention and intentions of the staff working, but it can lead to poor responses when users do call for assistance. Make sure any duties other than responding to assistance requests are not creating competing priorities or valued above providing effective support.
Improving the way the helpdesk staff communicates within their department, to the end users, and creating clear expectations of service can help improve your helpdesk’s effectiveness and the effectiveness of your business’ employees.
Martha Ciske is a legal technologist in Orlando, FL. She has made a career of being a translator of technology and resident nerd for businesses, professionals, and non-profits. She accepts professional contact via LinkedIn.
Any software you implement in your organization should enable or enhance a business process. Unfortunately, many people mistakenly believe that the software or technology itself is the solution, when in reality, technology is at best 10 percent of the value equation—the other 90 percent is based on the human factor.
Knowing this, it’s no wonder 70 percent of technology implementations fail. In other words, seven out of ten applications that are installed and that companies spend millions of dollars for the implementation aren’t being used one year later. Talk about wasted resources!
How does this happen? All too often, company or department leaders hear about new software and view it as the “next shiny thing.” They call the software provider and say, “We heard you have a great tool and we’d like a demonstration.” The software is certainly seductive with its bells and whistles, but its effectiveness and usefulness depend upon the validity of the information going in and how the people actually work with it. Having a tool is great, but remember that a fool with a tool is still a fool (and sometimes a dangerous fool).
So if technology is not the answer, what is? The answer that will really solve organizational challenges and enable business processes consists of three parts that, when done correctly in conjunction, will lead to long lasting results.
Get the business process design right before you implement any software: The first step to a smart technology implementation is to get clear on what information goes in and what analysis comes out, which has nothing to do with software itself. This is called business process design. Unfortunately, many companies fail to align technology with their processes. That’s because some companies have no processes, while others have a stated process (the one they talk about) and an emergent process (the one they actually do). So what is a business process and how do you design one?
A process is like a recipe. If you have a great recipe for New York-style cheesecake that calls for folding in three eggs one at a time, yet you decide to blend in all three eggs at once, you’ll get a completely different (and probably not very good) end product than if you had followed the directions. Make the recipe again and follow the instructions in the proper order, and your cheesecake will be edible.
If you do anything more than twice in your organization, you should define a process for it. Once you have done so, you should continue to improve upon it. In the absence of a defined and documented process, subsequent actions become experimental. Process design is an investment that’s easy to understand. But while the idea of it usually gets an enthusiastic response, actually doing it gets shelved.
So prior to any software implementation, map out your business processes and define such things as:
What do we want from the software?
How will this software be used on a daily basis in our organization?
Which business processes will the software affect?
Who will be using the software?
Who has the authority to make decisions about the software and the information it produces?
Who will be responsible for inputting the needed data and making sure it’s accurate?
Who will be receiving the data and acting upon it?
How will the data inform our future business decisions?
The clearer you get on business process design and how the software ties in, the better your results will be.
Choose the right technology: No company can do the things it’s called upon to do without technology, so some sort of technology is a must. We all need tools. If you’ve done step one, you’ll have a clear picture of your business and how the new software must play a role. Now it’s time to analyze your software options and choose the one that complements your business processes and will deliver the results you’ve outlined.
Implement the tool into the organization so it has rapid uptake and the shortest time to value: This third step is the most important because it’s about the human factor and how it impacts any organizational change—and implementing new technology is a big change. Unfortunately, too many companies today are simply doing installations. But “installation,” which means “to put something in place” is very different than “implementation,” which means “to put something into effect or action.” Having a new car in the driveway is nice, but if you can’t drive that car, it doesn’t offer much value.
Implementations often fail because companies forget the human factor. In fact, in most changes, human factors pose the greatest risks to long-term profitability. New knowledge and behavior-adoption drive ROI.
Why is change so difficult? Because most of us like comfort. We may complain about routine, but the majority of folks secretly like it. And almost any organizational change threatens our existing comfort zone. Change requires movement from what we know to what we don’t yet know. Like people, organizational cultures prefer to remain the same. That’s why even changes directed at entire departments or organizations, rather than specific individuals, often meet resistance.
So why bother with change when the odds of success stacked against it? The answer is simple. All businesses must continually change or they will die. The markets demand change; customers demand change. Therefore, you either instigate change or it will happen to you. David Nielson, a leading authority on organizational change says to better prepare your team for change and have a successful implementation, be sure you do the following six things:
Communicate the business case for the change
Identify internal change agents (allies) and engage with them
Educate and support the change agents
Assess adoption readiness
Define and support effective behavior
Execute a communication plan about the change
Remember, implementation will fail unless sufficient time and resources are allocated to the process of learning. These six steps form the foundation of successful implementation. Miss one and you’re asking for trouble.
Make Your Technology Implementations Work: The message is clear: Technology is not the answer. Yes, it’s an important piece of the puzzle, but it’s not the all-encompassing solution so many people believe it to be. If you just focus on the tool, you may end up the fool; but if you focus on the business, the tool, and the people within the organization who will be using the tool, you’ll be the leader who not only uses technology effectively, but who also sees great gains in productivity and profits.
Michael Menard is the author of “A Fish in Your Ear: The New Discipline of Project Portfolio Management,” and cofounder and president of The GenSight Group, which provides enterprise portfolio management solutions for strategic planning, project portfolio management and business performance optimization. A holder of 14 US patents, Menard has utilized his expertise to advise senior executives at organizations such as Coca-Cola, Cisco and the US Department of Energy. To learn more about Mike Menard please visit http://www.afishinyourear.com.
I have a love/hate relationship with technology. I love to have the latest, fastest, and most powerful tools and toys, but I hate the time it takes for implementation, requiring that I preempt more important activities to install, fine-tune, and master my new technology. Therefore, I tend to stick with what I have.
However, it became time where I had to buy a new office computer. Given my reluctance to spend time migrating from one computer to the next, I had successfully found reasons to put this off for over a year. But my aging computer was clearly being taxed, so I finally made the switch.
My new computer is much faster, and Windows 7 is a great operating system, with an easy learning curve from Vista. This computer is my first with a DVD burner and my first without a floppy disk drive. Also absent are the modem and parallel port – an oversight on my part, given that my old faithful printer requires a parallel connection.
The cost of the computer breaks down to about 50 percent for hardware and 50 percent for software (Windows and Office) – and 50 percent for unforeseen expenses. Yes, there were costs overruns. I’ve had to upgrade several of my other programs to work with Windows 7. Aside from my parallel printer, my other printer lacks a Windows 7 driver. Although I have temporary workaround solutions for both, a new printer is in my future as well. That will push the cost overruns even higher.
My other frustration is with Office 2010, specifically Word. Had I been using Office 2007, the switch would have been easy, but my migration is from Office 2003. For my prior computer upgrade, I purposely retained Office 2003. The user interface on Office 2007 was quite different (a learning curve issue) and cumbersome to use (an efficiency issue). I had hoped that the 2010 version would return to an Office 2003 type of interface, but that was not the case.
With Office 2003 showing its age, I made the leap to 2010. Despite my frustrations that common routine tasks now require more mouse clicks, I am discovering new features, pleasing improvements, and some nice shortcuts, so it will eventually be okay. Even so, two months into it, I am still not as efficient as I’d like to be when I write.
My new computer has cost me both time and money. The cost overruns were my fault: I overlooked the need for a parallel port and all my driver problems stem from the fact that I bought the 64-bit version of Windows (32-bit drivers were available for all my programs). The time issue, however, was unavoidable. Fortunately, I scheduled my purchase during a slower period of the year. This afforded me extra time to spend converting to the new system and learning new software versions.
Upgrading a single PC pales in comparison to replacing technology in throughout an office or workplace, but I don’t want to discourage anyone from doing that; the benefits are just too great. What I do want to communicate is to be extra careful in spec’ing the system and allow additional time to learn it and become proficient. The results will be well worth it.
I’m a huge fan of technology — and the allure of speech recognition (also called IVR or interactive voice response) carries with it great appeal. Yet when it comes to real-life implementations, I find it decidedly lacking and frustration-filled.
In the past I’ve been reticent to state my disinclination — knowing that I’m part of the problem: my words often lack clarity. Clearly, I don’t make a speech recognition engine’s job easy.
Some errors are easily explainable given my imprecise speaking tendencies, such as asking for Candy Lane and ending up with Cam DeLain. However, other occurrences are nonsensical, making for a great comedy skit, albeit poor customer service. For example:
“Good morning, Acme Call Center; your call is important to us. Please say the department or name of the person you are calling.”
“Sally Pavasaris” I dutifully respond.
“Did you say “Ned Flanders?”
“NO,” I exclaim! Nothing happens. “Sal-ee-Pa-va-sar-is,” I decidedly project using my best possible diction.
“I’m sorry, I don’t understand. Please say the department or name of the person you are calling.”
“Agent!” I implore. “Operator!” I beg. I begin pressing zero with repeated vigor. When I’m finally connected to a person, my demeanor is less than stellar. I know why, but the agent is clueless, likely muttering about rude customers after she transfers my call.
To further complicate matters, what if I don’t know the person’s full name? What if I can’t pronounce their last name? Speech recognition is ill equipped for such situations.
Another common issue that I have is a quandary on how to proceed when the software and I talk at the same time. A common dilemma is:
“Please say your account number…”
“Seven,” I begin.
“…followed by the pound sign,” the voice continues.
At this point I have a critical decision to make, the ramifications of which could have frustrating consequences. Do I assume that “seven” was recognized, allowing me to confidently proceed in giving my account number? Or should I play it safe and repeat the first digit? If I guess wrongly even more time will be wasted attempting fruitless communication with a machine. Either way, I’ll inevitably hear: “I’m sorry; that number is invalid; please try again.”
Sometimes I try to suppress my impatient tendencies (why am I patient with people and impatient with machines?) and wait to make sure the voice is done talking. Sometimes I pause too long, at which point I’m rewarded with the unappreciated prompt, “Please respond now.”
To avoid causing the voice further frustration, I quickly comply. This usually results in the situation I was attempting to avoid in the first place — the machine and I simultaneously speaking. At this point things usually spiral further out of control. The software still doesn’t know my account number, I still don’t know when to speak and when to listen, and I’m sensing that the likelihood of talking with a real person — versus talking to a machine trying to act like a person — is even more unlikely then when I started the call.
It is true that a careful speech recognition implementation can serve to speed up call processing and improve caller satisfaction. Sadly, that goal is not often realized. Instead, grandiose efforts are attempted, with little to show for it — aside from frustrated customers and unnecessarily maligned telephone agents and customer service personnel. Is that the intended result of technology?