The Agony Of Talking With IT
Written by Todd L. MichaudNovember 11th, 2009
Franchisee Columnist Todd Michaud has spent the last 16 years trying to fight IT issues, with the last six years focused on franchisee IT issues. He is currently responsible for IT at Focus Brands (Cinnabon, Carvel, Schlotzsky’s and Moe’s Southwestern Grill).
Do you know someone who irritates you so much that just the mere act of them taking a breath to speak puts you over the edge? No matter what they say, it just rubs you the wrong way. I think most people know someone like that. Unfortunately, for many businesspeople, that person is their IT partner.
Whenever the IT person tries to explain a technical problem or defend a business case, the person on the receiving end hears nails on a chalkboard. Couple that with a blank stare when pressing business issues are being discussed, and you’ve got a recipe for a rumble.
Over the years, I have heard from many business partners–especially franchisees–that they get very frustrated when talking to IT people. There is a significant barrier when it comes to the language. The business partners are frustrated that the IT people don’t understand their language (terms like COGS, theoretical food cost, sales/labor hour, etc.), and they have no idea what the IT person is talking about (terms like Web services, ASP, dynamic IP addresses, etc.). This barrier creates friction that can result in a not-so-subtle “stink-eye” from across the room.
The problem is only getting worse. First, technology vendors are creating new features and functionality much faster than they are retiring them. As a result, the catalog of things that most IT people need to know is constantly growing. Second, as technology advances and becomes more complex, so do the explanations behind it. As a result, IT people often focus on understanding the new technology and fail to learn how to properly translate that knowledge to the layperson.
Here are some helpful hints when it comes to talking about technology to your business partners or franchisees:
Let me give an example. I am in the process of launching a new inventory management package for one of our brands. This new system will replace an existing manual process with technology that greatly improves efficiencies, thereby resulting in dollars to the bottom line. The new system has a bunch of great features like integrated supply chain, theoretical food costs, recipe management, etc., etc. The training course for this system takes two full days to fully learn both the basics and the bells and whistles. I’m sure many of you already have a similar approach in place.
The mistake that many IT people make is trying to explain all of that detailed information right out of the gate. Remember that the goal is to explain what the system does, not how it does it. Here is the business case that I plan on presenting to our franchisees.
Saving You Money
- Reduces food cost, waste and theft
- Offers tighter inventory controls
- Allows you to see all stores’ data on a single screen
- Compares data against your market, DMA or entire system
That is it. It is simple, easy to understand and uses business terms. It does not give unnecessary detail about how the supplier interface works, nor does it talk about the hundreds of reports that can identify variances or the fact that it is a Web-based application. I also don’t go into detail about how not all reports allow you to see all stores on one screen. (Some do, and some don’t.) What is important is the sentiment; details will be provided later.
Many IT people get caught up trying to explain all the particulars right up front. Going into that level of detail at this level of conversation will just create confusion and frustrate your audience. Some businesspeople mistakenly think that IT people are talking about these details using technical terms and acronyms in an attempt to make them feel stupid. Most times, however, that is not the case. The reality is that the summarization rarely conveys the entire point and that the IT person is simply attempting to be complete in his or her statement of a technology’s capabilities.
IT people also tend to talk about what is comfortable for them, which is often technical information. But it is important to make sure that IT people understand, at a detailed level, how the business works. They need to spend time working with businesspeople to understand the company. IT should be closely tied with operations, marketing, supply chain or whatever business units that it supports. If, for example, an IT person is supporting the operations team, that IT person should think and act like an operations person who knows IT, not as an IT person who provides technology solutions to operations. This distinction can be a hard mindset to change, but one that can pay dramatic dividends in the future.
What do you think? Love it or hate it, I’d love to gain some additional perspectives. Leave a comment, or E-mail me: Todd.Michaud@FranchiseIT.org.
-J- R
November 12th, 2009 at 11:28 am
Excellent article, Todd. Great points. IT must realize that many users of their systems, particularly forecasting, merchandising, and category management are needed to be used by folks who went to the side of the university where “No math was required.” Their skill sets are different.
What is alluded to here but not overtly mentioned is that that business process must change to obtain the ROI benefits. That needs to be communicated as well. 75% of IT projects fail to meet ROI objectives because of this one point.
Thanks for a great article.
November 13th, 2009 at 11:54 am
Business analysts can help bridge that gap!
November 15th, 2009 at 8:43 pm
Thanks for the comments!
Greg, you bring up a great point about the business process change. Often business users expect “magic” ROI, without realizing that the true ROI comes from enhancing the business process. If they are not willing to change, then the technology implementation often is a waste of money.
Jen, I totally agree with the business analyst comment. The challenge with smaller IT shops is that it is very difficult to justify the role. Just like the movie Office Space: “I am responsible for taking the customer’s requirements and giving them to the Engineers. Can’t the customers just talk to the Engineers? No! I am a people person! I have skills!!!”
In most small IT shops, the traditional Project Manager and Business Analysts roles are both critical and extremely difficult to justify.
Thanks again!
November 16th, 2009 at 12:34 pm
Todd, while you are correct that it’s difficult to have an IT business analyst or seasoned project manager in small shops… it’s certainly not out of the ordinary to have on-boarding with all employees including IT folks that would among other things mean spending time in a restaurant to understand the business. IT people don’t know the terms COGS, margins, etc because they haven’t always been exposed to them. In restaurant training is key to having the individuals helping to run an organization understand how the business is measured / evaluated by the operators.
A large part, in my opinion, of IT projects fail to materialize their ROI goals because they do not have accurate requirements set from all participants. Better understanding about what the client needs often leads to other discoveries about the system and a deeper analysis of the project objectives. This further develops the need for a business analyst or for the IT person to be programmer / analyst.
November 16th, 2009 at 2:51 pm
Paul,
I couldn’t agree with you more about the lack of accurate requirements being one of the leading causes or ROI miss. “Tell me what you want.” turns into “Tell me what it can do.” Unless you are following a Agile methodology, the “big unveil” can be a disaster!
I also agree about in-restaurant training. In my previous role, we were 100% franchised, which made that difficult. Now, all my IT folks spend time in each of my brands to learn them from the ground floor, and when we meet with our business counterparts, we talk in their terms.
Thanks again.
November 19th, 2009 at 1:41 pm
My big frustration with IT is about attitude. Many of the IT folks I deal with have an attitude that they know more than me, even about topics that they aren’t tasked to manage.
For example, my company’s IT department installed web filtering software that started blocking websites that our staff use on a regular basis, for work purposes. The IT department felt that those sites were wasting time and bandwidth. But they weren’t tasked with managing employee time and didn’t consult with any downstream managers about their unilateral decision. They also didn’t look into the true cost of bandwidth, which was costing less than it cost the company to run a refrigerator in the employee break room.
That example is just me venting – there are many more examples that impact more critical business systems, where IT overrules business decisions without consulting the very people they are tasked with helping.
I’ve seen this attitude at other places I’ve worked, and I don’t feel that C-level management understands how much of a negative impact it can have. Or, maybe I’ve just had some experiences with bad IT groups?