The Psychology of Quality and More

| Menu | Books | Share | Search | Settings |

Planguage for Requirements

Quality Tools > Tools of the Trade > Planguage for Requirements


One of the most common reasons that projects fail is confusion over what is really wanted. This typically starts in the requirements phase, where what is needed should be clearly defined, but seldom is. Weak requirements lead to propagated error with specifications, designs and build that do not really meet original customer needs.

A second, related problem that follows from the first is creeping requirements. Customers changing their minds and changing the requirements is much easier when the requirements are not clear. If you have a precise definition of what is needed, then it is easier to control.

A good tool for addressing this is provided by Tom Gilb in his book ‘Competitive Engineering’. ‘Planguage’ stands for ‘planning language’ and is simpler than it sounds. The basic principle is to use a set of closely defined identifiers (‘tags’) to describe and quantify specific elements of the requirements.

Here is a simple partial example of using Planguage:


PLAN [01-Sep 2012]: Full product release
GIST : Develop XYZ product ready for product release
STAKEHOLDER [planning, final signoff]: Product Quality Manager
AUTHORITY [final signoff]: Marketing Manager
METER [Product]: Signed off acceptance by <those with final signoff>
MUST [01-Sep 2012]: Partial product release
WISH [01-Aug 2012]: Full product release


The format as can be seen is:

  • One element per line

  • Keyword ‘tag’ in capitals

  • Tag qualifiers in [square brackets]

  • Further description after colon :

  • <angle brackets enclose fuzzy items that may need improving>

There is somewhat more in Planguage, although much can be done with relatively few keywords, as shown in the table below.



A short description to help understanding


The level at which success can be claimed


The scale of measurement used to quantify the statement


The process or device used to measure using the SCALE


The minimum level required to avoid failure 


The best if everything goes perfectly


A desirable level of achievement


The best-known achievement 


Previous results that may be used for comparison 


A set of historical data or extrapolation of this


A person or organisation materially affected


The person, group or level of authorization allocated


The official definition of a term


A requirements document will often need more narrative than is provided by a Planguage format, though this approach is very good for definitive descriptions in the parts that need close attention (which is often more than is realised). It is also useful in legal documents such as contracts and proposals where people may be held to account for specific items.

The critical principle of Planguage is precision. It forces you to think carefully and define everything. It is also a good facilitation tool with which you can sit down with others and work through their ideas and requirements. Most of all, it gives you a definitive document that will lead to a higher quality, on-time product.

The Planguage Concept Glossary can be found here:


Next time: Quality Cost Audit


This article first appeared in Quality World, the journal of the Chartered Quality Institute


Site Menu

| Home | Top | Settings |

Quality: | Quality Toolbook | Tools of the Trade | Improvement Encyclopedia | Quality Articles | Being Creative | Being Persuasive |

And: | C Style (Book) | Stories | Articles | Bookstore | My Photos | About | Contact |

Settings: | Computer layout | Mobile layout | Small font | Medium font | Large font | Translate |


You can buy books here

More Kindle books:

And the big
paperback book

Look inside


Please help and share:


| Home | Top | Menu |

© Changing Works 2002-
Massive Content -- Maximum Speed