TFS 346: Setting Boundaries on Engagement Scope
In this episode of The Freelancer’s Show the panel discusses setting boundaries on the scope of engagements. This means not taking jobs that are too big or too small for you. They begin by define projects that are too small. They explain how many may not realize that there is such a thing a project that is too small. A too-small engagement may be too short in duration or not profitable enough.
An example Erik Dietrich shares is a two-hour job that is three hours away and they are only paying your $200, between travel, and labor that is 8 hours of work for only $200 which is not worth it. Jeremy Green shares an example from his past. He fell into the trap of taking on 2-hours per month retainer contracts. The problem with contracts like these is that clients cannot intuitively understand how long things will take or may feel that the 2-hours they paid for should roll over when a month goes by without using them.
They explain how setting boundaries defining what is too small is better than trying to use your judgment at the time of the engagement. Many developers have an any work is better than no work mindset, the panel explains how this is not true especially when you are losing money to the overhead of communicating for 5 hours, doing a 5-hour job and only getting paid for 5-hours of work, ostensibly cutting your profits in half.
Erik walks listeners through a helpful exercise of putting numbers to your costs, working your way backward through the numbers to decide how much you would actually have to make in order for a project to be worth your time. He explains that he wishes he had started doing this years ago. This exercise will also arm you with information that will help you from a negotiating perspective. It allows you to speak with authority about what you will and won’t do, giving you the power in the sales conversation and allowing your clients to see what they are really asking of you.
Besides the time spent and how much money you will make, the panel shares another scoping boundary, turn around time. They explain that if a client tells you they needed this done yesterday, run. It is a red flag, this means they haven’t done enough planning and it will only lead to a bad situation. Jeremy explains the difference between those who say they want it as soon as possible and those whose hair is on fire and they need it now now now.
Some ways to set boundaries for this is to require a certain number of weeks before you can begin a project and a certain number of weeks for actually working on the project. By setting these boundaries you make sure the project is sane and workable. Erik explains that as the professional you have the experience to set a reasonable timeline for the work required, which means you should have control over the conversation of time.
Next, the panel moves on to establishing boundaries with clients. They explain the importance of setting expectations when it comes to contacting your and the hours you keep. Also, set expectations on how quickly you expect them to respond to you. Jeremy shares times when short projects were dragged out because the client failed to respond to his emails. The panel discusses strategies for getting feedback from clients and escape routes for when clients refuse to communicate.
On the opposite end of the scale are projects that are too large of an engagement. How large is too large depends on the individual. Some developers may want a year-long contract where they work full time on one project while others may be looking to build a consulting practice. However, no matter what you are looking for it is always possible to get in over your head.
The panel advises listeners to have a realistic view of what you can actually do and what you want as a freelancer. Do you want to work solo or over a team? This decision will affect the types and sizes of jobs you will take. You don’t want to take a job that should be done by a team when you want to remain solo, on a similar note you wouldn’t want to take on a job that you could do alone but still have to pay a whole team.
The panel warns against taking on projects with an undefined scope of work, something vague like building an e-commerce site could be dragged on and on as the client adds on more and more features they want. They advise that if you take a job with a project fee to make sure you charge for discovery. Jeremy shares a time where he agreed to one job and once he saw the code he realized the job was not what he agreed to. The panel shares ways to avoid this problem. One way is to agree to work for a number of weeks and revisit the scope of the work after getting your hands into the code.
Now that they have explained how to set your boundaries, the panel shares advice on how to disengage from engagements that do not fit the boundaries you have set. The engagements that are too small are easier to disengage from. Using the 2-hour retainer model from earlier, explain to your clients that you have increased the minimum number of hours needed to keep you on retainer and that they do have need of that work. If they agree then great, if not it gives you a reason to move on and find work that fits your needs.
Erik explains two rules of thumb when disengaging from a client. First, a great phrase that no one can argue with is “I can’t make a business case for this”. The other is that when disengaging to err on the side of generosity, give them a generous refund or allow them to keep a sample of your product.
Extracting yourself from an over scoped project is much more difficult especially if they have paid you a large sum upfront and you have put a lot of work into the project. The advice the panel gives is to go to your client as early as possible and explain that the project is going to take a lot more time and resources that you first thought and hopefully you will be able to work something out. If possible, before engaging in any project the panel advises you to determine the worst-case scenario and to work safeguards into the agreement.
Finally, the panel lists questions to ask yourself to determine the perfect projects for yourself. Do you want to hire subcontractors? Is there a time limit you want to work on one project for? What are your costs? What and how many hours do you want to work each day? How much communication do you want to have with clients? What do you want your business and life to look like? Once you answer these questions and set your boundaries the perfect scope of engagements will be easier to define.
- Erik Dietrich
- Jeremy Green
- Sentry– use the code “devchat” for two months free on Sentry’s small plan
- Adventures in DevOps
How do you know if a engagement is too small?
A too-small engagement may be too short in duration or not profitable enough.
How can walking through the numbers of an engagement help you?
Working your way backward through the numbers will help you decide how much you would actually have to make in order for a project to be worth your time.This exercise will also arm you with information that will help you from a negotiating perspective. It allows you to speak with authority about what you will and won’t do, giving you the power in the sales conversation and allowing your clients to see what they are really asking of you.
What is a red flag to be aware of when scoping an engagement?
Turn around time, if the turn around time is too desperate it is a sure sign that it is a bad situtaion.
What questions should you ask yourself when setting boundaries to find the perfect engagement scoper?
Do you want to hire subcontractors? Is there a time limit you want to work on one project for? What are your costs? What and how many hours do you want to work each day? How much communication do you want to have with clients? What do you want your business and life to look like?