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! Our Software Development Estimation Tool started life as a spreadsheet, before progressing into a recently updated online tool (or mini web app). This article discusses how to use the estimation tool for software development, as well as the underlying methodology that powers it. In particular, how looking at every project through two lenses (team planning and tasks) can improve your understanding of the software project’s cost and timeline.
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 built a free tool to guide others through the most essential parts of software estimations and project planning.
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. 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?”
The Scalable Method
Our solution, which we have very modestly named the Scalable Method, advocates what Buddhists might call the ‘Middle Way’. You see, we’re not convinced that the Agile/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. The Scalable Method 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 Tool
Now let’s get into the nitty-gritty. Our estimator tool has two principal functions:
- Identify the team needed to deliver your project.
- 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 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)?
The Project Estimator app works seamlessly with our Job Description app. So, once you’re happy with your team and estimate, we’ll 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 app 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 Tool and create a new project. Click the Start an Estimate button and proceed through the wizard. You can skip the foundational tasks section – we’ll discuss this in the next example.
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. Click the Add Team Member button and then choose your first role. I’ll create a Senior Developer role, but you can select whatever role is appropriate for your project. If none of the options seem to fit, just select Other and type in the name of your role.
Now input the desired hours you have agreed on with your client. In my example, this will be a full-time role, so I’ll select 8 hours. You’ll notice the app will then pre-fill the rates. These aren’t set in stone though – you can edit them – they’re more of a guideline. In the case of my Senior Developer role, the app lists a $50/hour rate.
Next, you’ll see the Create JD (job description) option. If you’re looking for a remote developer to fill the role, we’ll be happy to help you. Simply click this link, create a job description and our team will contact you to discuss the details if you’d like. If you already have someone in mind, you can skip this step. 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,000, 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 free PRD tool. 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 that breaks down the project’s requirements and deliverables.
Before digging into how to use the tool 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 develop an MVP directly. Analytics will be worth setting up, along with some level of testing before going live. You can see an example of what this looks like here.
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.
TWO APPROACHES
Our estimator tool 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 estimating 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 of the app. This information can be moved over directly from an existing PRD by using the Create an Estimate button at the bottom of the PRD page.
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 particularly 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 – maybe because you don’t have much experience as a Product Owner – that’s OK, we’re here to help. Contact us and someone from our team can jump in, that’s what we’re here for!
Now good luck with creating your estimate!
Software Project Estimation FAQ
Can I Use This Tool for Software Project Estimation If I Am Working in an Agile Fashion?
Yes. If you have the relationship in place with your client to run with a monthly budget and build in an Agile way, perfect. That is actually how we work with the majority of our clients.
Should I Pad My Task Hours to Account For Unknowns?
No, you’ll notice that next to the total cost there’s a range. We’ve already built in the multipliers that should make the range fairly reasonable and account for a margin of error. You can also customize these multipliers by clicking the gear icon next to the estimate.
Can You Explain the Math to Me?
Sure. There are two main calculations going on. The monthly cost is calculated using a standard 174 hour work month. The budget range is calculated using an x0.8 multiplier for the lower range and x1.3 for the upper range because projects are more likely to end up over the estimate than below it.
What Is the Difference between Team Planning and Task Parts Again?
This might be best explained with an analogy. If you need a quote to get your kitchen remodelled, you will speak with a contractor. You’re asking this individual because they have experience in this area. Before you go to the contractor, you do some research: find photos of kitchens you like, draw some sketches, choose which floors, cabinets, fixtures, etc. you want. This is your Requirements Document for your Kitchen Project. Your contractor will use this information and, using their experience, give you an estimate. They remodel kitchens for a living, so they can guess how many people-hours will be needed to complete the project. This would be like your Team Estimate. But what if you want the contractor to really break down the elements involved in remodeling the kitchen. Maybe the estimate is close to your max budget, so you ask him to break down his estimate into tasks. This way you can decide if every aspect of the build is required, and find areas where you can save money. For example, the cabinet work you chose might be expensive, so you may choose a cheaper option. This is your Task Estimate. This is a more involved process and as such, likely a more accurate estimate of the project.
We suggest you do them independently for the same reason you proofread an important email before you send it, or ask for a second opinion on something that matters. Validating an idea is important, and thinking about an idea from different perspectives is equally important.
Editor’s note: This article was originally published February 19, 2019 and was updated on June 14, 2021.
Are you looking for help with your next software project?
You’ve come to the right place, every Scalable Path developer has been carefully handpicked by our technical recruitment team. Contact us and we’ll have your team up and running in no time.