Project scope, scope creep, gold plating, feature creep, scope discovery. What do they mean? The first time I hired a developer to work on my personal website, I had never have heard of them and had no idea these words were so important when working with an outsourced WordPress developer.

I learned it though as the developer, at that time, pointed out I was requesting changes that were off what he and I had agreed upon.

At that time, I hadn't realized I was going a bit over my requests and I had no idea this "approach" had a name too: scope creep. That's what I was doing.

After apologizing to my developer, and saying I was really sorry for doing that (in my defense: it was literally my very first time outsourcing development = #noobalert), I wanted to know all about scope creep. So I started to do some research. And the more I researched, the more I discovered a semantic world that developers do care about.

This world accounts for and is framed around 5 key notions.

As they're still obscure and not 100% grasped to many, I wanted to shed some light on them and help you understand what they mean, when they occur and why they're bad for your client-expert relationship.

Getting to know better these concepts will ultimately affect how good you'll be at hiring developers and get what you need to be delivered faster and better.

It's about money, your money. You'll see...

Ready to dive in? Let's start with the easiest one: project scope.

1. Project scope

Example of project scope

As one of the most challenging tasks for someone hiring a developer, defining a project scope is a critical operation because it directly affects the results you'll end up with. In "A Guide to the Project Management Body of Knowledge", project scope is defined as:

The work that needs to be accomplished to deliver a product, service, or result with the specified features and functions.

"The work that needs to be accomplished" should grab your attention because it's what you're in charge of. When it comes to a project scope, the work involved is where you'll need to invest your efforts on by determining the following aspects:

  • Specific goals
  • Desired features
  • Timeframes
  • Deliverables
  • Goals
  • Process requirements
  • Costs

In a shorter form, a project scope accounts for anything (and nothing less) that's required to deliver your desired outcome.

How to write a great project scope

One of the most effective ways to create a project scope is to write it following the SMART criteria, which is an acronym for Specific, Measurable, Attainable, Realistic and Time-based. Specifically, your project scope should be:

  • Specific: The goal should target a specific area of improvement or answer a specific need.
  • Measurable: The goal must be quantifiable or at least allow for measurable progress.
  • Attainable: The goal should be realistic, based on available resources and existing constraints.
  • Relevant: The goal should align with other business objectives to be considered worthwhile.
  • Time-bound: The goal must have a deadline or defined end.

There are variations to these criteria but, at the end of the day, it's all about providing a project scope that plays as the main roadblock for the work that's requested to be done.

2. Scope creep

Scope Creep

You might already have heard about scope creep because it's something developers are pretty concerned about. Scope creep happens when further requests or actions are required but haven't been formerly discussed with the developer, thus they're not clearly stated anywhere in your project brief.

As explained in Lewis James' "Fundamentals of Project Management":

Scope creep refers to changes in a project’s scope at any point after the project begins.

Scope creeping is a subtle beast as sometimes it's easy for you - the one asking for things to be developed - just to not put that much of attention and time into listing out all the things you'll need the developer to work on. And that's not good for you.

Here are some real-life examples of how scope creep might slip in in a standard conversation with a developer. After they've shown you their work (based on your brief):

You say: "All is fine. I just need another page, really a basic one with just text on it".

You say: "Cool! I think the form needs a couple of extra fields, though".

You say: "Can we add the contact form to the bottom of all new product pages?"

BAM! In all these 3 scenarios, the client - it could be you - is asking for additional things that fall outside of the original scope. This puts the developer in an awkward position and, even more important to you, the whole development work to a stall.

What happens then?

It's totally up to the developer you've hired whether to address (or not) your further requests. It might be the case that what you're requesting is really something that requires 1 minute of their time, or it's a favor you're getting because the developer really enjoyed working with you.

But that's not how things usually work.

Just think of this: if you were building a house and had agreed on everything with the construction company, wouldn't you expect to pay if you changed your mind about the types of materials, windows or tiles?

Yes, you'd expect to pay more.

Same happens when new requests, which have not previously discussed and agreed upon, rise to your developer's attention.

But wait, I know what you're thinking right now!

There's this little inner voice that keeps telling you:

Who cares about the developer? This is FREE work, c'mon! Just ask and see how they respond!

Well, that inner voice, on a business perspective, it's simply shortsighted (or plain stupid) because it just focuses on superficial outcomes, rather than your overall goals.

What I mean here is that downsides totally outpace upsides: the former result into project delays, higher costs, increased delivery time, and the latter into a tiny request being addressed without shelling out any additional money.

Is this the ROI you're really looking for? We both know, it's not.

3. Feature creep

Feature creep

There's a high chance that, if you're relying on outsourced developers, you're in need of someone with technical expertise to work on your next product or service. Maybe you're building your MVP to test your idea, some further iterations of your current product or even your renewed eCommerce store. It doesn't matter that much here.

Feature creep is always something you should stay away from because it will affect your users directly.

Why that? Let's start with its definition:

Feature creep refers to software or hardware that becomes complicated and difficult to use as a result of too many features. In addition to poorer usability, feature creep can cause a product to actually become less stable because of unintended results between the various components.

When working with a developer, listing out all the features they'd need to be delivered, you might want to take into account whether each of these will concur to enhancing or bloating your product.

For example: did you run tests to see if THAT feature would impact your conversion rate? Did you collect data to understand whether THAT feature will increase the number of your sales?

As Des Traynor, Co-Founder & Chief Strategy Officer at Intercom explains:

To solve feature creep you need to identify which features are being adopted by everyone, and which ones are struggling to gain traction.

That resolves into spending more time discussing with your colleagues (or stakeholders) what specific goals you're trying to achieve, hence listing out only those features that directly relates to them.

Another button on your homepage? Social sharing feature on a checkout page? Geolocation on your blog pages? Data will tell you.

Be aware that sometimes it's not a brand new feature what you want to have; there are cases where it's a matter of a UI tweak or updates in your copy that will get you what you really wanted in the first place.

4. Scope discovery

scope discovery example

This is a bit tricky to understand, yet it's really important so please pay attention.

Based on how much you (or your stakeholders) know about the project you're hiring a developer for, it might be the case for your project scope to leave out some important aspects that still have to be addressed.

This vagueness will likely result in several communications back and forth between you and the developer to get both a better, more specific understanding, and agreement on what should be done to address your needs.

In a shorter version:

Scope discovery is the discovery of key elements/aspects left out in the agreed project scope and brought up to stakeholder's attention because critical to the project success.

Best practice tells that, after scope discovery, the scope of your project should be updated, refined, hence less open to misinterpretation than before.

Let me give you an easy example to understand how this work in real-world.

You hire a developer to extend one of your plugins. You write your project brief, scoping the project properly, with all info and details in it. You set goals, milestones, deadlines and put in a nice budget.

All looks good, and now it's up to the developer to start working their magic, right?

Yes, but as soon you grant access to your website, the developer starts noticing that the plugin you'd like to extend needs to be updated. And to make things a bit more complicated, that plugin has some dependencies with other custom plugins, some of which are out-of-date.

Your original scope was focused on extending your current plugin but it had no mention of these dependencies nor the need to perform updates, right?

Through the scope discovery, the developer highlighted things that are critical to the correct completion of your current project but then stopped because they have no clue on how to proceed. This is not because they can't technically address the sub-tasks, but because they lack guidance on how to proceed.

At this stage, the developer you hired to work with would usually tell you about what they discovered and will ask you to update the project scope and probably adapt budget and deadlines as well. There might be some cases where the discovery phase would bring in new milestones too.

The important thing to understand here is that the discovery phase happens more often that you think, and it affects directly the chance of success of your project because it brings up things you had no idea you had to take care of while hiring the developer in the first place.

5. Gold plating

gold plating example

This practice has more to do with the developer's approach to work, rather than something you have to/don't have to do. Still, I'm listing this term here because by understanding what gold plating is, you'll be able to recognize it quickly and act accordingly.

Gold plating occurs when the developer deliberately adds features or functions (no matter how "big") that haven't been requested, nor agreed upon in the project scope.

Usually, gold plating is used by developers to show off they're good in what they do, or done by project managers to show the client they delivered something "cool".

Thing is, gold plating might sound like a bargain as you're getting "something more" for the same price. But it's not.

If you hear something like:

"I know just a couple of things that will make your X BETTER"

What would your reaction be? I'm taking a stab in the dark, but I think it'd be something like:

"Little things to make it BETTER? Score! Go for it!"

Poor you...

Well, the problem is you got tricked by the word "BETTER" and didn't realize how "BETTER" will affect your project eventually.

Blinded by some free work thrown your face, you failed to further question important aspects such as:

  • Better to whom?
  • What other things will be required to keep the BETTER run that I haven't budgeted for?
  • Will I need further help with this BETTER version?

See my point? Free things aren't always the best because you might end up with more work to be done than before. At least in the development world.

Wrapping up

Working with remote and outsourced WordPress developers isn't the easiest thing in the world. It requires you to translate into a written and clear form many of the usual practices and actions that usually happen among professionals facing one another. If not done properly, this opens the room up to miscomprehension, vague requests, assumptions and everything that might turn into undesired outcomes and delays.

Knowing more about key concepts and notions here outlined related to outsourced work gives you a leg up in terms of tackling your next project. In addition to that, a better understanding of these notions improves the effectiveness of your overall hiring and managing process of outsourced developers. And that's something your wallet has been waiting for ever since.

Codeable... Where Realistic Clients Meet World Class WordPress Developers

Post Your Project Today

  • Trade Southwest

    Very good points and I like how the article was written to address the client as well as the developer. A well defined scope not only keeps everyone on the same page but it also allows for the initial estimation and cost breakdown to be an easier task.

    As a developer I have found there are many clients that are actually not very clear on the “full” scope out-of-the-gate; and sometimes that is part of what they come to codeable for: to find out what “really” needs to be done to make the project work. As a suggestion to anyone who is posting a job to Codeable, it helps everyone to have—at minimum—a document or spreadsheet with a ‘game-plan’ well defined. Even if you are not sure of your GOAL(s) the worst that can happen is you might find the list of items you need done can show a developer that you are at least prepared to reach that goal.

    A simple bullet list can do wonders for the chat-room like workroom conversations. As we all know, questions can get confusing in a chat environment. A list of TODOs is much clearer for both parties.

    • Hey there!

      I completely agree and that’s why I always suggest to do “your homework” before posting a project. Whether is a more defined document, with goals, needs, deadlines, etc. or – as you suggested as well – a simple bullet list with your game-plan defined.

      “Give me six hours to chop down a tree and I will spend the first four sharpening the axe.”

      That’s the right approach when it comes to hiring a developer/designer: prepare all info, data and requests you can before even posting your project.