Building a scope baseline is what turns a fuzzy idea into a project you can actually deliver. Here you will learn how to assemble that baseline using a real example, the autonomous delivery drone project, and the templates that go with it. This is for project managers, founders, and team leads who need a clean structure to align scope, communications, and change control.

What goes inside the scope baseline document?

The baseline document can live in Google Docs, Word, or any editor you prefer. What matters is that it consolidates every piece that defines what the project will and will not do.

For the drone project, the structure includes:

• Justification of the project.
• Measurable objective of the product to deliver.
• Deliverables with their key requirements and acceptance criteria.
• Scope definition with inclusions, exclusions, assumptions, and constraints.

The acceptance criteria piece matters because you are not building any drone. You are building one that meets specific requirements, like a maximum budget, a launch date, or a mandated software stack [00:54].

What is a scope baseline? It is the approved version of your scope statement, the work breakdown structure (WBS), and the WBS dictionary. You use it to measure changes and performance during the project.

How do you detail deliverables with the WBS and its dictionary?

The work breakdown structure, or EDT in Spanish, breaks the project into hierarchical work packages. You can draw it as a tree or as a list, both are valid [02:14].

When you use the list format, build a table with these columns:

• ID for each deliverable and work package.
• Short description of the deliverable.
• Detailed scope for the WBS dictionary.
• Dependencies between packages.
• Responsible person or team.

Adding dependencies early pays off twice. First, it feeds directly into your schedule. Second, it forces you to name owners before things get messy.

How does the RACI matrix connect to the communications plan?

The RACI matrix is a cross between your critical work packages and your stakeholders [03:18]. For each cell you assign one of four roles:

• R: Responsible, the person doing the work.
• A: Accountable, the person who answers for the outcome.
• C: Consulted, gives input before decisions.
• I: Informed, kept in the loop after decisions.

Not every stakeholder gets a letter in every row. The project manager, for instance, sits across all activities, so the role rotates between R, A, C, and I depending on the package.

What does RACI stand for in project management? Responsible, Accountable, Consulted, Informed. It clarifies who does the work, who owns the result, who advises, and who just needs updates.

Once the RACI is set, you build the communications plan. For each stakeholder you define purpose, key messages, frequency, channel, owner of the relationship, artifacts, KPIs, and triggers.

A practical example with a project sponsor [04:40]:

• Purpose: strategic alignment of decisions.
• Key messages: ROI, milestones, critical risks.
• Frequency: monthly or on demand.
• Channel: executive summary by email.
• Owner: project manager.
• Artifacts: steering committee minutes, decision logs, dashboard.
• Metric: reports on time, decisions within a defined window.
• Trigger: communication right before or after a key milestone.

How do you handle a change control request without breaking the baseline?

A change control request is a formal ask from someone, often outside the core team, to modify scope, time, or cost. In the drone project, marketing requested adding a visible company logo to the drone [06:18].

The template for this request captures:

• Description of the change and expected benefits.
• Options considered.
• Estimated impact on scope, time, and cost.
• Risks identified.
• Recommendation from the project manager.
• Implementation plan if approved.

You also need a table of approval roles, since the decision may rest on one person or a committee. Without that clarity, requests stall.

Why does a scope change usually trigger schedule and cost updates? Because the three baselines are linked. Adding a deliverable adds tasks, and adding tasks consumes time and money. That is why you version every baseline.

What is the full flow of a change control process?

The approved sequence runs like this [07:42]:

1. Register the change request.
2. Project manager validates it.
3. Technical risk analysis.
4. Review by the change control committee.
5. Execute, approve, or reject.
6. Update the scope, schedule, and cost baselines.
7. Verify benefits and capture lessons learned.

Version control on the baseline is non negotiable here. Every approved change creates a new version, and the table inside your document tracks who approved what and when.

How do you adapt these templates to your own project?

Take the documents, swap the drone example for your own context, and add your company logo. The structure works for hardware, software, services, or internal initiatives.

The next step is the schedule baseline, which builds on the WBS you just defined and sequences activities over time. If you have already mapped dependencies in the WBS dictionary, that work pays off immediately.

Which part of your current project still lacks a clear scope baseline? Drop it in the comments and let's talk it through.