Does your business need a therapist?

If you've ever found the going tough or needed a little help in finding the way forward, you might have gone to see a therapist who helped you by untangling some of your most knotted thoughts and working with you to open up a new perspective on life. Therapy is often used as a tool for identifying dysfunctional or negative mental processes, allowing those thoughts and feelings to be transformed in a new light.

Often, businesses need therapists too. Just like people, they can develop dysfunctional processes. For example, information isn't properly recorded or doesn't get shared in the right way. This leads to inefficiency, poor service and sometimes conflict.

For almost any business, software is at the heart of how they work, and it shapes the processes they follow. It stands to reason; having bad software results in bad processes. If only you could get a kind of 'business therapist' that understood how your business worked and shared information, and who could come up with ways to get people working together more effectively.

Well, these people do exist. They can be otherwise known as Business Analysts, System Analysts, Product Managers, Program Manager or UX Designers, but their role is the same. On a simple level, these analysts bridge the gap between users and programmers, making sure the wishes of the first group are met by the skills of the second group in a way that makes sense. They work out what sort of IT systems your business needs right from the off.

"Mostly, becoming a Program Manager [or 'business therapist'] is about learning: learning about technology, learning about people, and learning how to be effective in a political organisation," writes Stack Exchange CEO Joel Spolsky, from a position of some authority. "A good Program Manager combines an engineer's approach to designing technology with a politician's ability to build consensus and bring people together."

You don't have to look far to find a software project that floundered because it was started before anyone had decided what exactly was required. Based on figures from CB Insights, the top reason for startup failure last year was "no market need" — in other words, these companies were building something that people didn't want.

Another issue is building more than is required, coding too far into the future and solving problems that don't exist. "Code should be designed on what you have, not on what you think you'll have in the future," writes Max Kanat-Alexander. "It should be designed for the requirement that you have right now, without excluding the possibility of future requirements."

Building to specific requirements, knowing what you need, and coding towards it is the responsibility of your 'business therapist' (whatever the exactly job title might be). That's why at D4 we value the role so highly: the right person can save a considerable amount of wasted time and effort. We insist on analysing a customer's needs and designing a suitable system before the coding starts, and we think that gives us a crucial competitive advantage.

Of course you don't have to lie back on a couch while you tell us what you need — but it's entirely up to you.