Scope Creep: Constraints, Products, and Time

Regardless of the type of project you’re working on – being side projects, freelance projects, or corporate projects – one of the things that plagues businesses the most is scope creep.

To be clear, this is not an indictment of any one party – this is something that affects anyone and everyone who is working on a product.

Look at it this way:

  • For side projects, we convince ourselves that adding just one more feature will make it all the better than it is in the current state never mind the fact that you can continue to work on this as your time permits.
  • For freelance projects, we either take the route of convincing our customer than this will be one more thing to enhance the experience, or the customer asks for just one more thing in order to “take it to the next level” never minding the idea that there is time, budgets, and constraints involved.
  • For corporate projects, this may vary widely but it can go anywhere from upper-management saying that feature-X should be implemented in order to stay competitive, or it can come from a major third-party client who has the money to fund the quick turn around of a feature.

The reason that I believe this is important is two fold:

  1. Products should have lifetimes.
  2. Time is our most valuable resource.

Nothing novel, is it?

Scope Creep Creepin’

In this industry, if scope creep wasn’t such a big deal, then there wouldn’t be articles, blogs, and books published about it. Similarly, I wouldn’t even be writing a post about it.

But the thing is that we – as both developers and customers – should do a better job of working within constraints, welcoming product lifetimes, and facilitating better use of our time.

1. Constraints

This is easy, right? Requirements are what define the constraints of the project. Think of them as the parameters in which you have to work to achieve whatever the goals are of the current version of the project.

As soon as something else shows up in the queue of work that does not fit within the constraints of the project, backlog it.

This is not saying no – this is saying “not right now.”

And that’s a good thing! You’ve just given your project another version that gives your customers something to look forward to having.

What good are constraints if you ignore them? When is a project done if you keep adding to it? Why would you not want to continue to grow a product?

2. Product Lifetimes as Good Things

We live in an age in which every single app that ships seems like it has to include everything before it’s considered to be complete despite the fact that many of us have extraordinary respect for people like Steve Jobs, Apple, and the like (I know, it’s easy to use the poster child as the example).

How is that we can simultaneously love the innovative work that people like this have done, claim we want to learn from them, yet disregarding everything that they taught us while working on their respective products?

Our projects should not be a one time launch with every option available. Release a strong 1.0, then build and improve over time.

3. Time Is Our Most Valuable Resource

I don’t know what people tend to perceive as our most valuable resource, but I know that it’s not money despite what many would have s believe.

Money can always be replaced, but time can’t be.

And this isn’t about time working, or time spent during leisure activities, or time spent reading, or time spent with family and friends – it’s about all of the above. Once those hours are gone, they’re gone.

This pertains directly to development because it’s worth asking if spending time cramming in that one last feature that doesn’t make or break a product is really worth sacrificing doing any of the above.

Perhaps sometimes it is. I don’t know, and I’m not one to judge. Personally, that’s not how I opt to spend my time.

Don’t let the idea that we’re running out of time force your hand to building something into a product that could always wait until tomorrow.

Scope Creep Is a Creep (But Why?)

We all know scope creep is bad. We can all write about our negative experience and disdain for scope creep, why it sucks, what it does to the quality of the code that makes up a project, and so on.

And, again, this isn’t about any single party – this is about all of us. But despite all of the above, scope creep still exists, and we still work with it.

Why?

I don’t have an answer, but I’d love to see all of us do a better job at managing our constraints, requirements, product lifetimes, and personal time in order that we can not only build better products, but also enjoy our time away from work just as much as we do at our work.

Sounds a bit like a Hallmark card, I know, but still – it’s the truth.

4 Replies to “Scope Creep: Constraints, Products, and Time”

  1. I’ve started keeping track of project time (for projects that have a fee for a maximum number of hours) in QuickBooks as “unbillable” (word to the wise: make sure you UNcheck the box in the QB timesheet that says “billable,” or you’ll be telling the client you’re good on time when you’re not). That way I can frequently run a Time for Unbillable report to track the time and keep the client on track, with good communication, and let them know if I go over, it will be at my hourly rate, per the contract. Some may moan and complain, but some, like my favorite agency client, will start to prioritize what they want to fit into the time left. Not a golden bullet, but it’s a good start. Then, you also have the data necessary to decide if you’re charging enough for a certain kind of project. Agency client has been informed that subsequent web project quotes will be higher.

    1. That way I can frequently run a Time for Unbillable report to track the time and keep the client on track, with good communication, and let them know if I go over, it will be at my hourly rate, per the contract.

      Smart – that love!

      Some may moan and complain, but some, like my favorite agency client, will start to prioritize what they want to fit into the time left

      Exactly! It’s all about delineating between the nice-to-haves and the must-haves and nothing does that better than showing time is money in the context of a project.

      Not a golden bullet, but it’s a good start.

      Bingo!

  2. Be sure not to confuse project scope with product scope, or intertwine them. One may remain constant, and another may expand. In either case, having a scope statement drawn up before/while composing the statement of work before the project begins will help control any scope creep. Listing the deliverables and writing out the scope statement gives you a tool to later be used to refocus stakeholders later as well.

    1. Be sure not to confuse project scope with product scope, or intertwine them. One may remain constant, and another may expand.

      Great, great reminder.

      In either case, having a scope statement drawn up before/while composing the statement of work before the project begins will help control any scope creep. Listing the deliverables and writing out the scope statement gives you a tool to later be used to refocus stakeholders later as well.

      Exactly – and I think both developers, designers, and stakeholders will all be glad to have something to keep them on track, to speak. No surprises, you know?

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.