These are the general assumptions, constraints, and dependencies that the project team will work under. The Work In-Scope section addressed specific assumptions related to a particular task. One may want to pull out the more important of those and list them here as well. Alternatively, for smaller projects, there may be no need duplicate sections.
Some general assumptions may include adherence to security, quality or architectural standards; following change or release processes; assumed software licenses; existence of a legal agreement or relationship; continued availability of resources; viability of the business case supporting the project; or certain business conditions. If a successful delivery depends on an interface another team is building, or stored procedure rewrites by customer DBAs, it needs to be clearly identified here.
The main objective is to communicate that if any of these assumptions change, the SOW will likely need to be modified and the project may be at risk.
This section may or may not have the “and Risks” added to its title. The risks are inherent in assumptions – they are corollaries; i.e., the risk is that a particular assumption may not hold true. Having “Risks” added to the section title or given its own section may be redundant. It may be appropriate to just state that these assumptions will be monitored through the risk management process. Regardless, assumptions provide the cornerstone of risk management and must be identified.