The lights rise, and the ballerina curtsies. The audience applaud, delighted with the superb performance they have just seen. The dancers enter the stage, and take their bows, happy to share in the enjoyment they have brought.

At every performance the troupe have delivered consistently, exceeding the expectations of all who have seen their skill, movement and grace. Their secret to success? Years of training, testing and refining their skills, underpinned by a clear vision for each production, well planned and carefully choreographed. This vision is captured in a language, a language of dance that describes movement: benesh.

Benesh notates each dancer’s movements like musical notes upon a stave, the symbols representing positions and dynamics. It is a piece of visual mathematics; the symbols and their placements follow rules: a grammar of dance. Benesh provides a balance between generality and precision, accurately conveying the performance the troupe must deliver.

What has this to do with projects? Everything: clarity of intent and efficiency of communication are essential if we are to deliver. I encourage you to take a look at the performing arts, the sciences, and engineering endeavours around the world, and ask yourself: what can we learn from these in order to describe the performances, the deliverables, the outputs we are charged with delivering?

There is a fascinating world of languages and notations waiting to be discovered and applied. Tested and evolved over the years, they possess common characteristics that can help us design and deliver our projects.

We switch worlds now, away from dance, to aviation. The next time you board an aircraft, recall that your safety depends upon computer programs performing near-flawlessly. To achieve this, the system engineers must consider all potential conditions. They must determine the requirements and operating envelopes, and record these constraints in a precise form that the programmers can turn into code. The code is then compiled into instructions for the airraft computers to run, transporting you safely to your destination.

There are proven software languages used to deliver high-integrity code, such as the SPARK programming language. SPARK is based upon Ada, a language named after Countess Ada Lovelace, a pioneer of modern computing. The SPARK language removes aspects of Ada that could lead to ambiguity, and introduces further grammatical elements to ensure that what the computer “thinks” is what the programmer meant. SPARK is a general-purpose programming language that is also precise. It can be mathematically analysed, leading to more reliable systems that are – perhaps counterintuitively – less costly to deliver because there are fewer misunderstandings and errors.

The safety of your flight depends upon another element: safety cases that underpin critical systems. Safety cases can be expressed using a formal notation called Goal Structuring Notation (GSN). The GSN language has formal rules for presenting a coherent and logical argument about safety. GSN helps identify areas of risk that the designers can then address. It is one of a family of modelling languages, of which UML (Unified Modelling Language) is another example.

The most widely used languages are, of course, the natural languages we converse in every day. These are by far the most dominant way in which we express project requirements and plans. Getting requirements right is fundamental to successfully scoping our projects, and then estimating, pricing, negotiating, delivering and controlling the inevitable change. Here, just like the SPARK programming language, we can apply the idea of subsetting. Rather than accept a general purpose natural language with all its ambiguities, we can remove the parts that cause confusion.

Controlled natural languages reduce ambiguity by restricting the grammar and vocabulary, and can be formally analysed, to identify contradictions and ambiguities. Attempto Controlled English (ACE) is an example, and even has its own standard. We can combine natural language and mathematics to form hybrid descriptions, such as Z, a formal specification language used to model high integrity and safety related systems. While training is required to read formal languages, along with an up-front investment in describing the desired system, the payback is significant: more predictable projects and products.

All these languages and notations have two key characteristics. They balance generality with precision, and they minimise ambiguity. With some honourable exceptions (you may know one or two!) we seek to convey the maximum useful information with the fewest words. But words and accompanying punctuation can fail us. Lynne Truss’ “Eats, Shoots and Leaves” is a well-known book on the consequences. There is no escaping it – the general expressiveness of natural language comes with a risk: ambiguity. Ambiguity in projects wastes resources and makes failure more likely.

Ambiguity arises where a word or phrase can mean many things. The person writing a particular form of words may have a clear thought in mind. But if the reader can think of many interpretations – or worse still – unwittingly pick one, unaware that others also exist – then our project may be derailed. To counter this we may go to the other extreme and over-specify our intentions, inundating the recipient with misleading detail.

Our challenge then is to pick the right level of information. If our communication is too abstract, we risk ambiguity and errors of omission; but if we are too detailed, we over-constrain the solution, blocking the creative process that professionals enjoy when seeking solutions. To scope our project correctly we must strike the right balance. This is where the intersection of natural language and mathematics has much to offer.

To apply these ways of thinking, I invite you to imagine a dial we can turn. At one extreme is precision, and at the other is generality. Where ambiguity is a risk, we dial up the precision, and where ground can be covered with less risk, we can use more general language.

How can we apply these techniques on our projects?

First, look again at how your project expresses its intentions. Ensure these are written down. Adopt a standard that governs how the goals, objectives and requirements are to be recorded, using unambiguous notations. Why not develop your own language syntax and grammar, tailored to your domain? Diagrams are a powerful way to express your intent, highlighting relationships and connections.

Second, determine whether the project is suffering delays and rework as a consequence of poor expression of intent. Use this insight to improve the way you describe and communicate your goals.

Third, focus on your stakeholders and clients. They trust you, the expert, to deliver their requirements, but you need them to say clearly what they want – so meet in the middle. Take the time to work with clients on how best to describe the problem and the solution, using clear, simple language underpinned with formal notations where precision is required. An investment in training the client in how we notate our work has enormous payback – we move onto the same page. Build a common description of what “good looks like” that is both precise and expressive. Regularly check back: “is this what you meant?”.

Finally – if we explore the fields outside project management with this new perspective, how do these disciplines describe and model their desired outcomes? What language and mathematics do they use to convey intent? As project managers we owe it to our clients and our profession to describe and deliver complex projects with confidence, laying the foundations for success with clear, unambiguous language. Put language at the heart of project management, and turn delivery into a graceful, flowing expression of intent: a dance.

(c) James Lea 2019

A variant of this article was also published as “Ballet Lessons” in the APM’s blog Surprising Lessons on language for Project Managers and in the APM’s Project journal Spring 2019.

If you would like to explore how we can choose the right language to describe your project goals and ways of working, please get in touch.

• Language