Martin Colebourne

Failure is not uncommon in the software world.

At one level it can be small: software may be delivered late, have poor usability, or fail to provide key functionality. At the other extreme, whole projects can fail – scrapped after multiple delays and rising costs.

There are many factors behind these failures, but I want to highlight one that I’ve seen time and again at the heart of problem projects: the lack of shared understanding amongst the many participants of what needs to be achieved and why. It is only when everyone involved in a project has the same understanding of the goals that they can all contribute to the best of their abilities – and software development is most definitely a team sport.

People often assume that their team has a shared understanding of what the aims are and where the project is heading, but if you dig a little deeper, this is rarely true. Why is this?

At the root of the problem is the fact that most software projects are very complex. It is easy to get lost in the details of a large enterprise database application, or CRM system, for example. Creating a shared understanding means actively working against that complexity.

However, more important still, is that all the people involved in a project approach discussions from their own point of view. They bring with them a set of assumptions based on the particular discipline that they come from (business, project management, design, devlopment, etc.); their own unique personalities and traits; and the current issues that they are concerned about. These biases have a fundamental impact on how they interpret discussions.

It Is usually clear when our communication breaks down completely – people look back at us blankly, or ask us to repeat. However, when people seem to understand us, we usually assume that they understand not just what we said, but what we meant, which is not the same thing. In other words we assume that their interpretation is the same as ours. This is a far harder proposition, people do not understand what we say, they understand what they hear, filtered through their own thoughts and biases.

You can see this at play any time that you have asked someone a question and they’ve answered something quite different. “What do you think?” You ask your partner over dinner, thinking of the vacation you’re planning. “A bit too much salt for me”, they reply.

Add to these challenges the fact that teams are often separated by distance, language and culture and it is hardly surprising that a shared understanding of what needs to be achieved and why is elusive.

So if the problems are clear enough, how can we fix them? How can we promote shared understanding within a project?

FOCUS ON THE CORE WORKFLOW

Shared understanding is impacted by focusing on too much detail too early. Many projects start to create lists of requirements, detailed use cases, complex flow diagrams, error conditions and other detailed documentation right from the start. This kind of output looks professional and important, but often obscures clear understanding of the key aims of the project. Shared understanding beats extensive documentation any day of the week.

A better way to start is by focusing on what a colleague of mine has dubbed the ‘happy day scenario’. What would the product look like, and how would the user interact with it, if it was a normal day and everything went well?

Take the time to describe the happy day scenario in a few short paragraphs (prose, not bullet points) and it will do wonders for the level of understanding of the project. Think of it as a ‘manifesto’ for the project. Focus on getting agreement from all the stakeholders at this simple level, before going into more detail.

SPEAK AND LISTEN WITH CARE

Take responsibility to speak and to ask questions carefully, to ensure that your listeners understand you. Listen carefully to ensure that you are understanding them. Don’t be afraid to ask if you aren’t sure.

Take notes during meetings and send them out afterwards. If discussions are particularly tricky, take those notes publicly – show them on a big screen, or share them via a screen sharing tool. Keep asking: “is this what we mean?”

Break issues down into smaller pieces and focus on creating small agreements and documenting these. However, don’t be too precious about these agreements. The idea is to move forward with everyone on the same page; if something you agreed turns out not to make sense, then drop it – you shouldn’t be tied in.

One of the most important questions to ask when discussing requirements is ‘why?’: Why are the product owners and users asking for that? Are they really asking for what they need, or are they asking for a particular solution when a different approach would be better?

VISUALISE

However, the key change is to bolster speech and text with drawings. Visualising the problem and drawing possible solutions has a huge impact on shared understanding. Wireframes are far better than text at clarifying what you mean in terms of a UI solution.

This doesn’t have to be pretty – almost any sketch will help to drive common understanding. However, this is one area where designers and user experience professionals can provide particular assistance, with their skills in sketching and wireframing.

Illustrating key flows as sequential wire frames or storyboards, combined with the manifesto can very clearly explain what the project is about and how it is expected to work. This approach ensures that everyone on the project understands what is intended. It also has the benefit that senior stakeholders can give their support more easily and it is possible to start testing the ideas with users very early in the process.

What are your tricks for promoting shared understanding?