Lost in Translation

The more parties there are in a project, the greater the translation overhead.

When someone commissions a piece of work, they have a vision in their mind’s eye of what they’ll be getting at the end of the process. When you’re commissioning a painting or a sculpture, you want to be surprised and delighted by the artist’s creativity – when you’re commissioning technology in a corporate environment, surprises are rarely good news.

This is primarily because where the relationship between artist and patron is often long term and one on one it can take a few twists and turns along the way, but in technology projects there are numerous people involved in bringing a new thing into being, and surprises put relationships between them under extreme pressure.

In all but the smallest organisations the person who provides the money for a project is not the person who will be performing the work to make it happen. There is a supply chain, which can include a ton of people, but for the sake of argument let’s say there are four main functions:

  • The Exec: the person who sponsors a project and signs off the money;
  • The Client Lead: even in an entirely internal project, there is usually someone who acts as client on behalf of the Exec;
  • The Project Manager: the person responsible for the delivery of the project;
  • The Project Team: business analysts, system architects, developers, infrastructure guys and so on.

 

Each function has to translate what the others have said into their own context, and as when using the babelfish app to translate between languages there is a delicate balance between taking things too literally, and applying too much interpretation that is by definition clouded by your own perspective. If you manage to agree a document detailing scope, or a set of requirements, everyone in the chain will have a different perspective on what each element actually means – a phenomenon that Ryan Singer at 37 Signals calls the Illusion of Agreement.

The first step in the right direction is to make an effort to understand what your function wants from the project – what is actually important, and then do the same (less perfectly) for the other functions. This is the classic stakeholder map – a useful technique that should be used a lot more than it is.

There is no silver bullet for maintaining a shared understanding – it is hard work, and involves listening more than talking, but even if its only demonstrating that you’re trying to understand other people, a little effort goes a long way,. The alternative is the big reveal: where you show what you’ve got, and the Exec says ‘that’s not what I’ve paid for’ and walks out of the room.