IT is a customer service field and we need to be able to do whatever we can, within the limits of our resources and regulations, to achieve “Getting to Yes” (Wikipedia, 2019) with our customers whenever we can; however, there are going to be times when we are just going to have to say no. It is never easy, it always raises more questions than it answers, and it often raises the ire of our customers. Yet the fact remains, there will be times when no is the correct answer. Folks may not like it, but it is what it is.
I know some people who have no problem at all saying no to a customer. They are usually the ones who say no quickly and often; like they are playing a marathon game of word association with their therapist. Most of us have a much harder time saying no to our customers. We want our customers to be happy. Some will even say yes to a request and then avoid doing it. That is worse than just saying no.
What to do When You Have to Say No
When can or should we say no and why? Much of the time, it boils down to four things:
- You are prohibited by regulation;
- You do not have the resources;
- It is not technically feasible; and/or
- It is not or cannot be ITCCB, ATO or FedRAMP approved.
Saying No Because it is Prohibited by Regulations
This one is simple. If the regulations says you cannot do it, then you cannot do it. Especially if it falls under security/cybersecurity regulations. That said, you had better have a copy of the citation in hand when you deliver the “no” news.
Example: I received an email from a colleague at an embassy overseas that said that because of the implementation of a new inventorying program at the Department of State, three other tenant agency offices decided that it was now the IT Department’s responsibility to manage the inventorying for their office radio program. They insisted that because the new Department of State regulation for the inventorying program did not specify that it was “State Only” and that it did state that “all IRM equipment[1]” was to be inventoried that it was now their responsibility. Apparently, the management office did not back this person up (see Standing Up for Your People for some insight on this) and put the onus on him to prove them wrong. He was new to the job and although he had read my compendium, he didn’t find anything about the subject as it pertained to inventorying (something I am remedying for the next edition of my compendium). So, he came to me. That was a good idea on his part.
He may be new to the job, but I have 25+ years and I know the regulations very well. Within minutes, I had five different citations from the regs to back up his position. One of these citations was crystal clear, “Tenant agencies that own radio systems are responsible for maintaining their equipment, their inventory of operable spares, and coordinating repairs or changes to their network with post management.” (FAM/FAH, 2017, pp. H-744) With the information he needed in hand, he was able to tell those who were expecting him to start doing their work for them, “I’m sorry, but the regulations will not allow this. The answer is no.”
Saying No Because of Limited Resources
Since joining the Foreign Service in 1994, I have heard the rallying cry from as far up the chain as the White House and Capitol Hill that we must tighten our belts and “do more with less”. At some point, something has to give, and we have to step up and take a stand. If we overwork our staffs, they will burn out and leave the organization. It happens all the time and it happens everywhere. When resources are stretched to their limits, or worse when they are cut, a decision must be made as to what products/services can be offered and how they will be executed. This can often mean not performing them at all.
Example: At one of my postings, the embassy was growing due to expanding mission requirements. A new office was to be opened with 25 people to support. Over the previous five years, the mission slowly expanded and nearly doubled in size; however, the IT staff was never increased in kind. An additional 25 people was putting my staff beyond the breaking point and no one had taken this into account as the mission expanded. When I was tasked with ensuring that these 25 positions were equipped with what they needed and that they were added to our service catalog, I immediately requested additional personnel to handle the increased workload. The request was denied due to budget cuts in an already underfunded budget. Something had to give.
So, I made the hard call. Our service catalog stipulated that we were to respond to service-calls within a 20-minute period and to resolve the call within two hours. This was not possible with the number of service-calls we were receiving due to the increased staff. We were already having issues with it prior to the additional 25 people (and rightly so, since no increases were made over the past five years). I informed upper management that our response times would be increased to 1 hour to respond and 4 hours to resolve. I presented the metrics that clearly demonstrated the increased workload over the past five years (number of customers served, number of service-calls logged, etc.) with no increase in staffing to cover the gaps. I then showed them that two employees left because of the increased workload with no compensation (raises, promotions, etc.) to incentivize them to stay. If we weren’t going to add staff, then we had to cut response times, or the entire staff would burn out and leave. The only other option was to eliminate the 25 new positions from our service catalog. It was then their choice which we would do. They agreed and the service catalog was amended to reflect the longer response times.
Saying No Because it isn’t Technically Feasible
Sometimes, a customer may have a great idea on how to do their jobs better, but you may not have the technology required to help them to achieve their goal. Applications and hardware that are used on U.S. Government systems and facilities must also pass rigorous tests before they are approved for use both within the organization through its IT Change Control Board (ITCCB) or across the Federal Government through the Federal Risk and Authorization Management Program (FedRAMP). In addition, a technology itself may not be mature enough to even be feasible for submission for approval (known in the Federal Government as Authority to Operate (ATO)). (Weedmark, 2019)
Example: One day I was approached by a customer who had a great idea. His office had been using WhatsApp to communicate with one another during shelter in place exercises (the application used by the embassy would only allow for communication between the employee and the embassy). He wanted to be able to use both systems and have it tied to his cellphone and office phone; all in one application. That way, no matter what device he had, he would be able to seamlessly talk to anyone in his circle. He could be on his cellphone or office phone but talk to someone via WhatApp (using some kind of text to speech software and an interface to bridge them together.) Mind you, I liked the idea, but the technology to do this did not (and as far as I know still does not) exist. We also didn’t have the kind of in-depth development expertise to achieve this lofty goal either. I explained this to him and told him that, unfortunately, the answer was going to have to be no. At least for the time being. He understood completely, although he still pings me from time to time to see if anyone out there has come up with anything like it. I actually do keep my eye out. Maybe someday.
Can it get ITCCB, ATO, or FedRAMP Approval?
If you can get past the first three gates, then whatever hardware, software, mobile application, or cloud application that is required to get the customer what they need, the final hurdle is getting approvals to work on an organization’s network or device. It may be approved already, which means that it will likely only require a quick approval from the CIO and CISO to be used for the purposes intended; however, it may need more. This will depend on a variety of factors. If you can secure the necessary approval(s), then charge forward. If not, then you will need to explain to your customer why it can’t be done. Whenever possible, if you can, see if you can secure the approvals needed to help your customer achieve their goal; otherwise, you will need to tell them no and why.
It Doesn’t Happen all the Time
These are just a few examples of when to say no. The good thing is that it doesn’t happen all
the time. If it does, you should be
reassessing your customer service strategy and doing everything you can to
ensure that you are doing your best to meet your customer’s needs. However, when you absolutely must say no,
make sure you have the information needed to explain why to your customer, so
that they understand you are not just saying no because you don’t want to do
it.
[1] Unlike IT employees in the business world that only manage and maintain IT systems, Information Management Specialists in the Foreign Service manage and maintain IT systems, telephone systems, data communication systems, and radio networks under the Information Resources Management umbrella.
Works Cited
FAM/FAH. (2017, July 26). 5 FAH-2 H-740 Maintenance Responsibilities. Retrieved from 5 FAH-2 Telecommunications Handbook: https://fam.state.gov/Fam/FAM.aspx?ID=05FAH02
Weedmark, D. (2019, December 4). What is Authorization to Operate? Retrieved December 4, 2019, from Chron: https://smallbusiness.chron.com/authorization-operate-ato-81858.html
Wikipedia. (2019, September 21). Getting to Yes. Retrieved from Wikipedia: https://en.wikipedia.org/wiki/Getting_to_Yes