I get it: collaborating with someone on a project for your design clients can be unnerving, no matter how many times you’ve done it before.
This is especially true with web development. If you don’t know a lot about the development process, you wonder what the heck your developer is even doing; if you do know a lot, you wonder if she’ll be able to do your design justice. Ultimately, you want to make sure your project is going to finish on time—and on budget!—so that you don’t look foolish in front of your client.
Luckily, there is something you can do to help said projects stay their course. If you stick to this one rule, your developer collaborations are much more likely to be a success.
The one rule you must follow when collaborating with a developer
You might be surprised to hear that “the one rule” is more about project management and client relations than design or development.
So, what is “the one rule?” Project scope.
What is project scope?
In the context of a development project, scope is like a big list of everything that the project must have and do. Features, functionality, interactivity, and appearance: all of those come together to create a project’s scope.
Though you may not realize it, your design projects have scope, too. When your client chooses a package or requests a particular set of services, they’re helping set the project’s scope by telling you what deliverables they need. And, just like you wouldn’t let your clients add extra services without paying for them, you shouldn’t let them add extra items to a development project’s scope.
When a project deviates from its scope, it is said to be experiencing scope creep.
Why scope creep means certain death for your project’s timeline and budget
When you receive a proposal from your developer, it’s been created with a particular set of features and functionality in mind. In fact, many proposals have a clause that states they’re contingent upon the mockups or additional information provided so that developers aren’t stuck honoring a price that doesn’t fit the project’s workload.
So, if the final mockups contain more or different features than were originally discussed with your dev, the original proposal won’t be valid…meaning that the original timeline and budget go out the window, too.
How to avoid scope creep from the get-go
Ideally, when you get a proposal from your developer, you’ll already have the site’s mockups in hand. You’re a lot more likely to get an accurate quote when your developer can see the whole picture up front, but that’s often not practical. Usually, you need to get a development proposal before the project has officially started so that you can build the price of development into your own proposal.
In that case, to avoid scope creep right from a project’s beginning, you’ll need to do a little digging.
Before you approach your developer with the specifics of the project, pick your client’s brain about the things they want and need on their new website. Good things to know are:
- What platform do they prefer the site be built on?
- Do they need a blog?
- How many pages will the site be?
- What kind of content will each of those pages contain?
- What kind of forms do they need? Do those forms need any special logic or functionality?
- Is there anything about this project that may make it special or different from a normal website build?
- Is e-commerce or membership functionality needed?
If you can answer those questions for your developer, you’ll be well on your way to an accurate proposal right from the start. And as a bonus, you’ll be better able to create a proposal for the client that ensures you’re appropriately compensated for the amount of work you’ll be putting in to the website’s design!
What to do when your client wants to make changes to a project’s scope
You’re not the only one with a lot of skin in the game during a designer/developer collaboration: your client is on the hook for a lot of money and time as well. She’ll understandably be a little nervous and excited about things, and sometimes that energy manifests itself as project change requests.
Once you have an agreement in place and the project’s wheels are turning, changes will undoubtedly have an effect on the timeline and budget. If your client approaches you with a list of change requests, don’t panic! Usually, all you need to do is educate her about how the proposed changes would affect the project. Some clients aren’t even aware that their requests would throw a wrench in things, and when they find out, are happy to proceed as originally planned.
If your client is insistent on integrating the changes, though, you have a few different options. Try to find some middle ground with her: propose an update at a later date to integrate those changes without affecting the current project, or talk to your developer about what the extra costs and time would be required and send that information on to your client so she can make a fully informed decision.
If you can stick to the rule of setting and maintaining your project’s scope, everyone will be happy when the project ends by the original deadline and without extra costs!
Put your next developer collaboration on auto-pilot...
…with the From Mockup to Code Mini-Toolkit! Includes the FMtC Checklist (covering everything you must send to your developer before your next project starts) and the 9 Tips Worksheet (covering steps you can take to prep before your next project begins and giving you tips throughout) for a seamless collaboration from start-to-finish.