Founders, business leaders and of course, budget holders, need to know what something is going to cost. Putting a price on software development isn’t always as easy as it appears.
Sure, you can attempt to take the Fixed Price approach. As a client, in theory, you should be able to approach a software developer or team of developers with a whist list of features and they should, in theory, give you a price for that work. With that information, you can decide to work with them, or get more quotes from other firms, then go with the most reasonable, or the one you are confident will deliver on-time and on budget.
However, we at YouTeam – and anyone who’s ever commissioned software or an app – knows it is rarely that simple (unless a project is extremely limited in scope, with a small budget). Most of the industry – around 90% of software firms and developers – prefer the Time & Materials model for estimating the true cost of software development.
In this article, we will outline realistic ways to work with developers when estimating and scoping out the costings of a development project, and how you can reduce those costs when at first glance, they risk exceeding your budget.
Benefits of Time & Materials costings
Budgeting using the Time & Materials model means that clients are only paying for the hours worked on a project (which is something every developer should be actively tracking) and any ‘materials’ used, e.g. the cost of software and in some cases, hardware, to develop a finished product.
At first glance, this sounds as though clients risk not having control over the budget. Surely this model means the more time a team spends working on software, the more money they will generate? Of course, budget holders would never agree to such a contract. Commissioning software is not a black hole that absorbs your budget with no sign of an event horizon.
What this approach means is that unlike the fixed price model, a software team and those responsible for the project in the client company are working together to achieve a shared goal. Ownership should be assumed jointly, and developers are trained to prepare ongoing business cases for features and decisions that need to be taken. Developing software is often an iterative process, with the aim to complete a project as close to the needs of the client while sticking as much as possible to the original budgetary estimations.
On the other hand, when you attempt to stick rigidly to a fixed price approach, either shortcuts need to be made or the software team needs to absorb hours internally. Often a situation evolves whereby both sides resent one another and the results fall short of the goals.
Let’s take a closer look at the benefits of the Time & Materials work mdel.
How clear is your idea for the software that needs developing? Do you have a complete list of features and the user-experience mapped out? Will it require user testing – an MVP put out into the market – before you know what is needed?
Most software products need to go through several stages, including an MVP and beta testing, before companies have a complete overview of the features users actually require.
Estimating software development costs is easier when you start with a scope, and then more details come to light as you work with developers to outline the desired objectives. It can take time to estimate the minimum features needed to test the theory, and then the steps required to implement what you need for the end-goal.
Only when features are limited does it make more sense to sign a contract for a fixed budget. In most cases, when there are multiple features, integrations with databases or other systems, and a project is going to involve several stages of development, should the costings scope reflect that.
Work with your development teams to create the most accurate estimate possible, including timescales and deliverables required from both sides. Before going ahead, make sure both parties agree who’s responsible for the various actions that need to be taken. And have a process in place for keeping on budget and making adjustments as needed.
Understanding risk is an important part of the software development process.
Having an open and honest dialogue means knowing what assumptions need testing and therefore what outcomes these tests might create, and any costs associated with extra work that might be involved. The last thing you want is for developers to take actions that will cost a company more, and then for the company to be surprised when extra work costs more in the budget.
Surprises such as this increase software development costs and create distrust between developers and project managers. This is a risk best avoided from the outset.
Start with an estimated budget, with flexibility built-in, and within that a series of actions and outcomes.
For example, if you get to one stage of the project and test an assumption – and the follow-up action requires an extra 20 hours of development time, this should be factored into the agreement before work commences so that budgets can be planned accordingly. Providing a sensible business case can be made – and there is ongoing communication throughout the project – there is no reason for any distrust between those developing software and the client they’re working for.
Taking a flexible approach benefits both parties.
Unless a scope and project timescale is clearly defined – encompassing every top-level technical detail – it’s almost impossible to fix the cost of a software development down to the last dollar. A wide range of factors can influence the cost outcome, including the amount of testing and experimentation needed and the outcomes from those tests.
Instead of both parties at odds with one another, when business leaders and budget holders ‘co-own’ a project with software developers, a cooperative working arrangement can ensure a successful outcome.
Providing both parties stick to clear processes and milestones then development budgets can be managed effectively. Taking ownership together should result in software that is much closer to the companies original vision for it while knowing that the budget was realistic and delivered the work as planned and on schedule.
4 ways to estimate the cost of developing software
Agile is one of the most popular development models in use today. And yet, even with an approach that promotes the benefits of iterative learning, constant testing, and short-term ‘sprints’ to deliver impactful parts of a project in stages, 1 in 6 software projects go up to 200% over budget.
One of the challenges is that during a software project, the goalposts can move. Business leaders want to know when something is going to be “done”, even though the definition of success, or at least one of the milestones a team needs to reach often moves over time. Unless a project scope and every feature are outlined and agreed from the start, a flexible approach can mean that the client will suggest new features without much thought to the technical work – and therefore cost – required to deliver what they want.
When the definition of success keeps shifting, conflict can arise and budget estimates can turn into budget black holes. Or a project risks grinding to a halt, causing delays and ongoing problems.
Using the Time & Materials costing model, here is how you start turning an idea for software into an accurate project budgetary estimate:
- Clearly define the outcomes;
- Now use that to identify the decisions that are needed and questions that need answering to achieve those outcomes
- Break the project down into smaller pieces and milestones – ensure that everyone agrees on these
- Use previous projects of a similar nature – or reference class forecasting – as a way of creating a costings estimate
- Make a priority list of “must haves” and only “nice to haves” for your software, so that you’ve got a clear idea what an MVP should look like – and cost – compared to the finished, all-singing-all-dancing final version.
With this information, you should have a list of either features, milestones or both, and using those a team of developers can estimate the number of days/hours required to deliver the work. Breaking that down into smaller pieces, use an element of the project, e.g. a trial phase or a small feature that fits into the larger project, then make that a sensible basis for estimating the overall budget. A prototype could be a good starting point – since it provides a 3D version of the vision – and will provide an example of working timescales and team productivity.
Once you’ve got an estimate of the budget needed – which could be anything from a few thousand to hundreds of thousands (depending on the scope, complexity, number of features/integrations, time and skills required) – you need ways of keeping those costs under control and the project on-budget. Here are some of the most effective actions to take to keep everything running smoothly:
1. Align requirements to technical outputs
Clients who regularly ask for “this amazing new feature” without understanding the technical work required can unintentionally cause project costs and timescales to spiral out of control. Instead, if you are working together on the assumption that when a new feature is requested it will adjust the budget – with an outline of the work involved for that change/feature — then you can stay on the same page.
When the budget for those changes is approved, technical teams can work to implement what is needed knowing that the non-technical managers understand what is involved.
2. Share product ownership
Both the team developing the product and the managers/stakeholders on the client’s side need a clear vision of the project outcomes. Keeping the ‘big picture’ broken down into silo’s is useful for sprints and to avoid any confusion and mission creep, but when no one can see the whole picture then everyone risks stumbling around in the dark.
Having the benefit of a product manager keeping everyone involved focused on the shared vision, and a project manager with sufficient technical understanding is one of the best ways to keep software development on schedule and on budget.
3. Implement ongoing iterative testing and quality assurance
- Product managers should factor in reflective testing to the end of every sprint. Without this, you risk learnings not being understood and changes that are needed but won’t be implemented in future sprints.
- During every phase, product teams should pre-test code in a secure environment. This way, when a finished – clean – version is uploaded for a client you can be confident it works as needed and there will be fewer changes required before moving onto the next phase or feature.
4. Project best-case to worst-case project cost scenarios
When a project is particularly complex, it might be necessary to split the project development into a few stages and make sure to have an estimate for each stage.
How to do this?
One of the ways is to create a table outlining the various steps in the project and the estimated number of days/hours to implement. In one column, product managers should be able to plan for the best-case scenario (if everything is delivered quickly and on-time, with minimal changes and complexity), and for the worst-case scenario in the second column. This way, if everything goes smoothly, a client has one price; and if not, then they’re prepared for the bigger budget.
In case a development team is working closely with a client, having the document they will be able to communicate a clear and transparent idea of the expected outcome and potential costs associated with the software development process they are going to launch.
Benefits of working with teams in Eastern Europe
Unlike development teams in the UK, the US, China, and Asia, development teams in Eastern Europe are more cost-effective and have extensive experience working with corporate and small and medium companies around the world. Eastern European universities have long-since focused on delivering robust and forward-thinking science and technology courses, with the region benefiting from an extensive talent pool that continues to gain an enormous amount of practical experience from an early age developing software for corporate clients and startups.
Developers in Eastern Europe are also well-versed in understanding the business case behind software solutions that companies need. Agile teams can be put together quickly. Communication is fast and effective, without the language barriers clients can experience in other regions. When you source a team using YouTeam, many developers in our talent database, as you will find, will be based in Eastern Europe.
Benefits of working with teams in Latin America
With the amazing universities, education, and quality of software development in Eastern Europe, why companies choose to outsource to Latin America? Time zone match with the US, and especially not a big difference with the West Coast time zone are among the top reasons startups, SMBs and enterprises enjoy working with Mexico, Brazil, Colombia, Argentina and Chile. It might be a bit more expensive than in Eastern Europe but is considered as an extra for convenience.
However, from YouTeam’s experience, companies are looking for talent to hire in the first place. The location of a developer when the match has happened does not really matter in the end.
Why work with YouTeam?
We carefully vet development firms and the developers working for them. We make sure that our customers get to pick from the most senior, experienced talent with the capacity to take on their projects. We do not offer to hire freelancers, only developers from vetted IT agencies, so you have more control over the work that is being done.
Why we offer a better service than Only then you meet the firm the developers are a part of. When working with developers through YouTeam — wherever they are — we provide a safe payment solution for the entire duration of your contract, and we reduce the risks usually associated with outsourcing work to a firm in a foreign country.
So in order to ensure a realistic estimation and scoping out of the development project costs when working with software developers, make sure to keep in mind the following steps:
- Agree a project scope
- Agree development timescales and milestones (clearly understand responsibilities and roles)
- Agree a project budget estimate with the flexibility needed to deliver the scope and project outcomes.