How I estimate a new project after three years of entrepreneurship

It's almost three years that I'm a full-time entrepreneur. It's not a lot, but I've done some errors, and learned a couple of tricks. Here's my process to understand a project's scope.

Giulio Michelon
Aug 23, 2017 · 4 min read

Human communication is awful. We don't understand each others, we tend to simplify everything and think that people will figure out details. My experience showed the very contrary. We don't listen too, and we are always in a hurry. All those problems undermine the quality of my work.

Therefore understanding specifications is very hard and tricky, and optimism — unfortunately — is an enemy in this phase.

Moreover everyone get nervous when it's time to talk about money, which is why this phase is crucial.

That's the actual Belka

My company is called Belka. In the first meeting we present ourself and explain how we can help in the project.

The meeting can happen via phone, Skype, Hangouts and it will be enough to understand very basic stuff only:

  1. Does the client have at least one person which will follow us during the project?
    This is very important and non-trivial. We had more than one project failed because the client didn't have the time to follow the project.
  2. Is the project's vision clear?
    If the vision is not clear the project is never done.
  3. What is the technology/expertise involved?
    Are we useful in this? Is a technology we know well and can we deliver a optimal result?
  4. Does the client have budget?

I don't expect to have anything more in this phase. Any precise estimate now is meaningless.

Usually customers won't reply to the first question, so we give an expenses span to them in order to understand if they can meet our rate.

This is a workshop we did with a Red Bull team. I know, it looks messy

Depending on how much the customer trust us we can go in two different directions:

  1. Best option: let's throw a workshop and understand what we are going to build
    This is the best jumpstart for a project. We can go deep into the topic and understand all the stakeholders involved, the target, and design a proper product.
    It's hard to accept for the customers, but very rewarding. All the project we started with this methodology ended well. It's our quality mark.
    Talking about workshops: w
    e are big fans of the Design Sprint. Here's some insights on our very first one.
  2. Let's meet each other for another meeting and go deep into the project
    This is riskier than the first option, but the customer doesn't always know what is best. Usually they are not design-savy people and they tend to cut corners in order to save money on the project.
    We try this road only if the project is really interesting, but we know that we will need to improvise a lot during the development and the estimate will be less accurate.

This phase will lead to better cost estimation.

E.G. if phase one can be "this project is between 15k and 25k" phase two is more like "this project is between 15k and 19k".

This is our given price, and we commit to finish the project in the given scope.

In order to estimate the entire project we map every single user story, which is a feature from the user's perspective, and we weight them starting from our previous experience and detecting when we have unknown parts.

We sum the expected time of each user story we add some time that will be used for meetings and paper work. This is where our estimate comes from.

Design phase: still messy

Next is the design phase, which can be tricky. Sometimes you discover new stuff (usually when you didn't throw a workshop), sometimes everything goes straight. We can still decide to change the product during this phase, and the development cost prevision accordingly.

Finally it's time to build the software. Easy-peasy!, except we can still decide to change it, because you can decide to proceed in different directions during the development. So how can we solve this?

We recently noticed that we can't bend the space-time, and software development is no exception.

All the previous steps are just a way to start a discussion and go deeper into the design phase, in order to forecast the path for the development.

We want to help the client to minimise those changes because those changes are expensive. Coding is time consuming. But still, sometimes, change is good, and you need to build the product with a moving target.

In order to do this we work in a agile scrum-ish methodology. This means that we can still change what we will build, but we need to be careful: adding features means more time, or removing other features.

This is tricky if you don't accept the immutability of space-time, but once it's understood by both parts you can easily change the track on-the-run and change the project budget as well.

Do you think that this is a valuable way to proceed? Is there something I'm missing here? I talked with a lot of companies and professionals to understand this and I'd like to know if you have some powerful tricks to make this process better.

Do you think that this modus operandi suits your needs? Let's discuss your next project together.

Life in Belka

We design and build digital products.