Often things are not what we like. And this applies to everything, whether you are a project manager or a programmer this will happen.
Of course, reading specification documents are not safe from this. On several occasions, you might find a lot of ambiguity in a document, this is a big problem at the time you try to read the document because this doesn’t give you insight about what to do. This problem is caused by unsolved conflicts among various system stakeholders. But even if a specification is ambiguous, you need to find sense in it.
If you have trouble finding sense in a specification document, this might mean that the document is nonsense and it is not worth reading. To identify this kind of specification document you only need to check one thing: Check if the document has a complete census of inputs and outputs. If a document does not specify that there is a problem, it does not start to specify, and because of this, it does not specify anything at all.
The problem starts with the document of course, but if you have employees reading a specification document of this kind they will not tell you if the specification is lousy. Instead, they will blame themselves rather than the paper.
To solve the problem with the specifications, the first thing to take in place is to speak with your stakeholders, apply other techniques to solve the conflicts between them, model a good specification document and then finally to pass them to your employees, try to reduce the ambiguity the more you can.