If you do any kind of client work you’ve dealt with bugs and scope creep. Sometimes the line between the two can blur making for difficult conversations with clients.
It can lead to you doing extra work without extra pay, or your client paying for something they feel should be included. Either way no one is happy.
Side Note: One way to avoid the debate of bugs vs. scope creep with a client is to value price the project. You identify the actual value of the project to a client and price it at a premium that makes sense to you and the client. You’ll still need a clear definition of new features vs. scope, but the premium price should make you comfortable with any bug fixes. Check out Jonathan Stark for more on value pricing.
It Starts With Discovery
Discovery, as I define it, is the portion of a project that is used to collaborate with the client to define the requirements and goals of a particular project.
If you’re not charging for discovery you’re doing yourself and your client a disservice. You are the expert the client is turning to after all. They don’t spend the day-to-day in the minutia of building a website. That’s why they’re hiring you after all.
And likewise you don’t spend everyday working with their product or service. They know their users’ needs better than you, but you know how to make a website that can accomplish those needs.
When you start a project without knowing the overall goal behind the project you’re setting yourself up for difficulty down the road. And the potential to blow your budget.
If you have the chance to catch Dwayne McDaniel in-person at a WordCamp I highly recommend you ask him about discovering client goals. Check out his lightning talk from WordCamp US 2018. Definitely worth the 15 minutes.
Defining Scope
Once you know the overall goals for a project you can start defining the requirements to get there. Those requirements become the scope.
You want your scope document to be detailed enough to not leave ambiguity to how features should work on the site. The more intricate the implementation the more detail you should include. For example, if a requirement is to display a YouTube video on a site you should be certain to include how that functionality will be implemented. Will it use existing embeds
Let’s take a look at that particular feature as an example. First, we’ll break it down into the requirements.
Open YouTube videos in a lightbox
- Allow for embedding YouTube videos in the page.
- Set a thumbnail image to use for the link to open the video lightbox.
- When lightbox opens, the video should autoplay.Defining Bugs
Bugs is a pretty generic term that can be used to cover functionality issues where features of a site don’t work as expected or style issues like fonts not matching. As a developer you may have a more technical definition for “bugs”, but clients will typically refer to all the above and more as “bugs”.
Your job as a developer is to differentiate the bugs from scope creep and be able to explain that in plain language to the client.
Bugs vs Scope Creep
That’s a decently well designed piece of functionality. We know we need a way to set an image thumbnail, embed a video, and open it in a lightbox. Let’s take a look at some potential client feedback and decide if they’re bugs or scope creep.
Client: Video isn’t autoplaying when the lightbox opens.
This one should be fairly obvious as this was clearly defined in the scope. If the video isn’t autoplaying when the lightbox opens we have ourselves a bug.
Client: We want to display the duration and rating for the video below the thumbnail.
This one is a little trickier. The client is used to seeing the duration and rating of their YouTube embeds and likely thinks you’re able to use this as you please. But this would actually require integrating with the YouTube API. It may not seem like a big ask to the client, but this is a clear definition of scope creep.
Client: We have some videos on Vimeo as well, we’d like to embed those too.
Now we’re getting into different services. Since YouTube was clearly defined in the original scope we may not have built things in a way that’s easy to implement Vimeo as well. Especially if the item above was addressed. This is again, scope creep.
Client: The video isn’t resizing on mobile devices.
Here’s one that’s not defined specifically in the scope document. But I’d argue it definitely constitutes a bug. Unless it’s been clearly stated the site won’t be responsive. But who is doing that these days? The client will assume their site will work across devices without explicitly stating it.
Client: Can we make the thumbnail image larger?
The old, “Can we make that bigger?” feedback. It may not be explicitly in the design, but I’d consider this a bug. Though it isn’t a functionality issue and it may match the original design. The goal is to get the client a project that fits their needs. And if you’re not leaving margin in your estimates to cover enough time for adjusting an image size you need to be charging more.
Wrapping Up
Eliminating scope creep starts at the beginning of a project. By providing a thorough discovery phase you can eliminate surprises for you and your client. You’re the expert on websites, your job is to help the client define realistic requirements for the project as clearly as possible.
When bugs come up, and they will, be sure to consider if it’s really a bug or if it is scope creep. It may seem like a small thing at first, but over the course of a large project little pieces of scope creep will add up. The additional scope adds more potential for bugs as well creating a vicious cycle!
