Turn discovery and project requirements into a clear working scope with the AAMA Project Scope Template. This editable professional template helps agencies, consultants, marketing teams, organizations, students, and academic teams document what a project is expected to accomplish, what work is included, who is responsible, when major decisions must occur, and how changes will be handled once the project begins.
A useful project scope should create enough clarity that the project team, client, stakeholders, and approvers understand the boundaries of the assignment before substantial execution begins. It should also make assumptions, dependencies, exclusions, responsibilities, financial limits, and acceptance requirements visible so they can be managed rather than discovered after work is already underway.
Download the Project Scope Template
The AAMA Project Scope Template is provided as an editable Microsoft Word document. Replace the bracketed instructions and placeholder content with project-specific information, expand the working areas when additional detail is required, and remove sections that do not apply to the assignment.
The document uses a neutral professional format that can be adapted to an agency, consultancy, internal marketing team, client engagement, course, campaign, creative project, digital initiative, research assignment, or other professional work. It can function as a project-management document on its own or be adapted to support an organization’s existing proposal, statement-of-work, procurement, or contracting process.
What the Template Helps You Define
The template connects the reason for the project with the work required to complete it. It creates a shared reference for the objective, scope boundaries, deliverables, workstreams, milestones, resources, responsibilities, approvals, budget, dependencies, revisions, and final handoff.
The goal is not to eliminate every possible uncertainty before work begins. The goal is to define the important boundaries and establish a process for handling new information without allowing the project to expand informally.
What’s Included
The 12-page template includes:
- Project Overview & Objective
- Scope Summary & Workstreams
- Deliverables
- Milestones, Timeline & Dependencies
- Roles, Responsibilities & Decision Rights
- Assumptions, Dependencies & Constraints
- Budget, Fees & Expenses
- Review, Feedback & Approval
- Change Control & Out-of-Scope Work
- Acceptance Criteria, Handoff & Closeout
- Final Scope Summary & Approval
Each section includes guided fields, working tables, planning prompts, or replaceable visual placeholders that can be edited directly in Microsoft Word.
Begin With the Project Objective
The first section establishes the business or organizational problem, the desired result, the priority audience or user, the success measure, the target completion date, and the accountable sponsor. These elements create the strategic boundary within which the rest of the scope should be developed.
A project should not be defined only by the deliverables someone initially requested. A website, campaign, research report, presentation, media plan, rebrand, video, or content package is an output, while the project objective explains what that output is expected to help accomplish.
Document the Project Background
The template includes space for the context another stakeholder would need in order to understand the assignment. This may include previous work, organizational changes, customer research, campaign history, market conditions, technical architecture, existing systems, or another condition that materially affects the project.
A replaceable Project Context placeholder can be used for diagrams, reference materials, architecture, research, or other approved visual information. The visual should support the scope rather than become decorative material that does not affect the work.
Define the Desired Outcomes
The Outcomes section asks teams to state what should change because the project is completed, why the result matters, and how it will be evaluated. This creates a stronger connection between the work being produced and the outcome it is supposed to support.
Some projects will have quantitative success measures, while others may use acceptance criteria, usability requirements, approval standards, production requirements, or another form of evidence. The appropriate standard should follow from the nature of the assignment.
Organize Work Into Workstreams
Large projects become easier to manage when related activities are grouped into clear workstreams. Depending on the assignment, these may include strategy, research, creative, content, media, production, digital development, technology, measurement, or another functional area.
Each workstream can have its own purpose, owner, and status while remaining connected to the overall project objective. This provides more clarity than treating the entire engagement as one undifferentiated collection of tasks.
Establish the Scope Boundary
The Scope Boundary section separates work that is clearly included, work that is clearly excluded, and items that still require a decision. This distinction can prevent unresolved questions from quietly becoming commitments later in the project.
Out-of-scope documentation is particularly useful when the project is adjacent to other work. A campaign assignment may include creative production but exclude media buying, while a website project may include page design but exclude custom software development.
Define Every Deliverable
The Deliverables section records the expected output, description, format or quantity, owner, and due date. It also establishes requirements for brand standards, technical specifications, accessibility, claims or compliance, localization, versions, and final handoff.
A deliverable should be described precisely enough that both the project team and approver can recognize what is being produced. Vague descriptions make it difficult to determine when the work is complete or whether a later request represents a revision, clarification, or entirely new deliverable.
Include Deliverable Requirements
Different outputs may require different standards. A video may need several aspect ratios, a website may require accessibility and browser testing, advertising creative may require platform specifications, and a research report may require defined methodology and source documentation.
The template creates a dedicated place for these requirements before production begins. This can prevent important specifications from appearing only during final review, when correcting them may require substantial rework.
Use Visual References Carefully
The template includes a replaceable Deliverable Example placeholder for approved mockups, diagrams, samples, wireframes, or reference materials. This can help establish expectations when a written description alone is insufficient.
Reference materials should clarify the intended deliverable without implying that another organization’s work should be copied. Teams should document what the reference demonstrates, such as structure, production level, information hierarchy, format, or another relevant characteristic.
Build a Realistic Project Timeline
The Milestones, Timeline & Dependencies section documents kickoff, discovery, approvals, reviews, production, implementation, and final closeout. Each milestone can include an owner, start date, due date, dependency, and expected approval or output.
A realistic project schedule includes review time rather than assuming that every deliverable progresses immediately after it is produced. Stakeholder feedback, legal review, executive approval, procurement, client input, or technical testing can all become part of the critical path.
Document Critical Dates
Some project dates cannot move easily. Product launches, events, media flights, conferences, regulatory deadlines, seasonal opportunities, contract expirations, scheduled announcements, or other external conditions may determine when the work must be completed.
The template includes a Critical Dates section so these conditions remain visible alongside the internal project schedule. This makes it easier to understand which delays can be absorbed and which may affect the underlying business objective.
Define Roles & Decision Rights
Projects often become inefficient when several people can request changes but nobody knows who has final authority. The Roles, Responsibilities & Decision Rights section identifies sponsors, owners, project managers, functional leads, analysts, legal or compliance stakeholders, and final approvers.
It also includes a practical RACI framework for identifying who is responsible, accountable, consulted, and informed across major project activities. Teams can adapt the roles to fit the actual organizational structure rather than preserving categories that do not apply.
Identify Assumptions
Every project scope relies on assumptions. The client may be expected to provide content by a certain date, research may be assumed to exist, technology may be expected to support a required integration, or a campaign may depend on product availability.
The Assumptions section documents the assumption, its basis, its owner, and the impact if it proves incorrect. This makes it easier to determine when changing circumstances justify revisiting the scope, schedule, budget, or deliverables.
Record Dependencies
Dependencies are inputs or decisions the project team cannot complete independently. These may include access credentials, executive approvals, legal review, data, client materials, vendor work, technology, product information, media availability, or another required input.
Each dependency includes an owner and required date so it can be actively managed. A project delay becomes easier to diagnose when the schedule clearly shows which work depended on a missing input.
Document Constraints
Constraints are conditions within which the project must operate. These may involve budget, timeline, technology, staffing, regulatory requirements, production capabilities, security rules, vendor limitations, or another fixed boundary.
Identifying constraints early can prevent the project team from developing recommendations that cannot realistically be implemented. It can also reveal when a constraint itself must be changed before the desired outcome becomes achievable.
Establish the Financial Boundary
The Budget, Fees & Expenses section can be adapted for fixed-fee, hourly, retainer, internal-cost, or other project models. It includes working areas for strategy, research, production, media, technology, travel, external expenses, contingency, and other costs.
The template also documents expense approval, third-party costs, overages, additional work, and invoicing or internal chargeback requirements. These controls make it easier to distinguish the approved project budget from new spending that requires separate authorization.
Identify Third-Party Costs
External expenses can materially affect the total cost of a project. Media, printing, licensing, stock assets, photography, research panels, data, travel, software, hosting, development vendors, production crews, freelancers, or other outside costs may or may not be included in the stated project amount.
The scope should specify how those costs are handled. This can prevent a project fee from being mistaken for an all-inclusive budget when substantial external investment is still required.
Define the Feedback Process
The Review, Feedback & Approval section establishes who reviews the work, when feedback is due, how comments are consolidated, how conflicting direction is resolved, and what constitutes final approval. It can also document the number or structure of revision cycles included in the assignment.
This process protects both the project team and the client or organization. Review becomes more efficient when the project team receives one coordinated direction rather than several incompatible instructions from stakeholders who have not resolved their differences.
Establish Approval Authority
A reviewer and an approver are not always the same person. Subject-matter experts may provide important feedback without having authority to change the project strategy, while legal teams may approve compliance but not creative direction.
The Approval Record gives the project a clear history of important decisions. This can be especially useful when later work depends on an earlier strategic, creative, technical, or financial approval.
Use Change Control
Projects change as new information becomes available. Change control is not intended to prevent that flexibility; it is intended to make the consequences visible before additional work begins.
The template includes common change triggers such as new deliverables, material revisions, new stakeholder requirements, missing dependencies, and external changes. Each request can be evaluated for its effect on deliverables, resources, budget, schedule, and approvals.
Distinguish Revision From New Scope
A revision modifies work already included in the project. New scope adds a requirement that was not part of the approved assignment or substantially changes an earlier approved direction.
The distinction matters because a project can otherwise accumulate additional pages, formats, markets, channels, audiences, features, review requirements, or production work without anyone formally recognizing that the engagement has changed.
The template provides a Change Request table and Out-of-Scope Requests Log to keep those decisions visible.
Establish Acceptance Criteria
The Acceptance Criteria section defines what makes a deliverable complete. Criteria may involve approval, technical testing, required files, accessibility compliance, production specifications, successful implementation, documentation, or another defined standard.
Acceptance criteria reduce subjective disagreement at the end of the project. They also help the production team understand what must be included in the final handoff before work is considered closed.
Plan the Final Handoff
Project completion may require more than delivering a final PDF, image, video, spreadsheet, presentation, or website. The client or organization may also need source files, credentials, documentation, reporting access, training, analytics configuration, recordings, or an archived copy of the project materials.
The Final Handoff section provides a checklist for these items. It also records the owner and storage location so valuable project assets do not disappear after the engagement ends.
Document Known Limitations
A responsible closeout should record important limitations that remain after the project is completed. These might include unsupported features, incomplete data, known technical limitations, unresolved research questions, future phases, measurement gaps, or work that was intentionally excluded.
Documenting these limitations makes future planning more accurate. It also prevents another team from assuming that a known constraint was overlooked or that an excluded capability was included in the original scope.
Create a Final Scope Summary
The final page condenses the project into an approved working reference. It summarizes the objective, audience, major workstreams, deliverables, completion target, budget or resource boundary, success measure, exclusions, dependencies, change-control owner, and final approver.
This summary can be reviewed during kickoff, major change discussions, status meetings, and project closeout. It provides a faster reference than requiring stakeholders to reread the complete scope whenever an important boundary needs to be confirmed.
Complete the Scope Readiness Review
The template includes a final checklist confirming that the project problem and objective are clear, scope boundaries are documented, deliverables have owners and acceptance criteria, milestones include approval time, dependencies and constraints are visible, financial boundaries are understood, stakeholders and decision rights are documented, feedback expectations are established, and change control is defined.
A project does not need perfect certainty before it can begin. It does need enough clarity that the major risks, responsibilities, and boundaries are understood by the people responsible for delivering and approving the work.
Use the Template as a Working Document
Project scopes should remain available throughout the engagement. When a new request appears, a dependency changes, a milestone moves, or a stakeholder asks whether something is included, the project team can return to the approved scope rather than relying on memory.
Meaningful changes should be documented rather than silently overwriting the original understanding. Preserving the approved baseline creates a stronger record of how the project evolved.
Adapt It to Formal Agreements When Necessary
The AAMA Project Scope Template is designed primarily as a professional project-planning resource. Organizations that incorporate it into a binding statement of work, contract, purchase order, or other commercial agreement should adapt it to their approved legal and procurement requirements.
Issues such as payment terms, cancellation, intellectual property, licensing, confidentiality, privacy, data security, liability, warranties, dispute resolution, and other contractual terms should follow the organization’s applicable policies and agreements rather than being inferred from a general project template.
Customize the Template
All bracketed text contains instructions or placeholder content and should be replaced or removed before the completed document is shared. Workstreams, deliverables, milestones, roles, budget categories, review stages, change rules, acceptance criteria, and approval fields can be expanded or modified according to the project.
The included visual placeholders use descriptive AAMA filenames so they remain easy to identify when the document or its embedded media assets are inspected. They are working placeholders only and should be replaced with project-specific materials when a visual genuinely improves clarity.
Use It With the AAMA Professional Resources
Use the template alongside the AAMA Client Discovery Questionnaire, How to Build a Marketing Plan, AAMA Marketing Plan Template, Campaign Planning Framework, AAMA Campaign Planning Workbook, AAMA Marketing Budget Template, Campaign Measurement Framework, and AAMA Post-Campaign Analysis Template.
Together, these resources provide a practical workflow from discovery and problem definition through scope, strategy, planning, execution, measurement, analysis, handoff, and project closeout.