Newsletter Issue: "Scope"

Hello everyone,

This week I want to talk about how we use the word "scope" in a software project.

Broadly speaking, scope refers to the list of requirements that the software is expected to fulfill. Sometimes it's a literal list of feature requirements, user stories, or some other form of functionality description.

Many projects begin with a "scope document" that enumerates every specific function the software will be expected to perform. Others take a fuzzier approach, focusing on high-level goals rather than detailed requirements (which are rarely correct at the start of a project anyway).

Scope documents are important to both the developer and researcher. For the researcher, it serves as a basic agreement of the work to be done. Sometimes the scope document is called a "Statement of Work" for that reason.

For the developer, the scope document draws a clear boundary between the work that is to be done by the developer, and the work that is specifically not to be done. It's a map. Conversations about functions inside the boundary will result in work to be done; otherwise it's a discussion that the developer can safely ignore.

But (you knew this was coming): it's a trap! The scope document is the first thing to be pulled out during a disagreement about whether or not the software is "done."

It's used has a weapon when the developer claims something can't or won't be delivered because it is "out of scope."

It can easily become a source of frustration and cover-your-butt techniques for each side, rather than the thing it was truly meant to be: a clear description of the outcome we want at the end.

Now, this is a big topic that probably deserves a second issue, but my recommendation is as follows:

Pay for outcomes. Don't pay for scope.

Got questions?
Ask me anything.

Click to schedule a Zoom call

Drop me an email:

Find me on Twitter (DMs are open): @jeffcohen