This is the third post in a series about hidden project changes: things that affect scope but are easily overlooked. The topic for this post is ambiguous requirements.
One of the conditions for a waterfall project to succeed is comprehensive requirement specifications.
You supposedly plan the whole project in the beginning, during the planning phase. Anything that is not clearly stated, without room for interpretation, potentially leads to contract negotiations, which in turn might lead to a damaged relationship with the customer and - in the worst case - the project failing or being canceled altogether.
Even if the relationship with the customer is good and you argue that "there won't be a problem", it's better to be safe than sorry. Like with a prenup, you don't assume it will be used but it can still turn out to be a good idea.
If you can't agree on another contract such as phased development or variable scope/time, make sure thorough requirements are in place:
- Review and discuss each requirement with the customer. Involve as many people as needed: technicians, domain experts, and so on.
- Agree on a plan B if discussions arise regarding the interpretation of requirements.
- Create a WBS (Work Breakdown Structure) to make sure everything is captured in the requirements.