This T-SQL Tuesday is hosted by Steve Jones (blog | twitter) and the topic he proposes is: "What issues have you had in interacting with the business to get your job done."

Jeremiah Peschka (blog | twitter) has a good take on the situation I've encountered most often, so I'll piggy-back on what he has to say.

They Don't Know What We Know:

This is especially true in IT security. When I lament IT pros and developers making nonsensical assumptions about IT security, it's because it's their job to understand the rudiments of it. I don't expect a business user to understand the ins and outs of IT security. Nor do I expect them to understand deep database concepts or programming methodologies or anything that is related to our jobs as IT folks that don't relate to their job on the business side. We can roll our eyes, we can make snide remarks, and we can do all of these things, but the big question is, "What's the point?"

The point is we want to get the business side to understand enough of our perspective to make an informed decision. That means we need to educate them, but we need to do so in language they understand with a focus on their concerns and how our concerns match up with theirs. If we do anything else, we're not helping the situation. We may be making it worse. And then they get upset at us because we seem to be elitist and smug at their lack of knowledge and we're frustrated at them because they aren't understanding what we know.

We Don't Know What They Know:

So let's stop pretending that we do. So how do we get what we know and the concerns that we have with the concerns that they have? We treat the business side with respect as fellow colleagues and we talk with them. We try to understand it from their side. And if they see us trying, they probably will, too. That is, if they haven't been burned by years of IT acting like I described above. Jeremiah hits it from the side of trying to solve their problem with some elegant solution. I'm going to attack it from a different perspective: find the real pain points.

Way back when I was an ASP web developer, the first big project I had at an organization I just started at was to revise the intranet application to make it more usable for the business. My boss asked me to do something that took me completely out of my comfort zone. He wanted me to interview every department head in the organization to determine as to their opinion about what was already on the site, how this could be improved upon, and what kinds of ideas they had to add to the site to make it better for them. So that's exactly what I did. And it was a very enlightening experience.

We on the IT side had some ideas as to how to improve the site. But after the interviews I found out that the biggest issues, the ones causing the users the most pain and the reasons they weren't using the intranet site, weren't ones we identified. Most of them centered around document and event management and being able to have a crew of people be able to do those tasks and to be able to quickly determine who was able to do those things. So one of the first things I set about doing was building a security model that permitted the type of functionality that they wanted. We had our own idea of how to do the security. Turns out what we thought was easy and useable wasn't exactly so easy for the business side. And lo and behold when we rolled out the intranet with the functionality I found that they wanted, we got some wonderful feedback about how it met the need, was a beautiful solution, etc. We had built the elegant solution we had wanted to build all along, and we did it by sitting down one-on-one and talking at length with the business folks about their real needs.

This sounds an awful lot like when Jeremiah talked about, if you read his post. But I told you I had a different take on it. It's not just that we solve the problem, but we show ourselves to be valuable to the organization. Think about it, if your management has to let somebody go, are they going to let go the one who consistently talks with the business folks and delivers what they need or the one who reads the specs, thinks he or she has it figured out, and then delivers a solution that ends up pushing the schedule because of the rework required? And even if it's not a someone has to lose their job scenario, which one would you seek to reward and promote? Which one is your boss' boss going to hear good things about and consider a go-getter? Exactly.

We're on the Same Team:

Too often we split business versus IT. When I give the presentations where I include how to present quantitative risk to the business to get your security product bought or your extra time approved, I talk about that fact. Ultimately a security breach impacts everyone in the company. A bad application that causes work issue does, too. And so does a well-built app that is suited to the needs of the business. Less time for each task means more tasks can be done in the same amount of time means the possibility of greater revenue. And we've got to think, "Hey, we're on the same team!" In the quantitative risk example, I talk about how some of the estimates have to come from business. And when we gracefully approach business to get those estimates, that means that the numbers we're putting together isn't just IT's numbers. They are our numbers. And when they are our numbers, then you have business users helping you convince other business users of the need to give you what you want. That's what teamwork does. If we treat business folks not as trolls who have come out from under their bridges but rather partners whom we respect and listen to, we'll see more success. And that helps all of us.

"You Can't Change Their Attitudes Until You Change Yours:"

Words similar to this were spoken to me by an old mentor when we were talking about coaching kids in soccer. I remembered these words and I applied them. That's why when I coached soccer, I was always upbeat and positive and encouraged them to do the drills or make the play, especially if they didn't believe in themselves. If I had a negative attitude, I certainly couldn't expect them to have a positive one. So if you're getting friction from the business, if you're having issues, the first thing to do is ensure your attitude is right. Over time you'll win some folks over. And those folks will help you win more folks over. Now, your attitude has to be genuine. You have to believe these are partners you can work with. You have to care about their pain points. And you have to want to work with them. Falsehood will eventually be seen through.