Learning how the business side works can yield better IT systems and service.
I just returned from a week of vacation in London, which was fun as always. The great thing about being an American in London is that it forces you to rethink a lot of things. This ranges from driving on the other side of the road (I hope my U.K. friends appreciate that I did not say the "wrong" side of the road) to fries being chips and chips being crisps and so on. Many things seem the same--but not quite.
Obviously the British have no difficulty with these things. It's second nature to them, it's their culture. It is only those new to their way of doing things who have to adjust. This is the same feeling many of our users experience whenever we roll out or modify a system. We roll out systems, processes and programs that perform adequately but somehow never feel natural to our users.
The problem is that these systems are designed for our information technology culture and not the culture of our users. We design them using the terms and conventions we are familiar with and just assume our users are familiar with them too.
The most obvious example of this is the cryptic error messages that we put in our programs. Highly technical with vague phrasings, these error messages often leave users more confused than enlightened.
Our IT culture permeating our systems can be even more subtle. As I was preparing to leave London, I saw British actor, Johnny Briggs, on BBC Breakfast promoting Get online day. This is an initiative to get people that are either unfamiliar or uncomfortable with computers and the Internet to take their first steps with using these technologies.
Briggs was open about his lack of experience and how he learned to accept and even love the Internet. He did admit it wasn't always easy and sometimes it was very confusing. "Who in their right mind would press "Start" to switch their machine off?" Briggs asked. But to IT folks this is "normal," and we fail to see or understand the confusion it creates.
Cryptic error messages and using "Start" to turn off your PC are trivial issues in and of themselves, but they highlight the issue. Rather than complain about how clueless our users are, perhaps we should try to see things from their perspective.
By switching to their culture rather than making them switch to ours, we can increase user satisfaction and acceptance so they'll really use our technology. Just as the painted warnings on the street to "Look left" were helpful to me in London, they weren't always enough to prevent me from almost stepping into traffic. It's only when the system or process and my culture are in sync do things really work well.
The design, testing and training phases are instrumental in gaining user understanding and acceptance and in getting the process and culture in sync. But there is more we can do.
The process should really be ongoing and not focus on a particular system or program, but rather, on merging our culture with that of the users. We need to not only understand the business of our company and also truly become part of it.
A good way to do this is to get your development (and even your support staff) out of the IT department. I don't mean in an organizational reporting way, but in a true physical sense. Embed your people with the business users they work with. Having them work among your users will give them the opportunity to see all the issues firsthand and understand how the users work. Have your people attend business meetings with your users to get a better understanding of the issues they face. Consider having your people "shadow" or actually perform the users' job for a period of time to get a true first-hand experience of what they are up against. Do whatever it takes to merge your culture with that of the business!
There are downsides to all of this, of course. Your staff may lose some benefit for the normal technical interchange among the IT staff because they will be dispersed. There is also the risk of "clientitus," which can be especially dangerous when your task was to change the status quo rather than to be absorbed into it.
Still, the benefits likely will outweigh the risks. Getting our IT culture in sync with the business requires IT leaders to be creative and manage the risk.
"Different Approaches To Time" photo by Mike Schaffner on flickr
This article is also posted on Forbes.com. Feel free to join in the discussion either on this site or at Forbes.com
If this topic was of interest, you might also like these:
I like your analogy. In an ideal world, both sides should work to bridge the communication gap. Howver, since IT is often considered to be the "guest" in the business' "home country", tenologists would do well to put extra effort into building harmonious "international" relationships.
Posted by: Anjuan | October 28, 2009 at 08:46 AM
Love the analogy, especially as a Brit living in the US!
Just to expand on your articles point and this statement, "The design, testing and training phases are instrumental in gaining user understanding and acceptance". I think it all comes down to creating empathy for the end user. Using User Centered Design processes can be an excellent way to apply empathy to the development process. Methods such as Personas and Scenarios, can not only elicit valuable requirements but also create an empathy in the development team towards the target audience and their perspectives when using the technology.
Posted by: Mark Tattersall | October 28, 2009 at 01:49 PM
Anjuan,
I agree that both sides need to work together to bridge the communication gap. However, too often IT gets defensive and complains that the business side is not carrying its weight. While this may or may not be true it is irrelevant. We should take responsibility and the initiative in improving communications regardless of whether or not the business side is cooperative. As you say we should put in the extra effort in to building the "international" relationship.
Mike
Posted by: Mike | October 28, 2009 at 07:42 PM
Mark,
I like the concept of empathy. It convey the concept of IT being a service provider and understanding and answering the needs of our customers. Thanks for commenting.
Mike
Posted by: Mike | October 28, 2009 at 07:43 PM
I liked how you told this story Mike.
It seems the identity issue - where one feels at home with similar folks - 'causes IT service people to stay close to their cubicle. Another is that being strange because they don't understand their user's language makes them freeze up. It's a hard behavior to crack other than perhaps throw them in a cubicle deep into "other" territory and take away their IT cube!
Put another way, I say, "We're service folks. How are you going to serve your users/customers when you're in your cube far far away in a different galaxy?"
But by the same token, our good users also need to reach out and make IT folks welcome and reach out. It's not Aliens vs. Predators either.
Cheers,
Posted by: Lui Sieh | October 29, 2009 at 11:30 AM
Lui
I agree - that is exactly what I meant when I said "Embed your people with the business users they work with. Having them work among your users will give them the opportunity to see all the issues firsthand and understand how the users work." You also raise a good point about the user needing to reach out and welcome them into the group as part of the team. Thanks for commenting.
Mike
Posted by: Mike | October 29, 2009 at 07:03 PM
Just like British people can understand American English (reverse compatibility) but not vice versa, often IT can understand the Business (they have to to understand how the technology is to be run). However the Business are like the "Americans" in that they cannot understand IT.
This is one argument for IT driving business change.
Posted by: Pete | January 07, 2010 at 06:13 AM