I recently finished reading Creativity Inc. and one of the sections really stood out to me. There’s a part where the author is talking about teaching people to draw and how our preconceived ideas of what an object should look like can cause a free hand drawing to have weird proportions. Maybe we focus too much on the spacing of a chair’s legs or the shape of a person’s nose. The point is, that the way things look vs what we imagine them to look like, is part of the reason why a novice artist will draw objects with unusual proportions, even if they have a perfect image of it in their head.

One workaround is to tell the artist to focus on drawing the negative space around an object. Without any preconceived ideas about what the space between the parts of a chair look like, someone can create a much better representation without any additional practice. So how does that apply to project planning?

Looking for the negative space

In the early stages of planning a project, we always consider what’s in scope, and what’s out of scope. Before something is officially deemed out of scope, consider what all the potentially out of scope work is. Also take some time to consider related work that we haven’t originally considered. All of this work can be considered the “negative space” in our drawing of a chair.

Now we dive deep into the negative space. What are the risks, complexities, and dependencies of the out of scope work?

Risks

• What are the outcomes if we don’t do those things?
• What would we expect the outcomes to be if we did do them?
• Are we saying that we’ll never do these things, or that we’re not doing them right now?
  • How can we preserve all this context so that when we decide to come back to it, we don’t need to spend as much time getting back up to speed?
• Are there competitors that already have the functionality that you want to remove from scope?
  • Is this functionality considered a “satisfier”, where it’s just table stakes and you have to have it?
  • Is this functionality considered a “delighter”, where it’s a nice-to-have, that could make you distinct in the market?
  • Or is the functionality overall just not that important?

Complexities

• What new problems would we create by removing these things from scope?
• What old problems will continue by removing these things from scope?
• Consider how long you’ve already left these fires to burn without putting them out. In some cases, you may also need a communication plan for why a fire continues to burn. You’ll need to get all the relevant stakeholders to actively commit to this path, even if they don’t agree

Dependencies

• By removing these items from scope, whose work is impacted?
  • Don’t just consider your team. Think about all the other product development teams, or even sales, customer success, operations, etc.

For example

In a project my team worked on last year, we worked with another product team to create a new module. When we created the module, we agreed that a UI to continually update the data was not in scope. The justification was that the new module was an experiment, and our assumption was that we would provide enough data in our first iteration, so we wouldn’t need to continually update it.

We managed risks by preserving this context in our “parking lot” of ideas, and validated the assumption with a few users ahead of time. There weren’t too many competitors with a similar module at the time.

To manage complexities, we developed a communication plan with the revenue side of the company to explain why we weren’t going to update it, even though we generally update most of our data daily.

We didn’t identify any dependencies when we made our decision on scope.

Now that a few quarters have passed, we’re getting feedback from the revenue team that we may need to revisit our assumptions on updating the module. Because we’ve preserved the context, we were able to get up to speed on it in a few minutes and now we’re in a place where we can do additional validation conversations with users and decide if we need to revisit the scope of the work.

Wrapping up

By taking the time to examine out of scope work, you can plan projects better, and make your life easier when you return to an old project to add more functionality.