The “Work In-Scope” section is the meat of the document, covering the service provider’s scope responsibilities. The work activities are listed here. For smaller projects, or when there is less need for detail, the activities can simply be listed as a set of bullet points. When the work is more complex and/or where there is potential for conflict or misunderstanding, the PM may desire to characterize each activity using elements such as these.
- Breakdown of activity (tasks/subtasks): While not as detailed as a WBS, this breakdown should elaborate with a few sub-tasks.
- Owners: Larger projects with multiple service providers may warrant identification of the individual or sub-team responsible.
- Specific assumptions: A “general assumptions” section will follow, but a complex work activity may warrant the listing of specific assumptions extremely relevant to those particular tasks. For instance, an implementation may assume power and rack capacity, or a development team assumes existence of naming standards.
- Out-of-scope: Listing out-of-scope items may be valuable to ensure all parties do not misunderstand what is to be – and what is NOT to be – accomplished. For example, the customer wants to save money by foregoing monitoring agents on the application servers.
- End conditions and deliverables: To ensure an exact understanding of the finished deliverable, this element described what will be delivered by the work activity and by when.
This section must explicitly mention the work to be performed for this project. Project management, un-boxing hardware and discarding trash, cabling, assembling source code into a repository, compiling documentation, and performing knowledge transfer would all warrant discrete listing as a work activity. Ideally, there will be procedures documents or design specs elsewhere that may be referenced, but the detail should be addressed somewhere.