Shabnam Gideon

Part 1: Managing Scope Creep

Welcome to the first article in a series devoted to answering the question of how to keep projects on scope and within budget. In this series, we’ll talk about how we mitigate and manage scope creep during each phase of a project.

Managing Scope Header

“There’s a whole choreography to the delicate dance of managing a project for scope.”

This was originally going to be a single post, but I realized after writing my outline that there’s a whole choreography to the delicate dance of managing a project for scope. This orchestration begins well before you even have a scope, in fact, and continues on as a regular, deliberate practice throughout the project, all the way to whatever the end is.

For the sake of this series, I’ll break it down into these key tasks:

  1. Set your future self up for success
  2. Keep your present self on the ball
  3. Revisit your past self on the reg

This week, we start at the beginning:

Part 1: Set your future self up for success

As we’ve continually encountered “learning situations,” we’ve used them to create concrete improvements to writing scopes. The following measures, respectively, are key to improving the  contents, comprehensiveness, and manageability of our scopes, and we refine these constantly:

Do a discovery

Read more about why here, but the moral of this story is that with a success rate of more than 95% (still), we’re pretty sure you need a good Discovery like you need coffee when your kid wants to play Legos at 5:15 a.m. on a Saturday. If you don’t get it, you will never locate the piece hiding in someone’s ear and there will be anger and lots and lots of crying. And then you’ll have to go buy a whole new Lego set since you mucked up the last one. Find a way to conduct a Discovery and you’ll know exactly where the pieces will be hidden.

There’s a second moral, and I tell this to all my clients verbally during Discovery: the point of Discovery is to uncover all the questions we need to answer so that we can accurately plan the research and exercises to answer the questions. Put another way, the purpose of Discovery is not to answer all the questions; it is to expose all the questions so that you can give yourself room (i.e. timeline) to answer them.

Get quantitative

I mean in terms of what you will do and how many times you will do it. Obviously, since a lot of what Discovery give us is unanswered questions, this is not so easy.

Logically, though, if we take the questions/exercises from Discovery, and pair them with what we know to be the practical outcomes of each exercise, we can made some educated guesses about 1- what to do, 2- how long it will take, 3- how many times we might have to do it, 4- what outcome/deliverable there will be, and 5- how many outcomes/deliverables there might be.

That’s as much of a formula as there is, however, and it takes perspicacity, patience, and an open mind each and every project. You have to be able to not know, and then to put some parameters and measurements around that not knowing.

Practically, this means doing things like:

  • Setting maximums for the number of wireframes you will produce (and whether you’ll do them for all pages),
  • Limiting the number of responsive comps you will design,
  • Saying only that you will conduct an “exercise” but not specifying what the outcome may be,
  • Limiting the number of revisions on a content strategy document, and
  • My personal favorite, establishing a cadence to or finite cut-off for client approvals.

By establishing quantitative line items, you thereby have a known baseline from which to gauge any requests that call scope into question.

“You have to be able to not know, and them to put some parameters and measurements around that not knowing.”

Get granular

Put it on a timeline. Do it. All those quantified line items you arrived at, lay them out one by one, in the order in which they should be completed, and showing who’s working on what.

This step, no matter what application you do it in, is invaluable to having a clear picture of how long things will really take. A granular timeline makes you really see how much a person, department, or project can tolerate at a time; illuminates dependencies; makes you realize even more things you don’t know; and shows you when and where to schedule your people and where they need to overlap. It also shows you where you’ve done some wishful thinking timeline-wise and where you can contract it.

We use a simple Google Sheet for our timelines, because it’s simple. That said, what sounds like a simple linear timeline usually ends up looking more like a depiction of the multiverse, but still, having it all in one sheet is so much simpler than any other tool we’ve used. In fact, the timeline spreadsheet is the project go-to for most of our team members, even before Trello.

But the takeaway here is what it means for your projects: only by timelining a project can you accurately gauge how long a project will really take. Side note: you should probably also add 10% more time to your estimate as a buffer.


I’d love to hear other ways to prepare oneself well for an upcoming project. Like I said, these are all based on our experiences, and we certainly haven’t had all of those we’re going to have yet.

Stay tuned for the second in the series, Keep Your Present Self On the Ball, where we explore a little bit about mindset, and a lot about real-time transparency.

Thanks for reading!

Give this a share if you enjoyed it :)