This post is all about estimating costs for software development projects. It’s not always easy. That’s why many firms have a discovery, research and scope period before they will give you an idea how much a software development project will cost.

Why can it be tough?

There are a lot of variables with software. And until we understand all the nuances there are always issues that could pop up. For example, let’s say a client is developing an eCommerce site that sells flags. In conversation the client talked about how the purchasing process goes from selecting a flag, to entering an address, then to credit card information. For selecting flags, they mention that there is a list of flags they want on the site. Great. We would assume that the client has a list of flags that they would send us and we’ll add those to the flags table in the database, which will then be displayed on the flags page of the website.

But what if what the client really wanted was to pull the flag information from an external website using an API? Maybe they actually drop ship the flags using this third party service. As you can imagine, this is a big difference in how the flags will now be displayed on the website. Now instead of pulling information from our internal database it will make a call to a third party API to pull in the flag information. This is common but integrating with third party data is generally trickier because you have to understand how their API works. And there can be issues with connecting and integrating.

This change would usually increase the cost and scope of the eCommerce site.

This is why consulting firms typically spend a lot of time and charge a lot money just trying to understand what you want before they submit an estimate. And even then the estimate isn’t usually guaranteed. Most software development projects are done on a time and materials basis.

But, change can be OK.

Using Agile makes changes in the middle easier because every two weeks you achieve a new deliverable. It still takes time and money to make those changes. At the same time, life is about change and rarely do projects not have some changes in the middle. In today’s world, that’s inevitable. So it helps to keep your architecture open to changes, even radical ones.