It’s almost three years that Belka is running as a company. It’s not a lot, but we’ve done some errors, and learned a couple of tricks. Here’s our process to understand a project’s scope.
Human communication is awful. We don’t understand each other, we tend to simplify everything and think that people will figure out details. Our 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 gets nervous when it’s time to talk about money, which is why this phase is crucial.
1. Hello this is Belka, nice to meet you 👋
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:
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.
Is the project’s vision clear? If the vision is not clear the project is never done.
What is the technology/expertise involved? Are we useful in this? Is it a technology we know well? Can we deliver an optimal result?
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 last question, so we give an expenses span to them in order to understand if they can meet our rate.
2. Let’s throw a workshop
Depending on how much the customer trust us, we can go in two different directions:
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: we are big fans of the Design Sprint. Here’s some insights on our very first one.
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.
3. Designers will design
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.
4. We can’t bend the space-time
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.