[REPORT] From Vision to Code: A Guide to Aligning Business Strategy with Software Development Goals is published!
GET IT here

Why You Shouldn’t Estimate Software Projects

readtime
Last updated on
July 2, 2024

A QUICK SUMMARY – FOR THE BUSY ONES

TABLE OF CONTENTS

Why You Shouldn’t Estimate Software Projects

Once you’re ready to get started with your software project, you’re probably asking yourself two questions.

How long will it take? How much is it going to cost?

Planning software development is a delicate affair and getting precise answers to those questions is never easy. If you try to estimate by all means, you’ll probably end up mismanaging your time and resources.

Sticking to estimates can lead to a bumpy road, especially when you’re outsourcing software development or working with an Agile team. There’s a way to avoid that. But to really plan ahead and get a better grasp of the time and budget, you need to understand why estimates don’t work in the first place.

Software development is a complex process

Agile software development almost by definition focuses on evolutionary approach and continual improvement. Requirements and solutions keep evolving throughout the development, making it’s almost impossible to plan a tight schedule for a project, let alone keep to it.

Both your expectations and the methods chosen by a development team are very likely to change during the course of implementation. Your initial ideas could change, too. After all, planning the architecture, tweaking features, and optimizing User Experience (all key parts of the process) can bring something completely new to the table.

Software teams can give you close assumptions, but they will be just that – close assumptions, not strict constraints.

Don’t require tight deadlines and targets. It’s almost impossible to say how long it’s all going to take unless you work with the team to specify the priorities (more on that later).

IT projects are like R&D projects

Every IT project is about building a fully functional service that’s able to solve a particular problem or meet a set of specific expectations. It’s crucial to start with a detailed analysis of the starting assumptions. Only then you can move to a planning phase and pick a fitting set of tools for developing the right solutions.

It’s not like building a house, where you give a contractor a blueprint along with a list of materials and simply wait for the construction to complete.

With software engineering, you’re essentially starting with a set of unanswered questions which often require breaking new ground and coming up with something that’s never been done before.

You’re going to see the results eventually, but it’s really hard to plan ahead from the very beginning.

By asking for estimates, you’re running a risk of being misled

Finding a software development company is a complex task in itself. Each time you have to compare a number of different options, double-checking each team’s experience, process, and offer.

Development teams are perfectly aware of the fact that they’re not the only ones on your list. And they will try to do what they can to stay on it.

This includes coming up with lowered estimates. Knowing that the initial assumptions are going to change nevertheless, development teams often try to convince you that they will do the job faster and cheaper than others.

After all, isn’t that exactly what you’re looking for?

When it comes to software development, you have to remember that by clinging to economic reality, you’re trying to control something that is beyond your control. If you want to plan ahead, you need to change your perspective and shift your focus from optimizing time and budget.

It just won’t work in the long run.

Sticking to a list of features and specifications can lead nowhere

By setting the scope of the project in stone, you’re limiting the potential added value.

Sure, you want your app to have some specific features, but at the same time you need to remember that together with the development team you may come up with different solutions. They might work better for a final user and be easier to implement.

For best results, you need to work hand-in-hand with the software company and trust their expertise. Remember, good developers not only code, but also consult – this is a rule of thumb.

Together, you’re building a product that meets the expectations of your final users – not just yours.

OK, so what are the alternatives?

Narrow down the scope

Try to define the priorities and milestones for specific frames of time, e.g. 3-month-long product phases.

Instead of asking for an overall time estimate, go through those milestones together with a development team. Try to lay out the expected outcomes and key features and specify what can be implemented in each phase.

Prioritize

Manage your requirements and sort them by importance. During the initial phase of the planning process, break down the features into four categories: must-haves, should-haves, could-haves, and won’t-haves.

This method, often called the MoSCoW method, is particularly helpful in creating an outline for Agile software development process. It lets the development team gain a better understanding of your project and makes planning time and budget a lot easier.

This is just one way of approaching prioritization. You can also calculate the cost of delay or create an impact/effort matrix.

Clearly define your project vision

Focus primarily on the users: their needs and problems and the way your product or service will address them.

A clear and brief summary will help the project team better understand your expectations. Once they know your business perspective, it’s easier to pick the most-fitting features and tech stack, and come up with an approximate time perspective for developing the solutions.

This approach will also help with setting the priorities, especially for the first phase of the project.

Frequently Asked Questions

No items found.

Our promise

Every year, Brainhub helps 750,000+ founders, leaders and software engineers make smart tech decisions. We earn that trust by openly sharing our insights based on practical software engineering experience.

Authors

Matt Warcholinski
github
Chief Growth Officer

A serial entrepreneur, passionate R&D engineer, with 15 years of experience in the tech industry. Shares his expert knowledge about tech, startups, business development, and market analysis.

Matt Warcholinski
github
Chief Growth Officer

A serial entrepreneur, passionate R&D engineer, with 15 years of experience in the tech industry. Shares his expert knowledge about tech, startups, business development, and market analysis.

Read next

No items found...

previous article in this collection

It's the first one.

next article in this collection

It's the last one.