Originally published on Codementor.io/blog on Published Sep 05, 2018 By Julia S.
A message drops in your Inbox.
Hi, it’s Mike from AdvoraCorp. I’m looking to build an app for my construction company to help manage our processes. I came across your profile and saw that you create enterprise Android apps. Currently, we’re moving to the cloud and looking at using technology to make our company run more smoothly. Can we have a chat over Skype soon? I have a considerable budget and lots of ideas.
Considerable budget, you say, Mike? Woohoo, payday!
Before you start plotting what you’re going to do with those mega-bucks you’ll get from AdvoraCorp, you need a solid plan for what questions you’re going to ask in that Skype session.
Important: Did you spot where you can tell Mike’s a non-tech person?
Hint: “Currently we’re moving to the cloud.”
What does that even mean? Their storage? They’re using O365 instead of on-premise Office? Mike obviously isn’t so sure, but he’s sure it’s a good thing.
In your first chat with a non-technical potential client, there are a
number of questions you should ask to see whether you’ll be able to have a successful working relationship and outcome.
I recommend following this list in order. The most important questions
are first. This is so if you get an answer that sets alarm bells ringing,
you can cut the chat short and go back to more fun ways to waste time
instead.
1. Do you have a concrete plan for the project?
Here’s the easiest way to tell whether you should pick up a project or
not.
If a client has a serious project that has a chance of being completed,
they will have a plan in place — often developed with the help of a
software consultant. This should be in addition to a business plan
for a commercial product or the internal systems it will
address/enhance.
Their plan should include:
- The overall goal of the project
- The intended audience
- Important features/modules, not just “sort of like X
website/app” - Approximate (achievable) timelines
- Approximate budget
- Understanding the importance of project management systems to help achieve timelines
- Who’s involved in milestone sign offs (just them or other stakeholders?)
- Potential screen mockups or user stories
Many “potential clients” won’t be able to answer all of these questions.
The main thing to note is that they have well-formed enough ideas on
all of these points to be able to draw up a contract that isn’t going
to leave you with a lousy deal (or them, or both of you even!). For
anyone that’s too vague here, and can’t further explain with prompting, you may need to let them down gently.
2. What are the most important features of your project to build an MVP?
Projects don’t always run to completion. The client runs out of money, loses interest in the project, decides it’s not necessary, or decides to go with a ready-made product instead. These things happen.
To ensure that your client isn’t left with nothing to show for a
partially-completed project, you can deliver their minimum viable
product. This is the bare-bones product with the minimum feature set that works. To do this, you’ll need to elicit the requirements to build the most basic version of their system — and use this as your first deliverable.
3. What is your timeline for deliverables?
Once you’ve got past the first hurdle, and the client has properly
fleshed out how their project should come together, you’ll need to look at deliverables.
The Agile approach is best suited to freelance software development, but that doesn’t mean that milestones can’t (or shouldn’t) be set. This will involve mapping out a full timeline with the client.
The first milestone (or deliverable) could be a working user interface or a bare bones product with just one feature. It could be a working Redis database that will dummy data that they can query or, more complex, it may instead be a prototype.
Each Agile sprint from thereonin will deliver a new feature (or
feature set to the client), with feedback between cycles. If you sit
down and plot these out in advance, it can ensure that timelines don’t
blow out.
4. Let’s talk money: Are we going by milestone or hourly?
Getting paid is the aim of this gig, so talking about how that’s going
to happen is essential. Clients may be keen to go with a milestone-based approach. Sure, that makes sense — they’re paying for what you’re delivering. This may not be an ideal choice as a dev, though.
Unless the project is fairly simple, you’ve done similar ones 1,000 times already, and you can accurately plot out how long each part is going to take, it’s difficult to accurately guess costs with a milestone-based approach.
Instead, you can encourage the client to put you on an hourly rate (and here’s how to determine your freelance rate). This is particularly important when using an Agile approach, as changes can arise.
You can point your clients towards this piece comparing
fixed cost, hourly, and retainer fee structures for development projects.
To alleviate their hesitation that you’ll be wasting time, or be slow/incompetent, you can show them an example of a component of your previous work and let them know what was involved and how long it took. If your client agrees to paying you hourly, using time-tracking tools with statistical analysis features to indicate what you have been working on and what, such as Toggl, can put prospective clients at ease.
5. Are you willing and able to learn specific project management/collaboration tools to ensure the process runs smoothly?
This question really goes both ways. As a freelancer, you’ll have worked with a multitude of project management tools with various clients. You’ll probably have your favorites, like JIRA. Clients, however, might use their own systems, such as Microsoft Project.
Some project management tools suit some projects better than others. For others, it’ll be an automated management stack, such as Basecamp + Jira + Slack.
Coming to a consensus on the project management stack is something you’ll need to work out with the client. While you might be an ace at a tool, they may have zero experience.
If you are certain the tool is essential for project management, then they’ll need to be able to pick it up. This means you should source training materials for them and/or walkthrough the system with them.
Often, picking a tool the client already has experience with (if it’s fit enough for purpose) and layering with your own systems is an easier route. Even if you have no experience with their tool, it’s generally trivial for you to pick up a new tech than it is for your non-tech client.
6. Are you willing to pay for additional components and ongoing costs that may be necessary?
With many projects, you can get away with using a variety of open source solutions and products that you’ve already purchased for development. However, this isn’t always the case.
Take, for example, if you’re tasked to build an add-on for proprietary software like Salesforce. The API will get you so far, but you’ll need access to the product itself for testing, which may require additional
license purchasing. This will need to be on the client’s dime, not yours.
Other open source solutions may charge for commercial usage. For instance, Java SE is moving to a paid subscription model as of next year, which businesses will need to use if they wish to receive critical updates. Qt may require a commercial license, unless your project follows the provisions of the LGPL.
You may also need to chat about storage, hosting, and runtime (for example, AWS products for the finished product. A non-technical client may not have considered these ongoing costs.
7. Do you have a technical consultant/advisor that you could call on if needed?
This is a great suggestion for a non-technical client. If a client has a technical consultant or advisor to call on, this person can help be a go-between if necessary.
This way, they can be assured of your proficiency and planning, without trying to figure it out themselves. This person might be called on if the client has any queries along the way that might be out of your realm of expertise — such as the best way to monetize an app.
Are you willing to do additional reading about the software development process? Suggest some articles/resources to them so they’ll get an idea of how things work
Screening non-tech clients is tough!
Trying to figure out whether a project will go smoothly with a non-tech client or end up in a steaming heap hangs on the first chat — if you know what to ask. Running through this list of questions can help see if it’s worth your time (and sanity) to get onboard the project.
Did we miss any questions to that freelance developers should ask non-technical clients? Let us know in the comments section below!
Are you an experienced developer looking for freelance work? Apply to join Codementor’s network of pre-vetted mentors and world-class developers.
