With some people, it’s easy to communicate. With others, it might not be even possible. With IT, it may be a completely different story, as people from this profession are, sometimes, weird.

Years ago, when I started dating my wife, she told me she never could communicate with IT people very well. It didn’t matter was that a professional contact or a private one. Languages used by both sides, even though technically the same, were different. I have no idea how we’ve overcome this issue, but I always joke that I used a different set of drivers to achieve that 🙂

It’s not easy to communicate precisely with anyone, and when it comes to IT, it may seem impossible. Why? I think because of mental processes on both sides – IT people don’t like to do be treated like babies in the mist and precisely told what to do in their sandbox. At the same time, they think all those people who request something they have to implement, don’t know what they want. On the other hand, all those people who require IT to do something think those people won’t understand what needs to be done. Therefore they create solutions which IT should directly implement without thinking. 

With this approach on both sides, many projects will fail. And that’s not the problem of IT. It is not the problem of business people. It is not even clients nor stakeholders problem. So where the issue lays? Everywhere between these people. Perfect communication is the key to a successful project. Sorry for decreasing value of every group, but business people, IT, marketing and so on are only tools to fulfil client’s requirements. 

I’ve worked in a project where we, IT people, were treated as kids in the mist. When we asked questions about ordered functionality, we were told what to do. „In this place, if the system adds a button which will invoke a function that recalculates something and sends an email to some group. After that this windows should close”, blah, blah, blah. You may ask „what is wrong with that? Everything is clear and should be easy as pie”. I say yes and no at the same time. 

I say yes, because it frees IT from thinking, therefore from being responsible. That’s tempting, sometimes even too much. I always can say I did my work precisely as it was ordered. It makes business people/stakeholders/whoever ordered functionality think IT behaves like babies in the mist. And to prevent it in the future, more precise documentation/specification should be delivered, as IT doesn’t understand what has to be done. 

I say no, as I am not a kid in the mist. I’ve spent years learning stuff which sole purpose is to deliver to stakeholders/clients a complete program or functionality which resolves their problem or problems. I don’t need exact instructions which are set in stone, which do not fit to the rest of the system and I’ll have to do some workarounds and hacks to connect it in a consistent way to the rest of the system. 

Friend of mine told me once „if you want to build a monastery, you have two options. The first one is to instruct every single worker, where the wood is stored, where the stone is stored and where all other things are placed. Next, you have to manage those people what to do with that, all the time keeping your eye on them and instructing them over and over again. After some time, you may have built something close to the monastery. Or not. Most likely, the second option. However, you still have the second option. You can tell workers where wood, stone and other things are stored, and you can tell them what kind of goal they have to deal with – the biggest monastery in the known world. You’ll have to describe them how you want it to look like, but if you precisely describe the goal and possible outcomes, your workers will work without you keeping your eye on them all the time, and they might give you some valuable opinions which may lead to achieving the goal faster, cheaper and better. Which option do you prefer?”.

Each person works enormously better, knowing why something has to be done. There is no difference for IT. In the project I worked for, for at least a couple of months, I tried to dig this information from business people. Unfortunately, I failed, and that was one of the reasons why I left. If I had that knowledge, most likely I’d stay a bit longer. 

So to communicate with IT in the best possible way is to include in the documentation, as well as on each meeting with them, information about the goal this change or functionality should bring to the client. Don’t speak about solutions, talk about problems as creating solutions in the software world is an IT thing. Try not to bring solutions instead of problems/goals. I know everyone likes to find solutions, but when you aren’t a person who is designed to implement it, most likely you’ll find the wrong solution which will pollute implementers minds and limit them to the solution proposed. With the correct approach, IT can focus on their work and business/stakeholders/whoever may focus on theirs. Therefore business/stakeholders/whoever stops thinking about IT as babies in the mist and IT starts taking responsibilities about the project they commit to. Everybody wins!