Ballet lessons

The lights come up and the ballerina curtsies. The audience applaud, enthralled by the performance they’ve just seen. The dancers enter and take their bow.

The secret to a dance troupe’s success is, of course, years of training, testing and refining skills, underpinned by a vision for each production that is carefully planned and choreographed. This vision is captured in a specialist language of dance that describes movement: Benesh.

Benesh is a notation system that records the positions and movements of a dancer like musical notes on a stave. It is a piece of visual mathematics, a grammar of dance.

What has this got to do with projects? Everything. For if we are to succeed in our roles, we need clarity of intent and efficiency of communication.

Every time we fly, our safety depends on 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 aircraft computers to run, transporting you safely to your destination.

The safety of your flight also depends on safety cases that underpin critical systems. Again, 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. Unified Modelling Language is another example.

 Getting requirements right is fundamental to successfully scoping projects, and then estimating, pricing, negotiating, delivering and controlling the inevitable change. The natural languages we converse in every day are the dominant way in which we express project requirements and plans.

Everyday languages v controlled languages

The general expressiveness of natural language comes with a risk, however: ambiguity. Ambiguity in projects wastes resources and makes failure more likely. So, 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 in order to identify contradictions and ambiguities. Attempto Controlled English 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 upfront 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, of course, words and accompanying punctuation can still sometimes fail us. Lynne Truss’s Eats, Shoots & Leaves is a well-known book on the consequences.

Ambiguity v precision

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 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’re 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.

Imagine a dial. 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 to our projects?

• First, look again at how your project expresses its intentions. Make sure this is 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.
• Determine whether the project is suffering delays as a consequence of poor expression of intent. Use this insight to improve the way you describe and communicate your goals.
• 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, asking: “Is this what you meant?”

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. So explore fields outside project management: how do these disciplines describe and model their desired outcomes? What language and mathematics do they use to convey intent?

Put language at the heart of project management, and turn delivery into a graceful expression of intent: a dance.