Speaking to your Geek -- Bridging the communication gap between business and IT.

OK, its a common cliche, the socially awkward yet arrogant and slightly insulting IT guy clashing with brainless, CD-tray-as-cup-holder business user. In reality, most IT staff don't resemble the Simpson's comic-book guy and most end users are fairly knowledgeable when it comes to their desktops and office tools.

However, every day, I witness exchanges that highlighted for me the fact that, although we are all becoming more technologically savvy, there is still a divide in perception between those who work in IT and those who don't.

Consider this exchange:

Business: We need you to build an AJAX web application. It should allow customer create a login and, depending on who they are, pull different stuff from a CRM system. It might also need to pull information from our vendors' sites. It will also need to let the users makes some changes to the information that they see.

IT: Well, why do you want it?

Business: (slightly annoyed) It doesn't why, Marketing has requested it.

IT: What vendor systems do we need to interact with, what databases are they running?

Business: We aren't sure yet. It will depend on which vendors join our cross marketing program. Look, I just need to let the Marketing guys know if we can do it and get some ball park costs

IT: When do you need it?

Business: As soon as possible

IT: How big is the budget?

Business: It's not set yet, we are really looking to you to give us a sense of what this thing is going to cost. So what do you think, can you do it?


IT: Sure, I'll need a year and 1 million dollars


Business: Why are you making this so difficult?



Clearly, this is a bit of theatre but it I want to use it as a means to illustrate some common challenges that business users have when communicating with IT and why the person on the other side seems so difficult.

One of the first problems is what a friend of my referred to as "solutioning." That is, asking for a specific solution before you outline the problem. You may be reading a lot about web 2.0 technologies, but AJAX may not be the correct solution to your specific problem or work within your current environment.

A co-worker of mine often responds to solutioning by asking the question that get's people's back up: "why do you want it?" This question is often misinterpreted as a challenge to the asker. In reality what his trying to ascertain is the business requirement behind the request. I've told my buddy the question should be better restated as "What is the specific business needs that you are trying to address?"

When trying to describe a requirement do worry about so much about how but what. For example:

What business need(s) should the solution address?
Who will need to access the solution?
What special requirements must be meet to satisfy the business issues (for example, will different users need different level's of access?
What existing systems will the solution need to interact with?

It is important to remember that IT systems are often interrelated or interdependent and your request may have implications that you are completely unaware of.

The next issue is specificity. All too often I am asked to "ball-park" a solution on less than complete information. When presented with this I've see many IT people default to one of two typical response is to either highly buffer the scope/costs to offset the unknown, or make assumptions about what the client requires.

In both cases, the result is often friction, In the first case, the resulting ball-park figure will greatly exceed expectations (and available budgets). In the second instance, the clients are often unhappy because the resulting solution is based on incorrect assumptions and need considerable retooling (and expense) to meet the actual demand.

Remember you would never to a home builder and ask for "something largish with marble in the kitchen and red brick" You would be specific and go through the plans thoroughly before even breaking ground.

As a tactic in this situation, I often artificially define boundaries and scope within these boundaries. I then detail my assumption and exclusions in the scope document and ensure that I have not made any incorrect assumptions while reviewing the scope with the client.

Three last thoughts to consider when working with IT on a project:

1) Simple is complex. The easier an application needs to be for your users, the more work a developer must do on the back end to make things seem simple. Driving a car is as simple as turning the key and putting the car in gear. It's that simple, because a lot of complex moving parts under the hood hide the complexity from you.

2) Minor changes are not always minor. You may ask for what you think is a simple change, but often changing one element of a system can have a cascading affect. You might just want to add one more field to a newsletter sign-up page. However, that new field much live somewhere, which means a new column in a table in the database. If that table is accessed by other reports or tools, it's quite likely that those must also be changed, and so on.

3) You may want it complex, fast and one budget but you will likely only get two of the three. Adding to scope adds time and costs. If you have a complex scope and a fix timeline, more resources will need to be brought to bear to complete the job on time. If you budget doesn't account for the extra bodies, you will have problem.

When business groups and IT come together, business need to understand that there are complexities that they might not realize and the IT group needs to better communication the reason why they need to know the information that they are requesting.

Finally remember the advice from the back of the Hitchhiker's guide to the Galaxy: Don't Panic.

del.icio.us Tags: communication , scoping , development , IT