They didn’t know the product development manager would quit one week into the project due to a disagreement over the correct pronunciation of agile.

They did not know that top management was working on a secret merger, so the scalability requirements have doubled.

They did not know that the business process analyst would elope and go for a honeymoon in Antarctica.

They did not know that all of the reviewers of the hardware and software requirements would be delayed two weeks because of a new high-priority project involving online sales of tea cozies.

They did not realize that the requirements training, product manager training, and business analyst training they had planned would fail because the trainers had accents that couldn’t be understood.

They did not know that the functional requirements would include workarounds that allow the CEO’s nephew Bill to use the system even though he refuses to use a mouse due to fear of carpal tunnel syndrome.

They did not know that the software development life cycle would be halted completely for a week because the system architect got attacked by killer bees before he was able to delegate responsibilities to his team.

They did not realize that agile requirements management meant ten different things to ten of their stakeholders.

They did not anticipate that procurement would reject their vendors for requirements consulting and project management consulting because the purchasing rep got a bonus if all their vendors for the quarter were from the preferred list.

They did not know that one approver refuses to sign anything that uses the company-standard BRD template, use case template, and SRS template because his templates lost the annual “design a new template” competition and he’s been bitter ever since.

They did not know that the requirement management tool that they were using comes up with an unexpected error message that the vendor refuses to fix whenever they attempt requirements traceability.

They didn’t know that the System Requirement Specification could not be posted to the company intranet because the intranet does not accept any documents created with any word processor released after 1987.

So please don’t ask them why these things were not in the original project plan and then tell them to plan better next time.  Also, don’t punish them for changing the plan.  When any (or all) of the above occur, the business analyst should be praised for adjusting the plan accordingly.  If you don’t want the plan to change, hire only fortune-tellers in your organization, not business analysts.