Throughout my career, I’ve had many opportunities to do a lot of different types of work, but the majority of my experience is in technical security and project management. In fact, I’ve carried my Project Management Professional (PMP) certification for longer than any other certification and I use those skills almost every day.

One particular area of project management that is close to my heart is defining the scope of work. I have written hundreds of scope documents, whether as part of a formal methodology or, when I was in consulting, in the form of a statement of work. I chose this time of year to write this because most companies start their new capital projects in January, so this is an opportunity to start these projects with a solid scope foundation.

Why Is a Scope Document Necessary for Security Projects?

None of us enter into a project expecting to get into arguments about the scope. We don’t ever want to be at odds with our colleagues, discussing like litigators what our teams should be doing. If we get to that point, no one wins the battle — but, unfortunately, it happens. And in my past experience, it happens on a lot of projects. This is especially true for long-duration security projects, affecting many systems and requiring many months (or years) to complete. While I could go on a rant about how far-reaching networking projects are, how long identity and access management (IAM) projects typically take, or how complex and distributed the work of building a security operations and incident management solution is, I won’t. It’s sufficient to say that it happens a lot.

One of the ways to avoid this conflict is to write a strong and clear scope document. The Project Management Institute (PMI) has a whole domain of knowledge around scope management just for this reason. The scope of a project is one of the guideposts that should be referenced by everyone on the project.

Right about now is when I expect some of you to dismiss this as a tool only for use in a waterfall software development life cycle (SDLC). It is not. In my observation, agile projects need the scope defined even more so because of their dynamic schedule and evolving priorities. Every sprint needs to be aligned with the scope of the project. The Kanban board needs to show progress toward project objectives. Scrum teams need to look up toward the scope posted on the wall every day.

But how does this apply to security?

In the regulatory context, we often meet with auditors and assessors and need to demonstrate plans to achieve compliance. A well-written scope document demonstrates this. Similarly, with ever-present funding constraints, we need to show executive leadership that we have tight management control and that we’ve scoped our work to address specific risks. This concept of precision should be familiar to anyone who has been through a payment card industry (PCI) audit or reviewed an SOC 2 document from a vendor. These documents and findings are similar to a project scope document because they directly affect what we do and how we work.

4 Components That Every Scope Document Should Cover

The sections below describe how I have seen companies create concise, clear and unambiguous project scope documents. Not everyone in every company will agree, and some will outright object. But after more than 20 years of working and interacting with hundreds of companies, this reflects my experience. In general, a scope document must have at least four sections: a summary, in-scope items, out-of-scope items and deliverables.

1. Summary: Summarize the Outcome, But Keep It Short

The summary of the scope of a project needs to be articulated as prose. It should be a short, concise description. Consider it an elevator pitch, targeted at the management and leadership of your organization.

The summary gives the theme, context and magnitude of the impact the project will have. It is typically subjective more than objective, and thus becomes a point of reference to guide change management and leadership decisions. It is not, however, a measurable part of the scope, so it should not be used for scope management decisions unless the other scope sections are not clear.

The tone and level of detail should match your organization and your readers. If the project is very technically focused, a more technical summary is appropriate. If the project is focused on policy and process, it should be higher level and focused on concepts. Consider the summary section as a first impression at a social gathering — so make it a good one.

2. In-Scope Items

Whereas the summary is more subjective, the list of in-scope items — and out-of-scope below — is objective. Much like writing a contract or legal document, the scope items must be precise, unambiguous and easily referenceable. Numbered lists work great for defining the scope because it is very easy to reference, for example, scope item 4b in an unambiguous way.

These should be grouped together logically. They can be grouped in order of expected operation (e.g., requirements before design) or by similar topics (e.g., user interface items separate from business logic items). To make these statements the most useful, every item should include three parts:

1. Action first — Always use an action word to start the sentence. When the first word the reader sees is “Create” or “Update,” there is no ambiguity about what action should be taken. Action words also make things measurable. Something was either created or it wasn’t. Example: “Document the existing PCI network traffic flow from the end users to the payment engine.”
2. Object second — Every action should result in or affect an object, a system or a quantifiable thing. That thing should be commonly understood using the vernacular of the team. Example: “Document the existing PCI network traffic flow from the end users to the payment engine.”
3. Conditions third — Certain action words or objects are not precise enough to be measured. They need modifiers and clarifications to make them more precise. Example: “Document the existing PCI network traffic flow from the end users to the payment engine.”

The level of detail for these items should be sufficient for any member of the project team to understand them, but not so long that they become confusing or turn into requirements or design details. If these scope items are written well, they can easily become the milestones or top-level structure within a project schedule. Further, these can be directly linked to the deliverables below. These items can consist of multiple sentences, but in general, they should be as short and concise as possible.

While it may be obvious by the nature of using a well-defined scope document, I often include an in-scope item to adhere to a specific project methodology. This becomes a mandate for project management discipline and holds the project leadership team accountable for good management hygiene. Example: “Manage the project scope, schedule, cost and risks in adherence with the PMI/PMBOK project management methodology.”

3. Out-of-Scope Items

It is often easier to describe the scope, particularly of large programs, by defining what is out of scope. This section, which should also include a list, is powerful because it proactively addresses those things that we know will come under conflict in the future. As with the use of conditions in the list of in-scope items, these can be used to refine the scope. Consider this version of the example statement used above:

“Document the existing PCI network traffic flow from end users to the payment engine for U.S. and Canadian operations, except any transactions using debit cards or legacy card readers.”

This is a long sentence and there is some ambiguity. Therefore, it is easier to split these and write them as an in-scope item and an out-of-scope item:

• In-scope item: “Document the existing PCI network traffic flow from end users to the payment engine for U.S. and Canadian operations.”
• Out-of-scope item: “Analysis, documentation or changes to any transactions using debit card transactions; analysis, documentation or changes to any transactions using legacy card readers.”

By splitting things this way, the scope becomes more clear. It’s a little more text to write, but the structure removes ambiguity. This also exemplifies how the out-of-scope items should adhere to the same principles of action, object, conditions and level of detail.

4. Deliverables: Clearly Describe Your Outputs

Every project should result in something, whether it’s an office building or a logical system change. Deliverables are the work outputs of the project. These might be documents, implemented systems, process designs or any other thing that can be shown and validated. Without deliverables, a project becomes a lot more like a business-as-usual process.

There may be a temptation to make this list very specific, including descriptions of the content, format, sections to be included, order of delivery and review cycle. But that is probably too detailed for this document — remember the audience is diverse. Instead, refer to your organization’s standard templates, processes and assets, which may be reused. If the detailed contents of the deliverables are of great importance, include these in an appendix or external document reference. In that situation, take advantage of the extra space afforded by the external reference and make them very precise.

Similar to the scope bullet items, it is important to include project management documents as deliverables. This is how you hold your project managers accountable for their part of the project and put them in a leadership position.

Making Your Scope Document Stick

You may be wondering, what if we don’t write good project scope documents or what if no one reads them? Your project might be just as successful regardless of the quality of the scope document. Not every company or project needs these. But consider this: With a well-written scope document, your team can work through a creative process that helps everyone come to the same understanding, share their opinions, work out tensions and feel heard. Hopefully, after taking the time to be thoughtful and diligent, the scope document is never used. But if you need it and you don’t have it, you will wish you had one.

Personally, I have yet to see a project in which the scope document isn’t needed. Whether it’s a way to onboard new team members or used for governance activities, there is always value in a well-written scope document.