One of the problems of working with the PRINCE2 practitioners is that the people tend to get highly focussed on definitions in the Scope of Works. A Scope of Works defines what the deliverables the customer is to received.
The problem with a Scope of Works is that it is usually prepared before the work is started and/or fully understood. maybe you have a Gap Analysis, a Consulting Reports or a Requirements Document to setup the initial engagement (every company has their own name of the same thing).
For example, a Scope of Works for building a Data Centre Network would require an extraordinary level of understanding to fully comprehend all the systems, applications, data flows and their dependencies. A Scope of Works is, fundamentally, more of a general plan or overview of the works. That’s the problem. One group of people treat the Scope of Works like a legal contract while the data contained is actually a summary of technical intentions for the work to be performed.
Requirements Terminology
Therefore I find using precise terminology to be useful. After many years of reading IETF RFCs I’ve come to love RFC2119 – Key words for use in RFCs to Indicate Requirement Levels as guide to exact phrasing. I’ve developed the following set of text that goes into my documents.
MUST -This word, or the terms “REQUIRED” or “SHALL”, mean that the definition is an absolute requirement of the specification.
MUST NOT – This phrase, or the phrase “SHALL NOT”, means that the definition is an absolute prohibition of the specification.
SHOULD – This word, or the adjective “RECOMMENDED”, mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
SHOULD NOT – This phrase, or the phrase “NOT RECOMMENDED” mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
MAY – This word, or the adjective “OPTIONAL,” mean that an item is truly discretionary.
FUTURE – This word means that objectives are provided as guidance or expectation and may or may not be accurate.
SEPARATION – This word means the prevention of reach-ability to designated resources.
This way, people who read the word “MUST” and want it to say “MIGHT” or “MAYBE” don’t get to misinterpret to their own way of thinking.
Warning
It’s worth noting that you also need to be quite precise and accurate in using these terms consistently throughout your documents. it takes some discipline to “mean what you mean”. Personally, I find that the use of these definitions makes me focus closely on the writing and leads me to be more accurate overall.
