You won a contract and will soon begin working on a project as a Salesforce freelancer. Congratulations! I’ve been freelancing in the Salesforce ecosystem for more than eight years and the joy of winning a new project never gets old. You start imagining how the org will look. You hope that the custom field descriptions are not empty and that the business processes are well-documented. If you are a developer, you pray that they use SFDX + Git and that the code is properly commented and documented.
That’s the ideal world. Unfortunately, more often than not, you realize it’s not the case. You see, when someone hires you as a Salesforce freelancer, it’s usually because things are not going as planned and they are looking for a specialist to jump in and get to grips with things fast! You’ll be lucky if your predecessors left any details about what they did and where (and why) they stopped.
Having been through more than 20 projects, I have developed a few tactics on how to deal with these situations. In this article, I’ll share my learnings and experiences on how I have run and participated in projects as a Salesforce freelancer. It doesn’t matter if you enter at the beginning, middle, or end phase of a project, if you know which questions to ask, you’ll be fine!
Do Your Research
I always do my homework before starting a new project. The first thing you need to do is learn which industry the client is in and exactly what they do. Next, learn about the project scope, what they are planning to do in the future, and what is expected of you. Ideally, you will have already developed an idea at a high level either before or during the interview phase.
Now it’s time to dig deeper and truly understand the use case. Ask yourself (and the client) the following questions:
- What exactly are they trying to build?
- Why are they doing this?
- Has anything already been built? If so, has it been tested or released?
- Can some requirements be solved via an app available on the AppExchange?
You’ll need answers to these questions as soon as possible.
You will most likely be working either with one or a combination of sales, service, and marketing teams. During this phase I interview the heads of different departments to understand their vision for their respective teams. I also try to interview the CEO, or someone from the C-level team, to understand the bigger picture and overall vision.
This gives you a jump start on the project. Now you know what everyone is aiming for, you can see clearly if the organization is aligned or if there is a disconnect.
When starting a new project, it’s important to gain the trust of the client as soon as possible. This exercise is a great way to start building that relationship.
Planning the Project
“A goal without a plan is just a wish!” – Antoine de Saint-Exupéry, writer
Once you know the end goal of your engagement, it is time to make a plan for how to reach that goal. By this time, you should have gained a good insight into what needs to be done. You might not have the technical tasks outlined in detail, but you should be able to prepare a list of actions.
Depending on the situation, you might be working alone or in a team. During this phase, we decide who is going to do what – most importantly, who is going to test, and who will have the final say in case of a deadlock.
Pro tip: Ask your client to help you identify the ‘power users’. These are the users who work on Salesforce every day – they are passionate about the tool and their job. They want to be the best at what they do, so they will tell you exactly what they need. They can also be the people who do the User Acceptance Testing for you.
By the end of this phase, you should have a clear set of milestones, understand who is responsible for what, and have a team structure clearly defined.
If you take away one thing from this article, it should be this: Learn the art of asking the right questions and do not be shy about asking a lot of them! In my experience, the more (logical) questions you ask, the more clarity you get. Gathering and jotting down the requirements in the correct way will save you from disputes (and headaches!) further down the line.
Depending on your profile, you might have technical tasks to complete, or your job might include converting the business requirements into technical tasks. Either way, it’s always helpful to write down everything in detail. Use Gherkin or a similar business language to create the ticket.
For example, I try to break down each task into: Given, When, and Then.
You can also use the same principle to document each step in your flow, sub-flow, and business process.
Every seasoned professional understands that you don’t always know the answer to every problem, and sometimes you face problems which take longer than expected.
Even after being in the ecosystem for ten years and having delivered more than 20 projects, I can attest to the fact that there will be inevitable delays. A smart professional accepts this and plans for it in advance.
Let’s say I need four days to deliver a feature, I will add either a half day or a full day to the estimate. I also inform my client in advance that I have planned for delays so it may or may not take that long.
In my experience, I do not face a major obstruction on eight out of ten occasions. This helps me deliver my tasks before the deadline and I build more credibility with my client, which becomes even more important when I do face a problem and it takes longer than the time that I planned for.
This is where most of the freelancing horror stories become true and people give up on freelancing altogether. In my course, I go much more into detail around how you can safeguard yourself against such situations.
Continuing with the example above, if I hit a major obstacle and cannot deliver the feature even after five days, the client is likely to be more sympathetic.
There will always be situations that you can’t plan for that will cause delays, for example, you or a family member getting sick. In my experience, it always helps to increase your original estimated effort by 10-20% before sharing it with the client.
Depending on the situation, you might be working in sprints or time and material deliverables. It is very important to keep your client updated on the progress of your work.
If you participate in the sprints, then you will probably be part of regular update meetings and won’t need to make any extra effort. However, if you are working on a big feature all on your own, it is advisable to have at least one weekly meeting – two meetings might be better!
Additionally, it’s also advisable to send a weekly progress report each Friday detailing everything you did during that week.
Example: Three years ago, I worked for a client on a small AppExchange app. I was the only person working on it, but I was working with their IT team because the app had to exchange information with their backend systems. During this project I took part in standup meetings on alternate days and also sent a weekly report.
If you face a roadblock during this phase and you realize that it is going to take some time to resolve, flag it and inform your client as soon as possible. Hopefully, you have already planned for situations like this, so there is no need to panic (from a time and budget perspective).
When you hit a major roadblock, you need to send an email or create a report addressing the following points:
- What is the issue you are facing?
- What caused it?
- Provide a detailed list of things you have tried so far. What were the respective outcomes?
- What are the next steps?
- If required, contact the Salesforce support team or post a question on the Salesforce StackExchange.
Finishing a Project
You’ve reached the sweet end of your project, so how do you wrap things up?
Firstly, ensure everything is neatly documented. Write with the mindset that the reader has no idea about the org and this is the first time they are reading about it. This can be in the ticketing system that your client is using. It goes without saying that you need to close all the tickets.
If you wrote some code, ensure that each file has a header describing what the class is doing and that each method also has a description block at the beginning. I use this VSCode plug-in for the same. Use ApexDoc to generate code documentation.
A few weeks before the final day of your project, you should start working on a handover document. If you completed all of the steps above, simply create a doc summarizing the project requirements and mention (in bullet points) what you did – include links to all of the tickets and documentation you delivered.
You can later use these handover documents to create marketing materials.
Ideally, you should have your next project lined up either with the same client or with a different one. You should start discussing an extension or your next project 4-6 weeks before the last date of your current project.
If, however, you are not getting an extension, you should start looking for external clients and opportunities. Running a successful Salesforce freelancing business means having a pipeline of projects. For this, you need to do some marketing, create a brand, and have a presence on social media (LinkedIn and Twitter in particular).