Why can’t IT do what we’re asking?

It goes like this….

IT – “we can do whatever you want, but you need to specify your requirements”

Business Team – “why can’t IT do what we’re asking?”

I don’t know how many times I’ve been part of this conversation and amazed by the difficulty of achieving understanding between IT and their business colleagues, and the ease with which misunderstanding becomes entrenched. My husband is an IT consultant, so we have both experienced this problem, from both sides, at work and, of course, at home!

The problem here is that both sides assume that the other is responsible. Worse than that, the communication gap is so large that neither side in this conversation is really understanding the other. Then, the reactions of each group can lead to a negative spiral that makes things worse. Techies either want detailed requirements, because they are tired of delivering results that nobody likes, or head off half-cocked and build things that nobody wants. Their business colleagues just want the techies to get on with it and so either give cursory instructions and leave the techies to it, or give detailed instructions that define the solution to the problem even though they aren’t the software experts.

What is really needed is to break down this communication gap and to begin collaborating. Here’s how:

Firstly, understand that this is not a linear process: One side, or the other, giving a very detailed description of what is required, or what is available, doesn’t communicate to people who don’t speak the same language, or understand the others’ role. Software development is a creative process and is complex, so it needs effective communication that both sides of this divide can understand. Communication is not one-way, its not even two-way, it has to be iterative, or circular: A conversation in which the players talk around and around, explain things from their perspectives and gradually each side gets a better appreciation of what the other does, wants to do, and what they mean.

Secondly, DON’T start off by detailing the solution. Get the IT techies and the future system users to do a ‘visioning’ exercise together, focussing on the business not the technology. Describe what the business does, what it wants to be different, what the perfect future looks like. Keep steering the conversation away from how to solve ‘the problem’, because the techies will want to revert to this and their business colleagues will follow trying to be helpful. Explore the problem and imagine what you would like to see from the perspective of the users of the system and not the people who will build it. Take time to imagine what it will be like when the new IT system works and makes your lives better. Don’t even think about the tools and resources at this stage. Then, when you do get round to defining system requirements these will be based on small, discrete, and useful features.

Finally  work closely together, both business and IT, share the ups and downs of the creative process. Enjoy the successes and working through problems and new ideas together. Review new features of the system as it evolves, so that both can see, and more importantly communicate, where it meets their needs and where it doesn’t. Software development needs steering towards success, not aim and fire. Its not a ‘Plan, Do, Finish’ kind of thing, keep going and it’ll get better and better.

Here’s our (slightly tongue in cheek:-) 1, 2, 3 guide to bridging the gap:

1. Talk in circles

2. Don’t specify the solution

3. Don’t finish the project

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s