Interface between technology and business

The interface between technology and the business side of the team is always something similar to friction between plates in the theory of plate tectonics and with very similar side effects! 

If you search the Internet on this topic you are bound to come to the swing in a tree cartoon. It describes the situation very well in pictures and I give an example below. (Side note: There is surprisingly a lot of variation of these cartoons, from black and white to color with variations on the actual content too. They seem to have been around from the pre-computer age and have just been adapted to the newfangled contraption and all the problems associated with its management. This tells us once again that the management of IT projects is just a new variation on an old theme. Here is a very interesting account on the swing cartoons and their origin.)

So the question is how to make the interface between technology team and business teams friction-less? And I think the answer lies in first accepting that you can't - you can only try making it better lubricated. With this first acceptance in mind, here are some of the things we as a custom software development company do to keep the interfaces lubricated well.
  

1. Let there always be a middle man

If there is a middle man in between the business and the technology teams then that middle man can translate each other's language. The classic middle man is the CTO or project managers but smaller projects we set one of the roles as the middle man role. We have seen that the putting on the middle man or interface layer hat changes the mindset of even hard-core developers and pretty much everyone can do the job but obviously the project managers tend to be better at it since they have more experience. Note one thing though, our project managers are always ex-developers so they can speak the techie language well and so it works pretty well for us. If you are one of those unlucky places where the PMs of software projects is not a techie, then this might just add to the friction, so be careful.

2. Let everyone speak a lot before anything is done

Sounds obvious right? But you'd be surprised at how many projects this is not done properly. We let every member in the team talk a lot about requirements - breaking the rules of not having prolonged meetings. We do these meetings as many times as possible at the cost of making everyone irritated and bored. We have found that this is a small cost to pay when you compare it with the benefit of a better understood set of requirements.  

3. Always do a "prototype" 

Sometimes the "prototype" is not something you'd call a prototype in a tech crowd! It could be half working quick and dirty app, or it could be just a bunch of pictures glued together in html pages some parts of which are clickable. But whatever it is, it helps clarify a lot of issues and makes the business teams see how things will look like or may work. It gives them the chance to scream or modify their expectation or modify their plans.  

4. Have regular meetings to show case the product in its current state

We call these internal product demos. Ideally they should be done with the project manager showing it to the business people as potential customers! The whole tech team should be there, to see the reaction and hear the feedback. It gives directions and food for thought about what is being built for the whole team - business and tech alike. 

5. Let business team see the product at any time

This is the classic Agile recommendation that the stakeholders should be able to see the current state of the product at any time without going through any red tape. This is actually very easy these days with build systems and automated deployments frameworks in place. The whole thing should be automated, so that at the click of a button the business guys can run the app and check things out.  

N.B. Just in case you are new here: we are a custom software company  in Bangladesh making custom web, desktop and mobile apps for other companies and being very good at it! Check out this page to know more about our software development work culture and environment.