How to Estimate the Cost of Software Development

We spoke with our CEO Simone Zinanni about how to choose a partner company for software and hardware development. Now that we have made this choice, we have reached the fateful moment of the quote.

It is quite difficult to estimate 100% of the cost of developing custom software just by taking a look at the client’s requirements; each project is unique and requires an individual approach.

Today we talk about it with Fabrizio Venere, Project Manager at Develer.

Fabrizio, let’s start from the beginning: what factors can influence the overall cost of a software development project?

That’s a good question: it’s not easy to answer; there are many factors to consider! First of all, there are two scenarios to consider.

The first: our team starts working on an ongoing project, so we need to do “refinement,” review what has been done, or add features to an existing project/product. This, in my opinion, carries a certain level of complexity.

Second scenario: the client comes to us and asks to create a product from scratch; so there are ideas, but nothing already existing or realized.

This second case is definitely more challenging, longer in time, and you need to understand the actual requirements, however, it’s easier to estimate since we have a project and complete freedom to shape it as we wish.

When, as in the first case, there is already an existing foundation, the situation is more complex because you have to integrate within an already established ecosystem.

You need to understand how to interface with this substratum – which isn’t necessarily immediately apparent – but most importantly, there’s the significant difficulty of having to build something while being dependent on what has already been done in the past.

So, we’re dealing with two very different levels of complexity

And then, of course, we have to talk about the internal resources that will carry out the project…

Regarding resources we face a great amount of variability: generally, we base ourselves on what may initially seem like the inherent complexity of the project, but also on the budget of the client and our current internal availability.

Usually, we need at least three people – a number that goes up depending on the difficulty or timeframe of the project itself – who can work in parallel and do code reviews for each other, avoiding a “one-man show”.

So a team of at least three developers?

Yes. How this team is structured depends on the situation because the project’s complexity may require everyone to be senior-level. Or perhaps just one senior is enough to have a technical leader, along with two more junior team members.

As you can see, many factors contribute to the overall cost. 

But the most essential thing is to try to understand what the client wants from the beginning.

And how do you understand what the client wants?

There isn’t a single rule. We have been experimenting with doing initial iterations with the client at the design thinking level.

The client has an idea that is often just that; we have a team that tries to ‘put on paper’ the things the client has in mind, translating them into wireframes and mockups.

For example, if we’re talking about the GUI of an industrial machine, we conduct collaborative design sessions where the client can already visualize drafts of the screens.

This way, we already start to understand how the graphical interface should be structured. And this is just the surface because, behind it, there’s a whole world with which those graphical interfaces will need to communicate.

This preliminary work allows us to create prototypes of graphical interfaces, including the user experience aspect. This gives us an idea of the effort required for their realization.

Next, we need to understand how these interfaces will communicate with the underlying world. This involves considering technological factors: what constraints do we have? Is it possible to use one language rather than another? What level of seniority is needed to create that product with those specific technologies?

This is the preliminary phase – about a month – during which we try to understand clearly what the client wants.

And do we do this regardless, before taking on the project, to provide a quote?

Yes, we get the requirements. We usually offer the client a day of design thinking workshop, led by Matteo Forni: using the tools provided by Matteo’s approach, we begin to sketch out various workflows.

Often, the client realizes the potential of this approach, so we carry on with this initial part of creative design, whose final goal is to prepare all the interfaces, or at least the “higher value” prototypes.

Clients often remain enthusiastic because they realize how many things – they hadn’t thought of – can actually be part of the final product, or perhaps how many things they had thought of are not very useful, not very functional, or can be done differently.

This approach has a dual purpose: it allows us to align the customer with our way of working and it also enables us to understand the potential effort required for a project.

What happens at the end of this activity? 

What happens is that the technical leader, with the help of the designer’s feedback, manages to give a fairly realistic estimate.

For example, he says: “In order to approach this work we would need at least two months of work and a team of three people”.

By ‘two months of work,’ he does not mean that the product will be ready and packaged at the end of the second month. No. It starts a process where work begins iteratively and agilely, focusing first on creating the most valuable elements.

What does the tech leader base this estimate on? 

Certainly based on their technical insight.

That estimate means: I am reasonably confident that at the end of that amount of hours, the most valuable things will be delivered. Then, at that point, the client starts with their testing and realizes that certain things may be revised or improved, or that some may not be useful. So there are additional reworks, which involve refining previously completed tasks, addressing lower-value tasks that remain, bug fixing, and especially incorporating the client’s feedback.

So, there isn’t an estimate with a precise number, but an indication to make the client understand that from that point they have an MVP (minimum viable product), i.e. a product that includes most of the key functionalities.

Although not ‘ready to market’, this MVP is something that is already working, allowing the customer to work on it to see what improvements can be made.

So, to summarise, what affects the cost?

It certainly makes a big difference whether the project is new or if we need to integrate into something that already exists. In the latter case, factors such as integration with other systems and data migration need to be assessed.

Then, of course, there’s creative design and the resources used in the project: how many are needed and how skilled they are.

And then the type of contracts has a big influence. How many and what types of contract can we have?

Usually, in the software world, there are three types of contracts that can be applied:

– The Fixed Price approach

– The Time&Materials approach

– The Float Scope Fixed Budget approach

The Fixed Price approach is the riskier one for customer and supplier. Generally the client must come, if they want a quote, with a technical specification which is usually a hefty file of an excessive number of pages, containing all possible details, implementations, and variations of a particular functionality down to the comma.

We base our estimate on that, but it is something that is no longer commonly used or is used much less because it is risky; the terms can change over time, and it’s not possible to foresee changes or manage them, or conduct risk management.

It’s an approach that can make sense for very small projects where the scope is clear to both the client and the supplier, and we know we won’t deviate from it.

In the Time & Materials contract, the client pays compensation based on the time spent and the amount of material used. The cost agreed upon between the client and supplier is reported periodically, using an agile approach to project management, meaning it is not fixed and static like the above technical specification, but instead is oriented toward speed, flexibility, and adaptability to client requests. Therefore, there is no predetermined total amount in the T&M contract, making it the riskiest contract for the client because the risk is entirely on them.

An evolution of this type of contract, which we prefer to use here at Develer, is the fixed budget contract with variable features. In this case, we agree on a budget for the work through our pre-project consultancy activities, with the estimation techniques explained earlier. The features are variable and are determined according to the client’s business priorities. We work immediately to deliver the most value by working in an agile manner: the goal is to release a “core” piece of code every week or every two weeks, allowing the client to test it immediately and provide feedback.

The strength of this contractual model lies in the fact that it allows changes to be made according to what the developers learn during the realisation of the product. However, it establishes a real constraint on the project in terms of time and cost. The project risk is mutually shared between the customer and the supplier.

It’s a cap, essentially a time & materials model with a maximum limit not to be exceeded.

We recommend it for elasticity, transparency and shared management of opportunities because in a fixed-price project, you cannot think about changes. Whereas in a float scope approach, change can be managed at any time.

As a project manager, what best practices would you recommend for estimating the cost of software?

First of all, as mentioned earlier, I would definitely recommend preliminary collaborative design sessions. To these, I would also add meetings with the technical leaders.

In general, the advice is to involve all stakeholders, especially when working with medium-to-large companies, because it is necessary to understand the needs and expectations of everyone.

So don’t just talk to business people, but also include the product owner, marketing, sales, and especially the technical team, because often discussions are held with everyone while leaving out those who will actually develop the product.

And if developers are not involved, you can sometimes end up with requests that are either difficult to realize or impossible to complete within the agreed hours.

All clear so far. But does it happen that a customer, after all this explanation, still wants to know the price?

Absolutely, yes.

We tell them that we cannot provide a precise price for delivering the finished product. We can only provide the price for a portion of the final product because there will be many aspects that will come up during the work.

There are times when we lose the customer because of this, but therein lies Develer’s fairness, honesty, and transparency.

Tough question: Isn’t it that we don’t apply a fixed cost because we’re not good at making estimates?

Haha! We do make estimates, and with the experience we have – as we can see from our satisfied clients – our estimates are accurate, and we respect timeframes and costs.

As I said, it’s a matter of transparency. We don’t offer fixed-cost pricing because the subject matter is variable; there’s always a delta that exists regardless of ability, because along the way, there are external variables, like a browser changing versions.

By nature, the subject matter requires a flexible approach; a rigid one cannot be used because we’re talking about digital products.

To be as transparent as possible, we always involve the client in our iterative activities. So, when we plan the work for the week in the sprint, the client knows very well that we divide a feature into many sub-tasks on our Trello board, and since we’re working at a lower level of granularity, we estimate those tasks.

We generally use story points: for example, one of our story points equals half a day’s work for a developer. So, in the end, by doing the algebraic sum, we can determine that operation X will take two and a half days of a developer’s work.

That level of granularity is transparent, so the client knows how long it takes to complete that small task. We can’t have the same level of detail for all functionalities because it would take months just to identify them, understand their implications, and estimate them.

It’s the nature of the digital product that determines the way we work.

The problem is making it clear to someone who has always dealt, for example, with a mechanical product, where you make the machine and that’s it. On one hand, you can relax because you know the product is finished and doesn’t need much updating or maintenance, while the digital product is ‘never finished.’ On the other hand, however, it has the advantage of being scalable, modifiable, and versionable at will. These new opportunities for the product need to be approached with methods different from the traditional ones.