You ask business people questions but you do it without respect
Tags: productivity, beginners, agile
Published: 2019-07-03 09:25:57

---
title: You ask business people questions but you do it without respect
published: true
description: When you start a freelance developer career, the first big project is a game changer. Big projects bring more money and, inevitably, more problems. How not to frack up by having a miscommunication?
cover_image: https://ucarecdn.com/7469e1d1-f685-4a4c-b796-f5058d7ee14e/-/scale_crop/1000x420/godfather.jpg
tags: productivity, beginners, agile
canonical_url: https://medium.com/@rsedykh/evaluating-incoming-projects-5c73f59e05c6
---

Ok, the more accurate title would be *"How to communicate with business people about their projects if you're a freelance developer"*, but I couldn't resist. :-)

When you start a freelance developer career, the first big project is a game changer. Big projects bring more money and, inevitably, **more problems**. How not to frack up by having a miscommunication?

It takes years to see things for what they are. Until then you'll have troubles with understanding clients' needs, underestimate tasks, and miss deadlines, trust, and money. It's part of the process, but you can accelerate learning by communicating your understanding of incoming projects better.

I compiled a checklist backed with my experience of evaluating more than a hundred web and mobile projects (from a week-long to five years in development).

***

Step 1, **preparation**.

Should you even consider taking the project? Will the client agree on your terms? For that, you should answer these questions:
1. Can I do it?
2. How much time do I need?
3. How much **must** I charge to be able to complete the project if something goes wrong (it always does)?

At this step, you probably can't spend much time gathering info, but you definitely can have a call with a potential client. What should you do?

Before a call, prepare: read all docs (if they exist), learn about a few similar projects.

Then, follow the algorithm:
1. Ask about the project's goal.
2. Ask about edge cases, question why the client sees thing this way, what are the reasons.
3. Ask any questions you have left from reading original docs.
4. Tell the client your vision of a project, carefully listen to their response.
5. Try to find underlying potential problems with tech/design/business.
6. Update your project vision, agree on it with the client. That will be the project you will evaluate.
7. Discuss which major parts of website/app/service you should thoroughly estimate first, leaving everything else behind for a while. (Always start with a key part of the project).

After you finished a call, immediately write everything down. Then, if you can wait till the next day — just wait, let things settle down. You'll have a more unobstructed view, and a client might send you some additional info.

_Still, want to land this deal?_

Step 2, **evaluation**.

Write a response with your estimates following this template:
1. Write the project description.
2. Write the project goals.
3. Write about why you like it.
4. Write about project features. Mention underlying potential problems.
5. Create a mind map with the project's structure that an average person can understand.
6. If you have enough time, work on basic user stories (see this [cheatsheet](https://medium.com/@rsedykh/example-canned-user-stories-and-tasks-717c73bc4046)).
7. Write how you think you will build it, what are the major milestones, what’s your release strategy.
8. Write about resources you will need to accomplish a task.
9. Write time/budget estimate, based on tasks and/or resources. Don’t oversimplify things, but don't go pessimistic either.

A density of this response depends on how much you like/need the project.

If it's possible, always present your response on a video call or in person.

***

A few iterations later, you landed yourself a big project that you and your client are confident in and which can become a big step for your professional skills and career.