BBC #02 - Scoping (Part II) What not to do

As always...

First things first

Here, in this article, I will not differentiate between Project and Product.

We will talk about digital products developed by freelancers and agencies, sometimes they end up being the “same” thing: an App for people to use.

Intro to Scoping

We have 2 types of scope:

• Closed: Fixed constraints (time, budget, and features)
• Open: Usually, one constraint is fixed (usually budget or time)

Most of the projects I’ve seen try to aim at Closed-Scoped, because it gives everyone (clients and agency/freelancers) a feeling of control.

With this, you start a project knowing:

• How much you will spend
• What you will receive
• When you will receive

But it’s also true that, usually, this doesn’t happen.

How many delayed and/or over-budget projects have you seen?

Actually, according to the Project Management Institute (2018), inaccurate time estimates are the cause of 25% of failed projects.

And that’s just because we are bad at estimating time.

We usually see things easier than they really are.

Scope = Constraints

Features x Time x Budget

These are the 3 key constraints you need to be looking at when scoping a project.

They are the edges.

But we can simplify it.

Let’s assume the budget is a function of time.

• If you need more time = more budget
• If you need less time = less budget
• If you need more time but the client wants it sooner -> you need more people = more budget

You got the point.

Back to the Closed/Open Scope.

I was working on a project recently in which the scoping document was complete.

At least we thought.

Clients approved the design, developers and designer had the handover meeting, I checked the design again and it seemed to be all connected.

When reality hit

During the project, we noticed a bunch of stuff was not decided.

• What happens to the user’s data if a user is deactivated?
• What happens if the user opens this screen and doesn’t finish what he/she started?
• Should we sort this by created date, modified date, or another sorting?
• This feature is only for subscribed users, what happens if the user starts using it and cancels the subscription?

I know that these seem to be simple questions to ask, and they are.

But the answers to these questions might not be so fast to develop and they were not considered when the project was being scoped.

Whose fault is this?

No, we are not blaming anyone. Sorry...

Unless you’ve done the same project over and over again and have everything necessary to build it written, you will never be able to closed-scope a project with 100% accuracy.

How do we fix it?

We open the scope a little bit.

Instead of giving an exact delivery date, we give a range.

Instead of giving an exact price, we give a range.

If your client agreed to receive the final project in 6 weeks for $30k.

They will also probably agree to receive it in 6 to 8 weeks for $30k to $35k.

But, if the 6 weeks delivery is a non-negotiable variable (hello, Time to Market!), you can always prioritize the features and save a couple of weeks not worrying about those details that 99% of the users will never notice.

That's it for today. See you next week!

Do you have a question regarding Project Scoping? Leave in the comments!

HOW - Highlights Of the Week

Chad Johnson - About Design and Team Collaboration

Pawe? Huryn - 390+ Product Discovery Questions

Eugene Segal - Product Podcasts