Sunday, November 13, 2011
But, the true test in learning from experience is a function of our ability to appreciate the events of our day to day lives. Every day has life lessons to give but most of us spend our time observing only the events that support our current beliefs. I could use this as a point to begin discussing politics but I truly believe that this blindness to the events around us impairs us all.
For a great read, I would suggest “How We Know What Isn’t So” by Thomas Gilovich.
I was thinking about this a few weeks ago while on a walk-through of a new construction project.
A large group of us had finished walking the halls of the building and we were hammering out a few last minute details. I was looking over floor plans when I noticed a number of cabling drops had been removed from the final prints. I was lamenting the loss of connectivity when the construction manager (CM) jumped in with a vigorous defense of their removal from the plans.
The tenants only planned to house one staff member in each room. Extra cabling was useless and unnecessary. In rooms planned to support more than one staff member the extra cabling was left in place. In short, the building plan was a lean, mean, and efficient machine delivering connectivity to each desired location without wasting cable. I got the sharp impression that I and others of my type were a drain on the project trying to wring out any “free” facilities that we could.
This isn’t the first time I had experienced the cost-cutting aggressiveness of value-engineering but I think I learned something from the CM that day.
I explained that his cable drops could be in the wrong place. I was told to run longer jumpers. For maintenance, nothing is more annoying at the host than long jumpers.
I explained that his cable drops didn’t account for a change in the room use. I was told to run additional drops later. Cabling drops placed “just in case” were a drain on the project and a waste of money. The first new cabling run will be requested within a week of occupancy.
I explained that some rooms had no cabling at all. I was told that they would never need cables. Any room large enough to be an office will one day be an office.
My shoulders slumped and I shook my head.
I’ve learned these lessons over years of maintaining buildings both on campus, and in a private capacity. But, as I walked away I wondered why the CM hadn’t learned the same lessons. He made a few great points about taxing a construction budget to the point where construction is cancelled. For him, it meant very little to add changes later and come back to do additional work. He had learned different lessons in his career.
And that’s where, for just a moment, I learned a lesson again in perspective.
The CM works on large construction projects. For him, every job is large, involved, and complicated. For every job, impact to budget and time can be measured and used to calculate whether a job should be move forward. Coming back to install cables is a trivial need when you spend your life constructing buildings.
When maintaining a building and responding to user requests, installation of an additional cable can be a multiple week stumbling block of managerial approval, PO generation, cable installation, and finally making a final patch connection. The pain in lost productivity can be soul-crushing.
I don’t know that he was aware, but I was actually paying attention that day. Often, my interaction with building construction project managers and construction managers is in an adversarial role. They want to build a building. I want UF standards followed. But, for just a moment that day I truly understood why construction personnel thought the way that they did.
With any luck, it will help me the next time I have to explain why that second cabling drop in a 10’x12’ room is necessary.
Monday, October 3, 2011
Customer service hasn’t taken a dramatic dip in recent years. In the last year alone, I have encountered multiple service staff that have gone the extra mile in resolving my issues. A firm but helpful account representative of Alachua General Hospital comes to mind. She dealt with a very frustrated patient who had been repeatedly ignored, shuffled from department to department, and cut off multiple times. She took the issues at hand, calmed the patient, and resolved three weeks of multiple contact attempts in ten minutes.
And, the customer service ethic of the past was not the shining beacon that our older population would have us believe. My father often argued with everyone from salesmen to insurance agents. I don’t think he was experiencing the joy of the good old days back in my good old days.
But, technology has allowed companies to put more distance between themselves and their customers. And, in the name of the bottom line, a number of them do so.
I won’t reiterate my distaste of phone trees here but I would like to share my experiences of the last few weeks.
I was fortunate enough to attend the Fall BICSI conference at the MGM Grand in Las Vegas. While there, the staff of the MGM performed their duties admirably. At no time was there a moment when a staff member was not attending to a customer’s wishes. The staff answered all questions quickly and efficiently. In addition, after dealing with a customer’s immediate needs each staff member was quick to point out other services that they were ready to render.
I asked about the kiosks for printing out my boarding pass at the hotel itself (a wonderful amenity). Not only did the lovely woman at the desk point them out, she asked if I had secured transportation, pointed out the shuttle stops, and offered to have my bags delivered to the airport. For those suspicious of her as a suggestive sales technique, all services were bundled with the room and incurred no additional cost to me.
Following that, I found I needed a receipt for my stay. I am currently engaging in my third attempt to request a receipt from the MGM accounts receivable department. The MGM phone tree (no tree necessary to book a room) bounced me around to where I could leave them a message so I did so. I have e-mailed their friendly support address twice and today I will try calling again.
Technology cannot be the problem though. Technology has made communication easier than ever. Customer service levels should be at an all time high.
As a counter point to my experiences with the MGM Grand, I contacted Blizzard Entertainment at the World of Warcraft support lines. I had received an e-mail informing me that my new account was established and ready for use. I do not play WoW so I was concerned that someone was using my e-mail account for some nefarious purpose.
I submitted a trouble ticket through their online system. My ticket was acted upon and I was notified in less than an hour that there would be no difficulties with my e-mail address. I was impressed. At no point did I make direct contact with a person but Blizzard addressed my complaint quickly and efficiently. I spoke with friends that play WoW and the description of their customer service experience echoed mine.
So, technology has opened up methods of communication that were never available in the past. As organizations become larger, customer service agents become more specialized in order to better cater to the needs of their clientele. But, the general service agent has been replaced by technology that still isn’t mature enough to meet the needs of a customer base.
Companies know the weakness of these systems well. Salesmen will never be replaced by a web form or phone tree – a smart company will never let technology stand in the way of a customer given them money.
I can get a reservation with a hotel without sitting on hold.
I can buy a computer without sitting on hold.
I can get any cell phone service without sitting on hold.
But, Blizzard shows that technology alone doesn’t hinder a company’s ability to address customer demand. Blizzard handles millions of customers remotely year after year and never directly interacts with them. A Blizzard customer would be hard-pressed to tell you where the Blizzard offices are located.
The WoW business model relies on customers to maintain their monthly payments. WoW is not a product that customer requires and there are not long-term contracts. Customers with negative experiences can simply stop payment and walk away – and they have. Customer service requests to Blizzard reflect a customer’s inability to play the game and that is a direct threat to their business. Blizzard trains their staff to deal with problems quickly and directly. Any delay in addressing a customer complaint translates into an opportunity for that customer to break their addiction to the game.
So, we cannot blame advancing technology for any perceived change in customer service. Technology introduces a distance between a customer and the service representative that can adversely affect that relationship. But, tacit company approval is required before that relationship begins to suffer.
So, as always, if a company has poor customer service, the company is to blame. It just becomes more annoying when the company is so good at getting you in the door before they decide to ignore you.
Friday, July 8, 2011
There really is no better way to communicate how I feel on this topic. I hate calling customer service. When I make a call and a machine answers the phone I just sigh. I punch “0” hoping for the operator anyone else. I hope to reach someone who can actually solve my problem. Eventually, I’ll follow the rules and hope for the best. Usually, the best isn’t very good.
Many smart people work on creating these trees. Vendors make a great deal of money designing these trees. Phone trees, they claim, allow a user to answer a few questions and appropriately route their own calls. Operators and receptionists are no longer necessary. Efficiencies improve. According to surveys customer satisfaction remains steady and companies can cut costs.
It’s very hard to argue against phone trees.
I work in IT and there are times when I’m the one on the other end of that phone tree. I have taken calls from UF staff that need help. They may have been routed to me appropriately or not, they don’t care. They just want someone to fix their problem or provide them service. If I can’t help them, the last thing they want is to be thrown back to the tree.
Usually, I never send them back to dispatch. I know enough people in IT here at UF that I can usually find someone to fix their problems. I listen to their story from beginning to end and make the next step without them. I find someone who can help them, then forward them along.
But, before I send them on their way, I always make sure they have my direct number. If I send you to someone who doesn’t solve their problem, they can call me back directly. Every single time I am thanked profusely. I’ve had a number call me back just to thank me for not letting them loose back into the system.
No one wants to be cut loose.
At UF, we’re currently working on developing a webpage for users to submit problem reports and service requests. There are a number of powerful tools that are available for creating these front ends and we have one at our disposal.
A well-crafted front end to a help desk can be used to route users to the appropriate support staff. Self-diagnosis of a problem can help a user cut through levels of red tape and cut directly to the support staff best suited to solve their problems. Utilization of the web form can be used to gather statistics concerning the incidence of problems in our environment.
A well crafted front page can be a valuable tool for routing users and gathering information.
A well crafted phone tree can be a valuable tool for routing users and gathering information.
But phone trees, in fact all user-managed entry portals, work based on the same fundamental premise. Every phone tree communicates the same message to the user.
My time is more valuable than yours.
Saturday, June 11, 2011
I’ve attended a number of construction meetings over the years where I wished that standards had more bite. I wished I could point at my printouts and demand people follow the rules.
Now, I’m not so sure. When I’m training my staff I try to convey not only the standards applicable to the topic but the logic behind those standards. Bodies create standards to serve specific purposes and solve specific problems. When a standard does not serve that purpose, we should set it aside. There is a time to not follow a standard.
That statement alone has gotten me more than my fair share of bad looks. But, standards do not arise in a vacuum. There is always context.
At UF, our Telecommunications Standard once required three cable drops at every outlet location. The standard was written down and delivered to every contractor that did work on UF campus. A number of smart people put their heads together to come up with that number. Their work should be respected.
When challenged on that requirement, we have a number of options. Those that don’t truly understand the standard or feel like discussing it rely on the document itself. The requirement itself cannot be challenged because it is a component of a University standards document. Everyone should respect the document. After all, a standard is a standard.
Unfortunately, work is rarely that simple. Most work, when done according to standard, costs more. Project managers are always under pressure to cut costs. And a cabling consultant rarely gets the last word in any project. Notes are lost. Requested changes somehow don’t make it to the next set of drawings.
But, when we understand the reasoning behind a standard, we can change the adversarial nature of a planning meeting into one of mutual understanding.
We need three cables for network, phone, and one spare.
What about an outlet for a network HVAC connection located above the ceiling. Can we only install two cables for that outlet?
Sure. Or, maybe not.
At this point a cabling consultant can discuss the topic with the project manager from a common point of reference. Maybe the project manager is making a reasonable request. If so, a consultant should feel confident enough to step away from the standard. If the request is unreasonable, the cabling consultant should be ready to explain why the request is being rejected. The project manager is not there to destroy the telecommunications plan – the manager needs the plan to work. They are operating under other constraints. The IT consultant should always bear this in mind.
As a consulting professional, we need to be able to explain the logic behind any standard we are trying to enforce. In a meeting with project managers, owners, and tenants, it is always in our best interests to convince others that standards exist for their benefit.
As a contractor I always tried to convince customers to place two cables at each outlet location. I would explain the reasons why. Sometimes I was successful and sometimes I wasn’t. In those instances where I installed fewer than the standard number of cables, I was often called back.
Each time I was called back to install additional cables for these customers, there was no malice. Each customer knew that I was looking out for their best interests and more work followed.
I’m sure I’ve said it in earlier blog posts, but we have a responsibility to treat others as the professionals we often claim to be. Stomping our feet and pointing to a piece of paper to justify our requirements does a disservice to our role in the industry.
Our credentials do not grant us any magical insight and the information we have means nothing if we do not share it.
Thursday, May 19, 2011
The theory goes that we can guide an employee to better behavior by “expecting” more from him. The converse holds as well. We can guide an employee into mediocrity by “expecting” too little. Having high hopes for an employee can help them while expecting them to barely work will result in them barely working. Using expectations fall into line with common theories on team-building and generating an appropriate esprit de corps.
Unfortunately, in my time I have seen the negative effects of this theory more often than the positive.
A few years ago, my workplace converted all of our cabling documentation to a new format. I was in charge of overseeing the transition and training the staff to use the new system. We migrated the data with more ease than we expected. I set up a few training classes to introduce staff to the concepts. We prepared to move forward.
Just prior to implementation, my supervisor came to me to ask what else we could do to help people interact with the new system. Management held concerns that staff would have too much difficulty interfacing with the new system.
In response, a staff member of mine created a line by line procedure with screen shots to guide staff in how to execute one task in the system. Our management was giddy. I followed up by crafting ten more documents that explained line by line how to insert documentation into the system. We had dummy-proofed our system.
Years later, staff still use those documents. It doesn’t make me proud. Years later, we have staff that have interacted with this system on a daily basis for years that still cannot carry out routine tasks without referencing the procedural docs. We had told our staff it was okay to be dummies.
Procedural documents have an important place in training staff but this kind of documentation carries an implication of ineptitude that I find insulting. Documents written at this level communicate that the staff cannot be trusted to know when to press the [enter] key.
On some levels, people even discuss this openly. We are currently in the process of implanting a new software package that will radically change how we process work orders, change requests, and service requests. The package is not easy to understand but those difficulties could consume a number of blog posts on their own. I’m more worried about a repeatedly voiced concern that we need to keep things simple for the front line service desk. We need to keep things simple since they are not full-time employees. Truly, what can we expect from them? Full-time staff could produce better results. We need to make things simple for them.
I think that in management there’s an appeal to writing procedural documents for every task. There is an appeal to treating your employees as buffoons and not expecting too much from them. Procedural documents shield a company from liability and produce the illusion of consistent results. By making sure we cater to the least common denominator we ensure that we have fewer problems with HR. No one wants to have a meeting with HR, a union rep, or lawyer and try to explain that you are not effectively training your staff.
But, in doing so, we stifle the productivity and creativity of our staff. I have watched it happen. I’m sorry to say, that in my time I have helped it happen.
More and more, I’ve tried to lay out my expectations for a project, provide procedural documentation, and then encouraged staff to lay them aside when they think they have found a better way. I judge them based on results.
It’s a difficult balancing act. Sometimes I micro-manage and sometimes I give a bit too much freedom. I tend to see-saw a bit more than I should.
But, I’m still much better off than if I had directly addressed every aspect of every task they need to complete. I do not need a buffoon working for me. Even more, I never want to take part in turning any of the creative people that come to work for me into one.
Sunday, April 10, 2011
I just spent the last week attending the ACUTA conference in Orlando, Florida. Not only did I have a wonderful time, I met a number of amazing people and plan on keeping in touch. As a bonus, the facilities had me thinking about future vacations and I think I’ll be checking out the Hilton Bonnet Creek for a visit to the mouse within the next five years. My boy needs to get a few years under his belt to truly appreciate a day in Walt Disney World.
While there I attended a number of lectures and there were some wonderful speakers. Before leaving for the conference, I was thinking about the phrase “continuous improvement.” Honestly, I tend to be rather cynical concerning new management buzzwords. ISO 9001 came and went without much effect on the rank and file I manage. ITIL is now making the rounds around my office and I wonder how much of the core philosophy we will truly embrace. Continuous Improvement is one of the newer phrases I’ve heard repeated around my upper management. I find the idea appealing.
As a creature of habit, I find it very easy to fall into a rut of just “doing my job.” Day in and day out my team has a number of tasks that need to be accomplished. I make that easier for them either by arranging training, smoothing over political difficulties, or coordinating their activities to respond to upper management. That’s my job. But, focusing on the job does not give much opportunity for continuous improvement.
At the conference, I was attending a panel of past ACUTA presidents and I heard something that stuck with me. I would like to properly credit the speaker but I don’t recall panel member was speaking. He advised that when working, we should be constantly seeking out the problems and coming up with solutions. If we aren’t doing that, our jobs can be outsourced.
There is an implied threat in that statement but also an opportunity that I think does a great job of defining what continuous improvement means. Working within an organization provides an unparalleled opportunity to truly understand the needs of a customer base. An IT department that truly understands their customers, whether they be professors, students, doctors, or plumbers, has a chance to not only respond to customer requests but to anticipate them with a level of accuracy that cannot be matched by an outside agency. By working within the organization, we can identify the problems and provide the solutions. This means going beyond our job descriptions and beyond our direct managers and embracing that our jobs mean to serve our customers, whoever they might be.
At the conference, one of the most common questions is “What do you do?” We all work in IT/Telecom but we all know that means different things to different people. I found myself always giving a two part answer.
I manage a team that centralizes network support for local building networks – my job.
I invented our documentation/labeling scheme for networks and constantly tweak our systems management and Pinnacle database for error correction – what I do.
The first line is a good summary of my job description. I show up day after day and make sure that our new network deployments go smoothly. Sometimes, like all IT workers, I show up after hours and replace critical systems so users don’t experience the downtime associated with maintenance. I train staff and attend meetings to keep projects going smoothly.
But, that second line is where I make a difference.
Over the past ten years we have identified and solved problems that no one knew existed. By constantly improving our documentation, we have raised the bar, both for our own performance and for our customer’s expectations. I will never forget the day one of our core engineers (switch and router jockeys) publicly complained that the jumpers plugged into his router were not labeled. Some of my staff were understandably defensive. I loved it. Just one year prior, he wouldn’t have considered that a failure at all. With one very loud complaint, he publicly validated the utility of a process he disdained just one year earlier.
Each step along the way of refining our documentation methods we have identified problems and solved them. We have looked at what many consider “the cost of doing business” with an eye to what we can do to remove those barriers. This is something we can do as members of an organization that would be problematic for an outside agency. Along the way, we’ve created a system that truly sings.
This year we’re turning our attention to our Outside Plant cabling system. By the end of the year I expect we’ll have an accounting of our outside spaces and pathways that will let us document the conduit path of newly installed OSP cabling. Installation of our OSP cabling has been outsourced for years. UF personnel are leading up this documentation project.
In identifying and solving problems that are less evident to outside agencies, we have found our own path to continuous improvement.
I have to admit, I’m a bit less skeptical of this latest buzzword.
Thursday, March 17, 2011
But, there is something judgmental in a formal evaluation that I do not enjoy. Giving advice as a friend carries completely different connotations than advice as a manager. A manager’s advice always seems to carry a bit more menace. Not only can I discuss the consequences of improper behavior but I can bring them to bear as well.
I am not a naturally cheerful person but I am a bit of pushover sometimes. I truly believe that proper behavior rewards itself.
This brings me to the point of this blog post. I’m finding that a number of my evaluation and workflow discussions revolve around a simple idea: responsibility.
Most people address responsibility by enumerating the tasks that a person can be held culpable for not fulfilling. Current legal systems and HR systems seem to support this notion and the idea filters into almost any conversation about a new task. Yesterday, I enjoyed watching a conversation between our networking and facilities managers. One of our buildings had a plumbing problem and they were debating who should be responsible for following up on the work order with our physical plant departments. No one wanted to be responsible for following up. Our facilities rep kept dodging the question until finally our networking manager asked if anyone thought networking should be following up on plumbing problems in our main building. The issue was tabled.
I tend to think of responsibility as empowering. I think any project manager worth their salt believes the same.
A project manager for a new construction project will never lift a hammer. They will never lay drywall. But, they know that they are responsible for every facet of that project. While that responsibility carries culpability, it also carries status. That project manager can intrude on any tradesman, any inspection, and any schedule associated with the project. That responsibility justifies almost any action that may be necessary to complete the project. Except for regulatory restrictions, almost any process can be set aside if it interferes with the progress of the project.
We have all dealt with staff that like to say “That’s not my job” or “I can’t do my job because John won’t do his.” In a situation like mine, we’ve dealt with them for years. If you accept responsibility for a task, people like this are not the roadblock they appear to be. It is your job to find a way over, around, or through them.
There’s a speech I often give my staff. I’ve asked them to repeat it back to me when I need it.
Whenever they begin to claim that they can’t continue a task because of someone else I ask a simple question.
Was this person a responsive in the past?
Did you expect them to be a better employee today?
Is the sky blue?
Is water wet?
Then tell me, who is the smart guy for expecting things to be different today? Did you expect the rain to not get you wet because it’s not fair? No, you carry an umbrella. Be the smart guy in this exchange and adapt. We all have our responsibilities and roadblocks. Responsibility means finding a way past them, not finding a way that absolves us of blame. Get it done. Move forward.
I can’t count the number of times I have done things that were not my job in order to move a project forward. Sometimes others don’t approve but the project keeps moving. No one complains when the project is a success.
The good employee, the good manager, is the one who finds a way to get it done. Keep moving things forward. And that is what I mean by taking responsibility. Those that take responsibility don’t just accept culpability; they take that power that comes with it. They take that culpability and transform into an empowering force to get things done.
They don’t accept responsibility, they take it.