There’s no ready software solution on the market to help your business. You have an idea in mind and you know that you have to build your mobile application or digital platform from scratch. The whole process of searching for a tech partner and estimating your project starts there. Getting your first referrals and estimations, you’ll certainly notice that they differ from each other. But where do the differences come from? Let’s talk about two budget estimation models: fixed price and Time & Material (T&M, Agile).
At the end of the article, you will find a checklist to help you check quickly what budget you’ll probably need to create your new digital solution.
Before we start discussing individual models, we need to answer the question: What elements are important in software development?
We can distinguish the three most important things. The first is the price, the second is the features we are going to implement, and the last is the quality. Depending on the choice of the model, these elements are treated differently.
Fixed Price model. How does it work?
When we work in the fixed price model, everything has to be agreed upon before we start creating the solution. This means that in most cases, teams and analysts work on a very detailed specification that takes a lot of time and has a lot of pages of documentation. The team then estimates how many hours it takes to complete the project scope from the start of the software development process to the implementation of the last planned functionality. This approach may be risky for larger projects because of going through a long and very complicated process. From my experience, I can say that it is quite difficult to estimate properly in this model and, as a result, the obtained estimates in the fixed price may be very different.
The second important thing is that when you build an application, in many cases the requirements may change during the software development process and it happens quite often. How does it affect the budget? When we start for example a six-month project, after one or two months of development we can physically show something. Then our sponsor downloads the alpha version of the application goes to his clients and collects feedback. Suddenly it turns out that many things could be implemented differently, the requirements were not so clear or we have some new ideas from customers and users. This means that we have to make some changes that can affect the project budget. The question is how to make these changes if we are working in the fixed price model? From the supplier’s point of view, such changes should not happen. Changing the scope requires additional proceedings and can be much more expensive. Also, by choosing the fixed price model, we take the risk of delivering things that are not the most valuable for users. This approach works quite simply for non-complicated projects.
Agile methodologies (Time & Material). How do they work?
When we work with Agile methodologies such as Scrum, which are mainly typical time & material models, the entire team and the client work together to deliver the highest value of the product. What does it mean? That both the team and the client are very open to changes, and they work having a common goal: to provide users with the greatest possible value. If the team sees that something could be developed a bit differently and it does give customers more value, they do it.
Looking from a client’s perspective and describing it simply: clients pay for the time of the developers and the material they used.
What does the process look like?
In Scrum, we divide the process of building software into periods – we call them sprints. Sprints are planned for two weeks, for example. As a part and result of each sprint, specific functionalities are provided and the client is informed of what will be delivered by the team in a given sprint. If any functionality needs to be changed, it is very easy to implement something else.
From the supplier’s point of view, the Scrum model is much better. From the customer’s point of view, it is difficult because you never know what the final budget of the entire project will be. How to protect yourself from it? In my practice, the best way is to set a budget. At Leaware, we talk to the client before starting the software development. We define what we will do, and we write the whole specification, but the purpose of this specification is different: the goal is not to ensure our security, but the purpose is to understand what we intend to achieve and deliver. And also the specification of the goal is the budget estimation. When we start to develop, we mean what kind or what a big budget is. And after each sprint, we talk to the client using review meetings, which are part of the Scrum methodology, and then discuss where we are, what has been delivered, and what part of the budget is left. We control the budget within sprints, keeping in mind the common goal, and together we decide on the next scopes and the budget of the project.
Working closely with the client in this model, we can very nimbly make decisions about what we should focus on in the next sprint, and maybe what we should give up because it will not bring us much value. Moreover, the goal of the development team is not to implement everything from a fixed price specification, but the goal is to deliver as much value as possible and that is a goal shared with the customer. So that’s the main difference between those two models – fixed price and time & material approach.
Summary: Fixed price versus Time & Material: which model to choose?
To sum up, all the issues mentioned above, the question is: are Agile models always better? And the answer is NO.
If you have a simple product like a website to build, and your team has been doing it many, many times before, it will be very easy for you to make a good project estimation in the fixed price model. In this case, this model should work perfectly. If you can implement something new, or complex, you should agree with the client on an Agile model with a fixed budget and time.
As promised, I am sharing a checklist with you. It allows you to estimate the budget needed to build your software solution.
I hope you find this article and the checklist helpful!
