Fixed price VS Agile (time material) approach, which one is better?
If you are going to build a new application and you are looking for a technology partner to help you with it, you need to be prepared for the fact that the estimates you will receive will differ from each other. Perhaps you have already received initial valuations and are wondering where the differences come from? You may feel confused. This is normal! Today I will tell you about two budget estimation models for your application: fixed price VS Agile (time material).
You will learn, among other things:
What are the differences between the models?
Pros and cons of each approach
Which model is better and why?
When to choose a fixed price and when to choose Agile?
At the end of the article, I will share a checklist with you, thanks to which you can quickly check what budget you need to create your new application!
Let’s get started!
Before we start discussing individual models, we need to answer the question: What elements are important in software development?
We distinguish the three most important things that influence software development. The first is price, the second is our features that we are going to implement, and the last is 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 software. 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. The team then estimates how many hours it takes to complete the project scope. From the start of work to the implementation of the last planned functionality. So it is quite dangerous because for larger projects we have to go through a very complicated process.
From my experience and many vendors, I can say that it is very, very difficult to properly estimate this. As a result, the obtained estimates in the fixed price model may be very different.
Second, when you work on building an application, in many cases the requirements change during development. This is perfectly normal. How does this affect the budget? When we start, say, a six-month project and after one or two months of development, when we can physically show something, 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, that the requirements were not so clear, that we have new ideas from customers and users. This means that we have to make some changes that affect the project budget.
The question is how to make these changes if we are working in the fixed price model? So this is a big disadvantage of the fixed price model development because, from the supplier's point of view, such changes should not happen. By choosing the fixed price model, we take the risk of delivering things that are not the most value for users.
Agile methodologies. How does it 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? This means that both the team and the client are very open to changes, they work with 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 really does give customers more value, they do it.
What does the process look like?
In scrum, the way this is done is by breaking down the creation process into periods of time - we call them sprints. Sprints are planned for a period of two weeks, for example. As part of each sprint, specific functionalities are provided and the client influences what will be delivered by the team in a given sprint. If something needs to be changed, it is very easy to answer it and implement something else.
So from the supplier's point of view, the scrum model is much better. But from the customer's point of view, it is difficult because you never know what the final budget of the entire project will be.
So there is also some risk, how to protect yourself against it? From my practice, the best way is to set a budget. At Leaware, we talk to the client before starting development. we define what we will do, we write the specification of the documentation, 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, 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, where we use review meetings, which are part of the scrum methodology, and then discuss where we are, what has been delivered, and how much budget is left. We control the budget within sprints, keeping in mind the common goal, and together with the client, we decide on the next scops and the budget of the project.
And this way, with the client, 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 shared goal with the customer. So that's a big difference.
Summary: Which model to choose?
Are agile models always better? The answer is NO.
If you have a simple product to build, a website, and your team has done 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 will work perfectly. Overall, we can break down the development models into two different scenarios. If you can implement something new, complex, you should agree with the client on an agile model with a fixed budget and time. If you are going to do something you have done many times before then the Fixed price model is OK.
As promised, I am sharing with you a checklist that will allow you to estimate the budget needed to make your applications! I hope you find this article and this checklist helpful!