In this article, you will find about the staff augmentation model and how it can be helpful for your business. Also...
Software Cost Estimation – How to Estimate Development Projects?
In this article, you’ll learn about:
- We will tell what the main benefits of accurate cost estimation are
- 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 us understand what drives costs in a project. One benefit of that is that it’s easier to prioritize backlog tasks smartly and effectively, using the “Impact/Effort” analysis. (Which essentially looks like this:
- 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 beneficial for the client to decide if this is in line with their budget and afford it.
- 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 project elements, 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.
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 inaccuracy risk level (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.
We don’t typically include the resources needed to complete a project or its duration in a ballpark estimate. We go into that in our detailed proposal. We provide clients with 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.
1. We gather as much information from the client as possible. This might include a high-level idea for the product, its business goals, any details of the existing software architecture and infrastructure, wireframes and mockups, and user journeys – anything that will help our team understand the needs requirements for the project.
2. We get a team together, which depending on the scope of work we have to analyze, might consist of:
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 the team’s desired breakdown 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 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 and work in the team to clear any doubts 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 project’s time and costs – 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 our team’s knowledge and experience – they’re key to an accurate software project estimate.
In this post, we’ll take a close look at what to consider when companies look for an offshore software development...
This article focuses on explaining what a Software Development Roadmap is, its advantages, the high-level process of building one, and...