World Commerce & Contracting (WorldCC) is quite explicit that poorly defined specifications, requirements and scopes of work are a major cause of contract failure, disputes and value leakage.
WorldCC’s Ten Pitfalls research identifies lack of clear scope and goals as Pitfall No. 1. WorldCC says this is the most frequent source of claims, disputes and disrupted relationships and affects around 40% of projects.
To assist those who are responsible for developing specifications and scopes of work, I have developed a simple “check” list of the 12 do’s and don’ts of Developing Effective Specifications and Scopes of Work derived from our popular course of the same name.
Developing Specifications & Scopes of Work: 12 Do’s
- Define the required outcome before developing the technical solution.
- Involve the right stakeholders and capture requirements.
- Involve Procurement/Commercial early; technical decisions have commercial consequences.
- Write in clear, plain and unambiguous language.
- Make requirements specific, measurable and verifiable.
- Clearly allocate responsibilities: who does what, when and where?
- Define interfaces, dependencies and boundaries between parties and systems.
- Identify assumptions, constraints and exclusions explicitly.
- Specify operating/environmental conditions relevant to the equipment or service.
- Define acceptance criteria, testing, deliverables and KPIs.
- Apply Value Analysis/Value Engineering and standardisation to challenge unnecessary requirements and variety.
- Carry out a final completeness and ambiguity review before issuing the specification.
Developing Specifications & Scopes of Work: Do Not…
- Start with a preferred solution before understanding the required function/outcome.
- Develop the specification in isolation.
- Assume the supplier or market understands what you intended.
- Use vague words such as appropriate, adequate, reasonable, suitable, quickly without defining them.
- Use “should”, “could”, “might” or “endeavour to” when the requirement is mandatory.
- Include requirements that cannot be objectively measured or verified.
- Leave assumptions, exclusions or responsibilities unstated.
- Copy an old specification without challenging whether requirements are still necessary.
- Over-specify or over-engineer simply because technically you can.
- Unnecessarily specify brands or solutions where performance/outcome requirements would encourage better alternatives.
- Focus solely on purchase price
- Allow uncontrolled changes after award; maintain traceability and formal change control.
If you would like more information about this course, please email info@dpss.co.uk