How To Scope Your Work As A Freelancer So You Never Work For Free

If you are super busy, then in short “you need to define your scope of work properly, before you start working on the project”. I’m working as a Freelance FullStack WordPress Developer, so most of my examples will be around web development. But I’m pretty confident, that these principles can be transferred to other freelancing careers as well.

What is scoping and why is it so important for freelancers?

A Scope of Work is a document which precisely describes the work which will be delivered to the client by you. If you do not precisely define the work which needs to be done, how the hell you dare to price it? Most probably, you simply scratch your beard and throw some random number on the client. Then you work on the client’s project and keep praying that you will somehow fit into the budget.

How to tell a good scope from a bad scope

The difference between these two is in the level of detail and in catching any edge cases. For example, everyone who has freelanced as a WordPress developer for more than half a year can throw a line like this:

Bad Scope

“On the homepage, there will be implemented a slider with 3 slides, taken from WordPress Posts.”

Why is it bad?

• The description is too general
• There is a lot of room for interpretation
• Room for interpretation almost guarantees conflict with your client, which will cost you money in the long-run (negotiating, client satisfaction, client feedback, etc)
• Honestly, how are you going to estimate this?

Good Scope

"On the homepage, there will be implemented a slider

• The slider will be a “carousel”
• The slider will have arrows on the left/right side and dots on the bottom for navigation
• Autoslide will be 5 seconds and when the user hits any action, the autoslide will be terminated
• Images in the slider will be taken from the latest WordPress posts, ordered by date
• On desktop and laptop, there will be 3 columns, on a tablet, there will be 2 columns and 1 column on a mobile phone
• There can be a maximum of 1 revision to this design. Additional revisions will be on an hourly rate basis
• The slider will be powered by a javascript library XXX.js. Future updates of this library are not included in this scope."

Difference between the good scope and the bad scope

You will have to make decisions about the slider type, properties, responsiveness, and functionality at some point in time. And, based on the combination of the properties mentioned above (slider type, design, functionality), the amount of work differs significantly. So, until you scope it properly, you will have a Schrödinger’s slider.

You have in mind a certain type of configuration, so you’ll reserve 5 productive hours for this. But your client has a very different interpretation of what slider is for him and he is the micro-manager type, which translates into moving those arrows for 5 pixels towards the top or bottom. Bam! Now you will spend 10 productive hours on this slider.

Quick maths, you’ve estimated for 5 hours and spent 10 hours on it. By not scoping the task properly, you just worked an additional 5 hours for free. Or worked 10 hours for half of your hourly rate, depending on which view you prefer.

I have to say, that as I've started being a part of Codeable, my estimation ability has risen dramatically. The better you get, the easier the estimation is. The smaller the scope and the happier clients.

The client will know exactly what they are getting from you

If you look at the “good scope” example, it’s all clear there. The level of uncertainty is pretty low, so I, as a client, can rely on the output and I’ll be more assured, that everything will be delivered accordingly.

Also, as the client, I honestly did not know that it would be better to have the autoslide functionality disabled after first user interaction, so that it doesn’t annoy website visitors. It is your job as a top-notch freelancer, to know these things. And just by knowing them and presenting them to your client, you are demonstrating your quality. Based on my experience, by scoping properly, you can win the client over.

You will know what to deliver and how to price it

This way, you are able to cut your relatively big project into smaller parts and estimate them properly. My basic estimation unit is 1 hour of deep productive work. The slider is just one part of the website which needs to be estimated and now we know that, we should reserve approximately 5 hours for it.

This way, we can iterate through the homepage and estimate all smaller elements on it. Then we know how we can price the homepage. Running this process through all other pages and adding up the numbers together, we get a pretty good idea about the time we should reserve for the whole website.

You will be protected against scope creep

When there is a room for interpretation, every new demand from your client means you have to evaluate whether it should be done as a part of the original scope. This is usually hard to discern as well as time-consuming, but if there is any disagreement, then either the client is left feeling short-changed, or you are left working for free. This all is avoided when the scope is crystal clear.

The magic behind creating a great scope

The winning situation is when the client is getting excellent results and you get paid for the whole time you have spent on the project. It wasn’t happening for me, so I formed some rules and tactics on how to get to this point.

It would be worth mentioning that the better you are in your job, the more value you bring to your client and the more suggestions you can implement. Of course, if you’ve started learning WordPress just yesterday, it is unrealistic to bill your clients upfront, because no-one will be interested in working with you on these terms. Some clients also come and go, and just as you cannot be a good fit for everyone, not every client will be a good fit for you.

Don’t underestimate because you feel bad - have the statistics ready

At the beginning of my freelance career, I would estimate a simple-looking project for hundreds of dollars and then tell myself, "it can’t take that much time." I felt like I would be ripping off the client if I stuck to my original estimate. So I would submit an offer, which was like half of my original estimation. Of course, the time it took me to complete the project was usually 3 times higher.

I was making business decisions based on my feelings and although feelings are great (and surprisingly for my friends, I have them too), basing your hourly rate on feelings and calculating your hourly rate based on data provide substantially different outputs.

So, I introduced the hour of productive work and started tracking the whole time I spent on a project -including every single interaction with the client. The results honestly surprised me. In reality, I was earning approximately 30% of what I “felt” my hourly rate was.

By having complete statistics about every project, you can figure out interesting things, such as:

• Your real hourly rate, without any doubts
• The type of projects which provide you with the best income
• In what type of projects you suck and always lose money
• Your best client

Count all the overheads, not just writing code

Based on my stats, I’m able to work approx 90 productive hours per month or 4.5 productive hours per day. But I also have to run the company, write this blog, work on leads and continually improve and learn. So I can do like 60 - 75 billable hours per month.

Based on my observations, almost every project can be divided into these phases:

• Pre-hire communication and scoping
• After-hire communication
• Actually writing the code
• Communicating, showcasing the work
• Doing revisions and adjustments
• Handing over the work
• Post-hand-over support

Of all the time I spend on the project, “actually writing the code” accounts for between 50% – 90% of the time, depending on the project size and clarity of the scope. If you think about it, you can’t write the code without going through all the phases. I mean, you could, but you would deliver terrible results.

• Without pre-hire communication – you would not be able to define the task properly
• Without after-hire communication – you would not be able to fine-tune the work exactly according to the client’s ideas
• Without showcasing the work – the client would not know what they are getting
• Without revisions – the client will not have the result in the way they imagined
• Without handing over the work – the client will simply not have the work
• Without post-hand-over support – the client would be screwed up and the work will be almost useless

In the beginning, I only considered “actually writing the code” as billable work and I was absorbing the cost of the rest. From today’s perspective, I see that all these phases have to be done in order to successfully deliver the project, so all these phases are considered as actually working on the project. So I’m billing all of them. Even the time I spend in pre-hire communication is factored into the estimate provided to the client.

Quick maths: if the overhead is around 35%, then from 60 hours I worked on client projects, I would only bill 39 hours per month. Meaning I would work 21 productive hours, or 23% of my productive time, without getting paid for it.

Please, use the advice above wisely and try to reflect on your current skills. For example, if your English skills are very poor, then the time you spend communicating will be significantly longer. You should consider not billing this time because someone else would be able to talk through the details much faster and I would not think it fair, billing the client for something I haven't mastered. Apply the same logic to the other parts of the work process.

Actively think, and ask yourself “what if?”

Thinking hurts, I know. Being thorough hurts even more (at least for me: I love the chaos!). But these things are an absolute must-do, when you want to be a world-class freelancer. So when I’m estimating a project (be it a website or some hard-core integration of 3 WordPress plugins together with WooCommerce), I’m always carefully going through the small details of the project and trying to find the edge cases.

I’m looking at the project through the eyes of my client and figuring out what they would like to achieve. What are their priorities? What are their values? Which things would be important for them?

Then you can notify the client about potential problems they might be facing and propose solutions, in a way which brings them value and is aligned with their targets.

There is a huge pearl of wisdom in the Albert Einstein quote: “if I were given one hour to save the planet, I would spend 59 minutes defining the problem and one minute resolving it.” I’m always crystal clear on what the client wants and what I’ll deliver, before we start the job.

Accept that there is always a risk factor

Being crystal clear on the scope does not always mean that every single detail is lined up and known upfront. The bigger the project you are scoping, the more uncertainty there will be. This happens because as the complexity of the project rises, the uncertainty rises exponentially. There are always some hidden dependencies, relationships, and facts, which are impossible to predict or catch at the start of a project. The sooner you accept that there is always some uncertainty and risk, the easier and happier your freelance life will be.

The nice thing is, as you gain more experience in your field, you’ll be able to predict the problems in advance, because you’ve already made similar mistakes in the past. This is one of the perks of hiring a top performer and if you are one of them, you should definitely reflect this in your pricing.

Think about the risk and how to deal with it wisely

Properly dealing with risk makes the difference between earning as a world-class freelancer and coding from your mom’s basement. When I’m doing my obsessive tracking of work, I’m sorting my projects into multiple types:

• Migration
• Speed Optimization
• Debugging
• Easy Development
• Medium Development
• Hard Development
• Integration
• Update
• Full Site Build
• Consultation

Then, at the beginning of the new month, I get my excel macros to generate me a nice report of my earnings. Based on this report, I was able to see that my average hourly rate in “Hard Development” was approx 40% – 60% of my target hourly rate. Through analysis, I have figured out that I’m estimating the projects properly, but there always pops up something which makes the project significantly harder. And then here I am, sitting in my chair and sadly looking through the window, seeing a nice and sunny day on which I would love to run through a meadow and catch butterflies. But I have to sit down and write the code because I’ve screwed something up.

I had not been dealing with the risk factor properly and I was absorbing 100% of the risk. In principle, the bigger the project is, the more risk you want to transfer on your client. Here are some tools I’m using to deal with the risk factor as a freelancer:

• My initial communication is 1-hour per client maximum without billing – as we talked about above, communicating with the client is an essential part of delivering great work. When doing the pre-hire talk, you are still bearing the risk, that you’ll spend 5 hours on your client’s project and they will decide not to hire you. And 5 productive hours is a significant part of my working time. So I’m basically transferring the risk to the client, by explaining to them the situation and proposing that we can purchase a block of hours, which can cover the communication and scoping. Remember as we described above, creating the scope is work as well, and it is necessary in order to deliver a great project.
• I’m factoring a “risk” budget into fixed price estimations – we freelancers tend to estimate with an idea in mind, that absolutely everything will go smoothly. But then you get server access from your client and it’s not working. And then you get a new one it’s not working again. And then the server is really slow, which makes the job more time-consuming. And then the server has an outage. And then you discover some twitch in the plugin you wanted to modify, which adds 2 hours. And then you are waiting a week to get an answer from your client, so you completely lose context for the work and you have to remember it again. It is guaranteed that at least one of these things will happen. And they are not reflected in your scope and price. So I have a risk constant. This means that I’ll do the estimation (including all the communication, setting things up, etc) and then I’ll multiply it with the risk constant, which is currently 1.36. This helps me to cover the risk, which is hard to estimate. At the end of each project, I go through evaluation and this includes adjusting the risk constant to keep it accurate.

• Most of the larger projects I take are billed per hour. Since they are almost impossible to scope properly and I do not want to be accountable for the risk, this is the smoothest solution. I’ll provide the client with a probability based estimate, which is more of a range. Like: "the best scenario here would be 43 productive hours, the worst scenario would be 76 productive hours and you should expect to be somewhere in the middle. The client then purchases hour blocks, which are burned by working on the project and I report to them on a weekly basis. I also consult with the client on where the time should be spent and propose next steps.

Be prepared: not all clients will accept this style of cooperation, which is completely ok. It is up to you now, and you are free to make the decision on how to deal with the risk factor. But if you do not deal with it somehow, you’ll end up earning less than you should, be stressed and end up working for free.

How does it work for me so far?

When I was starting my freelancing career, I wasn’t satisfied at all. I did not understand these basic principles, and I was often working for $10 per hour. Then, I improved my approach on how to deal with clients, scoping, pricing, risk factor, and other things and I started getting better results. Remember, the change is evolutionary, not revolutionary. Step by step, as you get better at freelancing, you get more negotiating power and you can incorporate more of the strategies mentioned above.

So my current result is: I’m getting paid the hourly rate I’m aiming for. I’m not stressed. My risks are covered, so I can barely remember working on a project for free and hoping that the nightmare would soon end.