Set the stage for successful collaboration

Invest in clarity

Why do the business and technical sides of an organization so often frustrate and disappoint each other? This is the third of four articles in which I explore that question, along with some possible solutions.

Building management dashboards has become common practice in organizations. Ignoring them is almost as popular.

Most of us have seen the dashboards that go unused because they were poorly conceived to begin with.

We don’t have to tolerate this waste of money, time and goodwill. In this article I will explore ways to lay the foundations for successful collaboration between business and technical teams.

Start strong by ensuring that both teams are speaking the same language, that they both understand the business outcome that the project is meant to deliver, and that they share the same assumptions.

Without these three foundational requirements, the project is likely to end in misunderstandings and recriminations.

In my experience, it’s best if everybody adopts the language of business: outcomes, dollars, Return on Investment et cetera. That means that the tech team can’t hide behind T-shirt sized estimates that abstract away the cost, but they are allowed to have a range of dollars because technical development is uncertain.

Meanwhile, business folks then need to use the estimates from the technical team to prioritize projects. You have to trust what the technical people are telling you about the effort and time required. Projects don’t become easy just because the business team doesn’t understand what’s hard about it.

The business folks can (and should) explain more about which requirements are optional if they do want to reduce the investment. The technical folks should highlight which requirements are driving the cost. For example, “real-time reporting” is one of those sneaky requirements that can be extremely expensive to achieve.

It’s worth investing the effort at the beginning to understand what the business hopes the project will enable it to do. The business folks should describe how they expect to use the output, and the technical folks need to highlight any problems based on their experience. They build these systems every day, and have seen which ones can fail.

Collaboration between the teams can help discover better ways to give the business what it wants, for less cost and time. Equally, once the business team understands the investment needed, they may decide that they can live without one or more of the original project requirements.

Iteration is crucial. You can save a lot of money and heartache by making your starting point and first few updates or iterations about “how do we want to tackle this? What don’t we know that we need to figure out?”

We often learn things as we’re building a solution that changes the potential return. By understanding the plan up front, the technical folks can keep an eye on how that ROI calculation changes.

Existing frameworks for “Risk management” typically focus on contingency plans that enable you to deliver the planned technical results when things don’t go your way. However, for the technical team the things that go wrong are often their clue to cancel the project entirely, or at least pivot to a new approach.

In the next article, the last one in this series, I will describe the value delivered by investing in someone who is fluent in both business and technology, and can act as bridge and translator between these two worlds.