Small agencies screw up the most at defining a project scope. Heck, even big agencies still make the same mistakes (maybe on purpose to close the sale). It’s always the engineers who suffer the most. What you need is write a good Scope of Work (SOW) document. SOW is used to add definition to the project and align on what needs to be done. Do not start a project without first agreeing on the scope, do not ever put clients results guarantees into the document.

I define scope of work in three parts:

  1. Define meaning of “work”.

  2. Define the outcomes.

  3. Define a timeline.

First part of a SOW is to agree on the definition of “work”.

Got too many unknowns? The work should be defined as “untangling the mess and figuring out what exactly we can do”. Not sure if what client wants is achievable? Treat the goals as a hypothesis - “given x input & y approach, we believe we can get z output”.

When you work with less technical clients, it’s always tempting to start the conversation with technical solutions. Truthfully, a technical solution is usually not the best way to start a project.

Machine Learning (ML) projects especially sensitive to bad scoping. Here is a guide on how to approach project scoping step by step created by Santiago on X. I’m going to include the whole text here with some small modifications, but the general advice here is applicable to software engineering projects too, so I recommend you to read on regardless.

Follow these three steps:

Step 1 - Start with simple rules

You should start most problems by writing simple rules. It may not be perfect, but it’s a better process than jumping straight into complex solutions. Learn as much about the problem client want you to solve as possible. Get a baseline to compare against the bigger solution in the future.

For example, imagine you are building an online shopping store. You want to show your users a list of recommended products. Instead of thinking about machine learning, start with a fixed list of recommendations. You can upgrade that to a list sorted by popularity. You can solve this problem in many ways before training a model.

Step 2 - Replace simple rules with simple models

There’s a point where you don’t want to keep adding complexity to your rules. Maintaining a simple machine-learning model is easier than a codebase of complex rules.

People usually recommend starting with simple algorithms like linear regression or decision trees. This makes sense, but simplicity doesn’t always refer to the algorithm but how easy it is to use.

For example, instead of jumping straight to setting up a complicated bare metal kubernetes cluster to scale your application, you can use managed PaaS service like Amazon EKS.

Step 3 - Increase complexity

There’s a point where your simple solution can’t give you better performance anymore. Here is when you should start exploring more complex solutions. Sometimes, a better model can improve your results. Sometimes, you need many models or combine them with manual rules.

For example: instead of NextJS boilerplate, start thinking about custom builds. Instead of Postgres string search, use specialized third-party like Elasticsearch.

For step #2 and #3, checkout the rest of the 500K Agency Playbook

or download the » FREE SOW template «.