The Ultimate Guide to Software Project Estimation

Software Project Estimation. Three words guaranteed to make anyone in software development shift uncomfortably in their seat. Until now.

Over the past 10 years, our team has planned hundreds of development projects. As you’d expect, we’ve gotten better and better at it!

Estimating is, by definition, a guess about the future. The fact is that the majority of software projects aren’t delivered on time, run over budget, and end up with fewer features than originally planned. It’s safe to say that, as an industry, we’re not all that good at software project estimations, so it’s understandable to be unsure about the process.

Yet there is no getting around the need for robust and accurate software project estimation because, ultimately, clients need to be confident they can fund a project before they commit to it.

Estimating software projects poorly has many other side effects:

• Depending on the contract in place, clients may have to pay more than they had budgeted.
• The product itself may suffer, as corners get cut trying to deliver within unrealistic time and budget constraints.
• The development team’s morale can be negatively affected, as they suffer from the stress and pressure of trying to meet unrealistic expectations.
• A project may never be completed if funding runs out.

Over the past 10 years, my team and I have planned hundreds of development projects. In the process, we developed a methodology that has worked well and so, we created a template to guide others through the most essential parts of software estimations and project planning. To get started, head over to the Example Estimate Template, make a copy of the spreadsheet and customize it with your project requirements.

Why Are Software Estimates So Hard?

Until around 2011 or so, the majority of development teams used the Waterfall methodology to plan projects. Waterfall requires all the specifications of a software project to be defined upfront, which is very helpful to the estimation process. But now, everyone is going Agile (Kanban, Scrum, etc). Products are shaped through ongoing stakeholder conversations, and what is delivered may not exactly resemble the initial concept. MVPs (Minimum Viable Products) are released quickly, feedback is obtained and improvements are made iteratively. While Agile has proved its value as a development framework, it has complicated things from a planning perspective.

So the question we wanted to answer was: “How can we accurately estimate within a framework that thrives on continuous unplanned change?”

Our Approach to Software Estimates

Our solution advocates what Buddhists might call the ‘Middle Way’. You see, we’re not convinced that the Agile vs Waterfall dichotomy – that pervades the industry – is helpful. Things are rarely black and white in the real world. That doesn’t mean we’re rejecting either approach, the opposite, in fact, we’re cherry-picking the best aspects from each. Agility is absolutely a good thing, it delivers the best products for our clients. But that doesn’t mean that planning has nothing to offer. A healthy sprinkling of planning helps provide more accurate estimates when needed. Our approach provides the best of both worlds, and it makes everybody feel more Zen.

Who Should Do a Software Estimate?

That’s a great question. The reason many people worry about the software project estimation process is that it requires a broad set of skills. From design and development through to strategy.

The need for estimates is present throughout the entire development process, from top-level project planning to version release planning to task planning. These all require estimates to be done.

In an ideal world, the person doing the estimate for a project should be someone who has built software and done estimates before. Estimating a software project is itself a valuable skill. The more you do it the better you get. Because every estimate is shaped by the estimator’s personal heuristics and past experiences, the ideal person is someone who has also worked on a similar project.

Now, not every project will have someone who fits that mold. And that’s fine. We believe that with a little help (for example, from our tools and guides) anyone can take on the role of a product owner and create a solid set of requirements and an estimate. It will take some time, research and maybe some help, but it is achievable.

Project Estimation and Team Planning

Now let’s get into the nitty-gritty. Our estimator template covers two principles aspects:

1. Identify the team needed to deliver your project.
2. Estimate the monthly and/or total cost for your software project.

I’ve already mentioned how estimating is akin to predicting the future. The more information you consider, the better your model of the future will be. In other words, if you skip the requirements phase your estimate will have a lot of uncertainty.  When I am asked to give an estimate on a project without proper requirements, I often refer to this as a “ballpark” or a “guess” because my margin of error will be very high.  The more refined the requirements are, and the more thought and work are put into the estimate, the lower the margin of error on the estimate.

The first real step in a project is often the creation of a Product Requirements Document (or PRD). If this is the first time you’ve heard of a PRD, then I strongly suggest that you read our in-depth guide on PRDs before continuing on with this. It’s by far our most popular blog post and has helped hundreds of product owners define their requirements.

For everyone else, let’s take a quick refresher course. A PRD should answer questions like:

• What is the purpose of this project (AKA goals)?
• Who will use your product and how (AKA audience and user personas)?
• What features will your product have (AKA user stories and functionality requirements)?

Once you’re happy with your team and estimate, we can help you craft a great job description and attract the right talent to your project. Finally, as both apps are plugged directly into our network of hand-picked freelancers, it’s very easy to see what talent is available for your project, in case you get curious.

The time you spend on software project estimation will depend on the specific goals and requirements of your project. Some projects will require a Waterfall-style task-level breakdown before work can start, while others will skew towards the Agile end of the spectrum and will only need to use the team planning part of the tool (not the task breakdown).

We’ve designed the template to be flexible enough to help with all types of projects, budgets, and development approaches. To best demonstrate how this works, I’ve picked some common use cases. Let’s start with a simple use case, followed by a more robust example.

Use Case 1: Staff Augmentation

Your client is midway through building an application and they’ve decided they want to augment the project team by adding a Designer (part-time) and Senior Developer (full-time). The client has set aside a budget of $15k USD/month.

Requirements

The requirements stage for a staff augmentation contract is often straightforward. In this case, we’ll assume the client has already defined the skills, hours and rates they require. With that information to hand, head over to the Estimator Template, make a copy of the spreadsheet and customize it with your project requirements.

Project Description

In this section, you need to input the expected duration of your staff augmentation contract. You can enter this as a whole or decimal of a month. In this example, my project is a rolling 1-month contract. This section also includes an optional project description field.

Team Details

This is where you build out your team. Once you’ve included every team member and their role, you can input the desired hours you have agreed on with your client. For example, let’s say I need to hire for a Senior Developer role, and the agreed hourly rate is $50.00 USD.

As a side note, If you’re looking for a remote developer to fill the role, we can help you hire great tech talent. Once you fill out some details about your project, our team will contact you to discuss.

I also need a Designer for this example, so I’ll repeat the above process for that role.

Once I’m done, the Estimated Monthly Cost is calculated at the bottom. At close to $17,392, it’s slightly above the client’s budget. I have a few options though, I can chat with the client and explain they will need to up the budget to secure the right candidates. I could try to get lower rates (by negotiating with the contractors or finding cheaper ones, though cheaper sometimes means less productive) or I can reduce the hours/day for one or both of the team members.

As this is a Staff Augmentation project, you don’t need to fill out the Tasks section. So that’s it, you’re done!

But what if you’re starting a new project, or want a more detailed estimate for a new initiative?

Don’t worry, we got you.

Use Case 2: Project-Based, with Defined Requirements

Let’s use the example of building a ToDo app featured in our How to Write an Effective Product Requirements Document article, which utilizes our PRD template. For this case, we’ll look at how to use the estimator to provide a quote on a project with a fixed end date, working from a completed PRD document we created internally.

Before digging into how to use the template for this example, I’d like to introduce the concept of “foundational tasks” which can be selected during the initial setup wizard when creating an estimate.

Foundational Tasks

Think of these as the common tasks associated with developing an app that isn’t specific to its business logic or routine coding and development procedure. Foundational tasks generally aren’t ongoing processes, although they may require some occasional or regular maintenance once put in place. At a minimum, most new projects will require the following to get off the ground:

• UI Design
• Database architecture
• Development environment setup
• Hosting and Deployment

Depending on the scope and objectives of the project, some other foundational tasks may be necessary or worthwhile to include as specific line items:

• Wireframing
• UX research and design
• Google Analytics configuration
• SSL certificate installation
• Automated testing
• QA testing rounds

For our ToDo app, we’ll be sticking to the fundamentals. We’ll want to do everything from the first list of foundational tasks, although the database architecture should be simple, so we may choose to reduce or even omit its cost. From the second list, we likely don’t need specific UX research or to do a prototype – it should be enough to build an MVP directly. Analytics will be worth setting up, along with some level of testing before going live.

You may not need to do some of these tasks if you have existing infrastructure and processes in place, and others may or may not add value to your project – it’s a judgement call. Even if there isn’t much work to do for a specific item, it’s usually worth including (with a respective cost estimate) if only to capture what will need to be done, and sum up all the “minor expenses” to produce a more accurate estimate.

It’s a common mistake to write off something as “easy to do” and ignore it during the planning process. However, these items can add up and lead to delays or increases in cost once the time comes to do them. Err on the side of caution – it’s better to come in under budget than over.

Choosing An Approach

Our estimator template offers two ways of calculating an estimate: by breaking down the team, and by breaking down the project tasks. A team estimate is a top-down approach. For example, “Who will I have on my team and for how long?” This is estimation from an Agile perspective. A task estimate is a bottom-up approach that comes more from the Waterfall school of planning. Working through both these methods independently means we can then compare and contrast the two estimates and, if they differ, try and work out why. It’s essentially a way to look at your estimate from two different perspectives and validate your numbers.

#1: Team Details

This is where you can list the roles, hourly commitment, and rates for the members of your team. When combined with the expected duration of your project, it provides a high-level estimate of the monthly and total project cost based on the defined staffing requirements. These positions often translate directly into job descriptions and postings when staffing a project.

For our ToDo app, we’re going to specify roles for two developers and a designer. The designer will have a lower hourly commitment than the developers, who will be doing the bulk of the work by bringing the designs to life. This gives us a quick ball-park estimate for what our monthly and total cost will be:

#2: Task Details

This section also outputs an Estimated Budget, but unlike the above Team Details section, it does this by tallying tasks, not roles. That’s because we like to think through the team and task sections separately. It can be easy to underestimate the work required to realize a project; small and routine items are easy to dismiss as requiring minimal effort. One-time tasks required to get up and running can also be easy to overlook. Creating a robust breakdown of the required work and associated costs can help produce an estimate that’s representative of what actually needs to be done.

This kind of breakdown can lead to a more accurate estimate than a high-level team approach, and also serves as a starting point for project planning with respect to the core tasks. Once you have this list, refer back to your team estimate and adjust the expected hours as needed. It may also reveal that an additional role is required. There is synergy between the two methodologies here.

The origin for these tasks is often a Product Requirements Document, and working from one makes this step straightforward. For our ToDo app, we’re going to add the Foundational Tasks we discussed above. Additionally, we’re going to include line items for the specific use cases, screens, and functionality.

We can then estimate how long it will take to complete each task and attribute that time to the team member(s) who will be working on it to compute the cost. This type of breakdown gives us a good overview of the core work that needs to be done in our project, with an associated estimate. We can then check the task-based estimate against the team-based one. If the numbers are close, that’s a good sign that we have an accurate representation of the work and staffing requirements to realize this project. 

Which Approach Is Better for Software Projects?

If you are primarily focused on hiring a team and not worried about how much a particular project will cost, then you can simply do the Team Planning part.  However, if you are primarily looking at getting a particular project completed within a certain budget, we recommend doing both. At some point, you’ll need to decide on the breakdown of your team, and the major tasks that need to be done. Looking at things from both perspectives lets you check your work and evaluate your assumptions – this ultimately leads to a more accurate estimate. At the same time, it’s important to keep in mind who the estimate is going to be presented to since that can shape how you choose to lay things out. 

When curating your tasks list, be mindful of your audience. If this estimate will be delivered to a CEO (or another non-technical decision maker), I suggest you keep the number of tasks fairly low and high-level. If, on the other hand, you intend for these tasks to be viewed by a technical audience and/or converted into ‘to do’ items on a sprint, then, by all means, be as technical and granular as you want.  You should also correlate each task to a role specified in the Team Details list since this can help justify requirements such as  “we need X hours of design work”, while also giving you an impression of who the responsibilities of your project are going to fall upon. 

If this all seems overwhelming to you or you don’t have much experience as a Product Owner – that’s OK. You can get started with a technical project manager or contact us and someone from our team can help. It’s what we’re here for!

Now good luck with creating your estimate!