Software Cost Estimation – How We Do IT

An accurate cost estimate is the key to a successful software development project. This may sound a bit cliché – but we’re serious about this here. After all, it’s money and software we’re talking about. Let me walk you through how we approach the software cost estimation process at Asper Brothers and share some (hopefully useful) tips that have helped us nail it down. 

In this article you’ll learn about:

  • We will tell what are the main benefits of an accurate cost estimation
  • You will know several types of cost estimation in software project management
  • What do we need to focus on in our ballpark estimates for software projects?
  • How we approach the estimation process step by step 
  • Useful tips you should know to avoid overshooting costs and time in estimates 
  • We will introduce you some useful tools which can help to create cost estimates

 

So, why is creating an accurate cost estimate important, again?

There are plenty of reasons, but let’s focus on a selected few:

  •  It helps you define your team’s effort that you’ll have to put into the project and the exact scope of work. This, in turn, will help you come up with an adequate price you’ll present to the client. (And I don’t think I have to tell you what undercharging means for you and your company.)
  • It helps understand what drives costs in a project. One benefit of that is that it’s easier to prioritize backlog tasks in a smart and effective way, using the “Impact/Effort” analysis. (Which essentially looks like this:

impact-effort

  •  It provides clarity to both the team and your client, helping define and agree on milestones.

 

Estimates are not made equal 

There are several types of cost estimations in software project management.

  • A ballpark estimate usually presents a range of costs the project might fall into. It’s especially useful for the client to be able to decide if this is in line with their budget and if they can afford it at all.
  • A budget estimate is a more detailed cost breakdown for a project, usually including a general project plan.
  • A definite statement of work (SoW) estimate outlines all the elements of the project along with their cost and a contingency plan.

At Asper Brothers, we use ballpark estimates providing a high-level overview of the project costs. We break the project down into phases, starting with the „Discovery/Analysis/Design/Scoping” phase. Only then do we prepare a much more accurate – and detailed – final budget with our client.

There are several popular cost estimation techniques, but we prefer to mix some of their elements into our own individual approach.

Let’s dive in a little deeper into how we actually do it.

DSC00305

What does a ballpark estimate include?

In our ballpark estimates for software projects, we focus on these elements: 

  • Costs and jobs grouped into categories. In other words, what jobs need to be done, and the costs they might involve.
  • Estimated timelines created in three different scenarios: optimistic, realistic, and pessimistic.
  • The level of inaccuracy risk (more on what it is and how we do it a little later).
  • Optionally – the level of complexity of a project.
  • We might include third-party costs if relevant.

In a ballpark estimate, we don’t typically include the resources needed to complete a project or its duration. We go into that in our detailed proposal. What we do provide clients with are detailed comments explaining how costs work in a project – to make sure we’re all on the same page and there are no misunderstandings at any stage of the project.

 

How we approach the estimation process (and how you can, too) 

Let’s look at the whole process of project analysis and estimations at Asper Brothers – from the moment we get an RFP, to the kick-off of the first development sprint. 

Estimation-session

1. We gather as much information from the client as possible. This might include a high-level idea for the product, the company’s business goals, any details of the existing software architecture and infrastructure, wireframes and mockups, user journeys – anything that will help our team understand the needs and requirements for the project.

2. We get a team together, which depending on the scope of work we have to analyze, might consist of:

  • Our CTO
  • A backend developer
  • A frontend developer
  • Optionally: A UX/UI designer

The team members look at all the project materials on their own. Then, we host a quick meeting to exchange questions and doubts and make sure everyone’s on the same page.

If we have questions or concerns, we create a shared file and send it to the client or product owner. When we have the answers, we usually meet again to discuss them and hop on a call with the client. We define the scope of the project and collect all of the requirements.

3. We create a high-level architecture and infrastructure design and describe the tech stack we’ll use. 

We define a desired breakdown of the team and create a high-level agile timetable of things we need to do before the first development sprint. Then we break down the scope of work into detailed elements.

4. We meet for an estimation session to estimate the time needed for each of the elements. Estimations can be tricky, so even after we’ve completed all the points above, we might still have some questions and doubts at this stage. If we do, we leave those elements blank and move on. Then we get in touch with the client to clarify them.

 This is an important refinement session leading to a more accurate estimate. 

5. There’s a lot of uncertainty in the process of software development and discussions during the estimation process can get heated. So we define an Inaccuracy Risk Level score for each element. The score can be low, average, high, of very high.

Low risk means the estimates are almost certainly accurate. A high or very high score means that there’s a chance we’ll exceed the estimates and we can’t specify by how much. (Since it’s a “risk”, this might not happen in the end, but we want to be prepared ahead of time.)

6. As soon as we complete estimating all of the elements, the team goes through the estimates one more time and refines them. After reviewing our proposal, estimate, requirements, and risks with the client, we make final adjustments.

7. We make sure the backlog in Jira is up to date with what we finally agreed on. We develop user stories and host a backlog refinement session.

8. The ballpark estimate is based on hours. Apart from it, we host a Scrum Poker session during which the development team awards story points to each user story.

9. Finally, we can kick off the first development sprint.

A few tips to avoid overshooting costs and time in estimates 

Overshooting (and undershooting) is really easy in the estimation process. And it can either cost you a client or lower your profits (and get people frustrated).

So, if you don’t want to miss the mark, here are a few of the strategies we use – and recommend – to make sure we stay on track. 

  • Make the most of the learning and discovery phase. Ask the client as many questions as possible, work in the team to clear any doubts as possible, as early on as possible.
  • Pick the right people. It seems pretty obvious, but in reality, it not always is. The people who estimate the project should be the people who actually do the work. They’ll be able to use their previous experience and see any red flags that might come up.
  • Use historical data from previous projects. Keep detailed records of the time spent on each aspect of your projects. That data will be super helpful later on to create realistic estimates.
  • Break down the work into smaller chunks. And place them on sticky notes. The smaller the task, the better you can estimate how long it’s going to take. This has really improved the accuracy of our estimates at Asper Brothers.
  • Then analyze them in detail. If there’s nobody on the project analysis team that knows the task you need to estimate really well, talk to other people in your company or external consultants.
  • Score each task with a complexity point and inaccuracy risk level. Talk to the client about ways to decrease the complexity and inaccuracy. Maybe you need to spend more time on research and discovery or create a proof of concept to verify your assumptions.
  • Reduce bottlenecks. When planning and doing the work, try to cut back on the dependencies between people and make sure there are no bottlenecks that typically increase the time and costs of the project – and which more often than not can be avoided.

 

Some useful cost estimation tools 

There’s a bunch of online tools you can use to create cost estimates. We like to keep things simple, so we usually use: 

–       A shared Google folder with all of the materials

–       A shared ballpark estimate template file

–       A dedicated Slack channel

–       Scrum Poker Apps 

Most importantly, we rely on the knowledge and experience of our team – they’re key to an accurate software project estimate.

Call to action

There’s plenty of different cost estimation techniques companies use – has any of them been particularly useful for you? Or do you have your own approach, as we do? Drop us a comment!  

Share

SUBSCRIBE our NEWSLETTER

Are you interested in news from the world of software development? Subscribe to our newsletter and receive a list of the most interesting information once a week.