Firmly establishing project scope will save many headaches as you near the end of your project.
The project sponsor, for example, may believe this or that was to be part of the project deliverable. But you, the project manager do not have the same understanding. Now what do you? Either the project sponsor will go away unhappy or your scope just increased without any ability to pay for it.
Putting a fence around the project scope is the best way to avoid future problems like this. Clearly establishing the project boundaries during project initiation ensures everyone will be getting what they expected out of the project.
Scope is typically defined in a Scope Statement, but smaller projects will include scope in the Statement of Work.
I suggest using two subheadings to clearly define in and out of scope.
In Scope
Explain in detail the scope of the project. Include a breakdown of all the deliverables and a clear summary of the scope of work to be undertaken.
Out of Scope
List any gray areas here and include details on the exclusions. Be specific about items that are not in scope that others may assume are in scope.
Further evidence of In Scope vs Out of Scope deliverables will be documented in the Deliverables Traceability and/or Requirements Traceability documents if you include them during project planning.