Freelancing is supposed to be fun, right? You set your own hours. You choose the work you find interesting. If you’re a solid developer, you can pull down a respectable income while maintaining some of that mythical “life” everyone in the startup grind is always fantasizing about.
At least that’s what I thought when I was 19. I was a young developer, eager to do my own thing and set my own pace. As with so many 19-year-old developers, eager to do their own things, eager to set their own pace, I had no idea what I was getting myself into.
It all started pretty innocently. Really well, actually. I took on a big, respectable, full-stack job with an entrepreneur in the nonprofit sector. He was looking to build a “LegalZoom for the 501(c)3 set,” and I was going to build it with him. From the ground up. This was the kind of gig I thought I wanted as a freelancer: the kind where I’d be solving an interesting problem, and creating something new to the world.
The client and I were both very excited about the possibilities. There was a great personality fit. Right from the start, we got way ahead of ourselves; we dove into the project, and all of its possibilities, before working out a contract for the engagement. After all, the contract seemed like a formality.
You can probably tell where this story ends: with massive scope creep, heartache, and crying children. (Well, crying 19-year-olds, anyway.) In our haste to get started, in our eagerness to think and rethink every possibility, we failed to map out or stick to a development plan. We had no specific deliverables. Just the big picture. So when we finished up the site, we found ourselves ridiculously over budget–and on entirely the wrong platform. I was devastated. One of my first big jobs as a freelancer, and I’d exhausted myself on it, to no avail. I’d probably pulled twice as many hours as I’d anticipated, with half the results I’d wanted.
So why did we fail? It wasn’t for lack of cooperation, or shared vision, or mutual enthusiasm. We didn’t fail because we fought all the time, grinding the project to a halt. We failed because we agreed too much. We failed because we said yes to everything and every possibility. We didn’t make choices. We didn’t know when to say no.
Scoping a project is the art and science of saying yes and no. It’s the process by which you, as a project leader, work closely with your freelancer(s) to set up realistic goals, deliverables, and timelines. It’s how you say “yes” to the things that matter, “no” to the things that aren’t feasible, and “maybe” to as few things as humanly possible. (In fact, if you find yourself saying “maybe” a lot when scoping, that’s a good sign you take a step back.)
You can hire the best freelancer in the world–a legendary 10xer, astride a winged unicorn, armed with referrals from Google and Facebook–and you can still fail spectacularly. Even the best of the best have to know what they’re getting into. And if you’re going to work with the best–or even just the very good–you have to know where to lead them. This can be an extremely challenging task, not to mention intimidating, especially if you’re hiring a subject-matter expert in a domain where you’re a bit out of your technical depth. No matter how smart you are, you assume that an expert is going to be a lot smarter than you in his or her given domain: be it a platform, a language, a business vertical, or an API. So it’s natural to put a lot of trust in the developer’s hands: that’s why he or she is the expert.
But when you hand a developer a blank slate or a blank paycheck, you’re not showing any trust. It’s inevitable that you’ll have change orders, shifting requirements, and countless headaches when you adopt a mindset that says, “I’m not sure what I want, but I’ll know it when I see it.”
So what do you do if that’s actually the case? Oftentimes it is, and there’s no shame in admitting it. Let’s say you know you want to use SendGrid to send transactional emails and track open rates. You know SendGrid is the right tool for the job. You’ve never worked with the API before. You don’t know how long it’ll take, or how much it’ll cost. There may be quite a bit of information on this topic–more than you can wrap you head around. At the same time, you’re not sure if it applies in your unique case. So how do you set a realistic scope when you are struggling to define what you want?
The best freelancers are ready to help you with your scoping process. They know that the first 30% of an average project is spent scoping. Unfortunately, most freelancers don’t know to do this. It’s common to hear a freelancer say “My client has no idea what they want!” The best way to help your freelancers out is to be prepared with a well thought out scope of work.
My friend Matt and I co-founded WorkMob to help solve this problem. Because we’ve been there, on either end of the situation. As I mentioned before, I’ve been the frustrated freelancer on a scope-creeped project. I’ve also been the project lead.
WorkMob supports the leading platforms (and cross-platform integrations) for payments, email campaigns, customer service, and other common use cases. We have a “mob” of expert developers for SendGrid, Zendesk, Balanced, GoCardless, and other major platforms.
No two projects are exactly the same. But all projects have a lot in common. Every project needs well-established deliverables, precise parameters, flexibility in the right places, and rigidity in others. Those are the factors WorkMob helps you establish. You don’t need to be smarter than your expert to get the best work from him. You just need to be smart about scope.