When planning to develop your software product, you must, at some point, pop the big question: How much will it cost? The cost is undoubtedly one of the crucial aspects that can make or break a deal. It has to be within your budget, that’s certain, but the question presented above is still not easy to answer. Why is that? In this article, I’ll try to explain that, presenting you with the examples of two most popular forms of contract: fixed price and time & material.
Fixed Price
A fixed price contract provides a single sum that is normally not subject to any adjustments (unless certain provisions that have been stated in the agreement beforehand) – meaning that in this type of contract, the price does not depend on expended time or used resources. These contracts are usually negotiated when the total cost can be estimated with reasonable accuracy.
When is a fixed price contract recommended? There are some prerequisites for a successful fixed price project:
- The scope is clearly defined and the outcome is 100% known.
- The materials are complete and well-understood by the development team.
- The timeline is realistic.
- The budget matches the scope and the timeline.
This type of contract may fit well with some services. Think about those that have their offer (along with all prices) available on their website. When the service is known, and the scope of it won’t change in the meantime, fixed price will work. While there are situations when we choose FP, we also realize that it is not the best model and it surely doesn’t belong with every project.
So why is it NOT the best model?
1. You waste way too much time
If you’ve ever worked with someone who tried to convince you that “it’s not a bug, it’s a feature” while you’ve been trying to explain your points proving that “it’s a part of the scope!”, you know what I mean.
The development process won’t just start day one, it’s not going to happen instantly. Defining the scope accurately may actually take some time. But what does ‘’accurately’’ even mean? See, when you order a product, you have certain expectations. You may express them well and make it clear to the service provider that you expect A, B, and C, but most frequently you and the other party will see things differently. It’s not about bad intentions, though. The point is that each person will just understand the sentence in a different way.
Let’s say you want to have a “Login” feature on your website. It may be obvious to you that there should be a possibility of signing up with your email address but also using Facebook, Google, or LinkedIn. Let’s emphasize: this may be obvious to you. When you haven’t specified what your expectation actually is, the developer will design it as he understands it. This may mean that you’ll end up with a simple email sign-up and nothing more than that. Was the job done? Yes. Did the outcome meet your expectations? Not really
The vendor will need the requirements really clear and accurate in order to accept the statement of work, and that slows you down. Plus, a higher budget will be needed. Why is that? There’s always a buffer of at least 15% included in the estimates to account for unexpected things or uncovered requirements.
2. Fixed price contract places the client and the service provider on different sides
In this scenario, the client tries to interpret the scope to include as many things as possible using the lowest price possible, while the vendor tries to interpret it in a completely different way: to do the minimum of work possible using the cheapest possible resources. The first one wants to get the most at the minimum price; the latter one, on the contrary, wants to get the most for the minimum work. It will never be a win-win situation, as there’s always a loser and a winner in this type of relation. Going back to the Login example: when your product is ready and you’re not happy with the result, you can only argue that it is not what you ordered. The fight will be time-consuming, energy-draining and may still leave the problem unresolved.
3. Communication problems may arise
A fixed price contract may also affect communication between the development team and the product owner. If the scope is (more or less) clearly defined before the development process even begins, not as much communication is needed. The programmers just do what’s been defined in the scope, and as long as there’s no need for further clarification, they don’t have to talk to the client at all.
While developing a product this way, sticking strictly to the scope, the chances of building a useless product are higher. Project development isn’t a map where everything’s in place and all directions are known, it’s an ongoing process where you have to be responsive to changes. However, there is no flexibility in responding to those when we work in a fixed price model. The ordering party can be given updates on the development progress but taking into account the limitations posed by the FP model, no adjustments can be easily made along the way. And if you come to a realization that you need an additional feature, the scope will change. You will then need to go through formal Change Request (CR) process, which ends up with signing an appendix to the original agreement.
Learn how to choose the best IT outsourcing company
4. It separates the development from business
Limited contact with the client and predefined scope may make the team disconnected from the product in a business sense. When they’re not engaged in the process of defining the product, it may feel like it’s only another project, just a job to be done. If there’s a clear boundary between what is ‘’you’’ and what is ‘’us’’, the business relationship is not a real partnership, but rather an official client – vendor relation. Given a chance to fully understand the requirements and the client’s actual needs, the team will grasp the ideas much faster and become a part of the client’s team. On top of that, the team can help you come up with better ideas and requirements because of vast experience with other projects they completed.
Time & Material
A time & material contract is an agreement in which the contractor is paid on the basis of the actual cost of labor (in hourly rates – man-hour) together with materials and equipment usage. This type of contract is used when there is no firm scope, or the work is for an indefinite period (i.e. ongoing development of the product).
Though being a fair option for both sides, a time and material contract is still subject to many discussions and opinions on it vary. Let’s have a look at some pros and cons of a T&M contract.
An important thing to note is that a T&M contract allows both parties to work in an agile way. That’s because we can react to changes and learn with each iteration. When the development is divided into sprints, at the end of which a functioning feature is delivered, there is room for adjustments. Every iteration is an opportunity to test whether the development is going in the right direction. Following the lean methodology, after building a certain part of the product (e.g. a given feature), we first present it to the client to get feedback and only then can we go further, having learned about what has to be improved or changed.
What value does Agile bring?
Agile way of working creates a transparent relationship between the client and the vendor, thus making it a partnership. The team is more involved in the process of developing the product and connected with it on a business level, which in turn leads to them being more dedicated. Working together with the client (rather than getting a list of tasks to do only) helps the developers understand the product. They can ask questions, suggest changes and, thanks to that, they get more engaged. This element is not so obvious in the case of an FP contract because constant communication with the client is not as necessary then and, even if we decide to have iterations, when we detect a needed change, it will still be difficult to make changes to the agreement.
What’s more, both sides can quickly react to changes, there’s a lot of flexibility when it comes to unexpected events – and that helps limit waste. The Scrum framework, with its planning sessions, daily stands, reviews, and retrospectives, helps organize work in a way that prevents creating features that will not be useful – we don’t waste time designing something that won’t prove relevant. With your priorities defined, you can react to business needs much faster: let’s say you’re having a demo with a potential client in a week and you need functioning feature X. It can be done, easily. The model of work that is adopted under a T&M contract allows us to adjust to the client’s needs. If the feature X is of the highest priority now, it will be done now and not in a month as planned. If feature X is out of scope but is necessary, the scope will just change.
Communication
In this model, communication between the development team and the client is based on honesty and transparency, which strengthens mutual trust and helps reach real partnership. Communication also helps the client plan their business better and avoid over-designing the product. In short: real partnership is based on honest and precise communication.
Transparency is a must in a partnership like that, so weekly time sheets and reports are delivered to the client – these are needed to keep track of how much time was spent on the development and to issue the client’s invoices accordingly. After each iteration, the team’s velocity is presented and that helps predict how many user story points on average can be completed in the next sprint. The iterations are short and lessons learned are applied with every iteration, all that while keeping in touch with the client to explain what, and how, is happening at the moment. It’s in the best interest of both parties that the team spends as much productive time on building the product as possible because it will bring results faster.
Now, let’s see some possible risks
You may think that with T&M, it’s the vendor’s best interest to burn maximum hours. With vendors that have low work ethics, this could happen but with a trusted partner, the situation is completely different. Good vendors understand that making the customer extremely happy is the key to building long-lasting cooperation, which is (or should be) the single most important metric.
There’s also a potential risk of running out of money along the way of developing the product – you can set a cap that could be used as the maximum of labor hours you can pay for. This may work well, but it may also leave you with an unfinished product. And that is exactly why trust and transparency matter so much to both sides – when all limitations are known, the vendor will do his best to stay within your budget and complete the most important things from your scope.
Why so different?
The difference between a fixed price model and time & material can be easily described using the example of something as simple as pizza. In the case of a fixed price contract, it is easy for any service provider to calculate how much it will cost. They know exactly what needs to be done, they can estimate how much time it should take, and give you the price. It’s like ordering a Funghi: you know the ingredients that you’d like to have on your pizza, you tell the waiter what you want, and you get the price.
Now, imagine that while you are waiting for the pizza, you see another client eating their pizza with extra prosciutto and you suddenly realize that this is something you would like to have on yours as well. You change the order, just to then call your wife who says that she would rather have Capricciosa. With extra olives on one half and maybe some pepperoni on the other one. So you change the order once again. If it’s not too late to change it yet, you wouldn’t expect to pay the same price as for Funghi, would you? Ordering software is not that different. Way more complicated, with many more variables, but with quite similar mechanics.
In fact, making your custom, one-of-a-kind pizza is more like T&M: while you’re developing your idea, the factors are changing and the final price can only be calculated when you’re done changing your order.
What can change about the software?
Assuming you have an idea for a product, you’ve done all the research, you have all the requirements listed and described, assuming that you are prepared to get a reliable estimate, it is still hard to predict what may happen when you start the development. When you go to this big conference and talk to the potential investors, or when your main competitor releases a new feature, you may want to have some flexibility in your project. So what scenarios are common while building a software product?
First of all, there are always changes to the scope in different phases of the project. You may not know exactly what you want from the very beginning and it’s only natural that you will feel like you need some adjustments or additional functionalities. It’s hard to predict that when the project starts. There are a lot of reasons why the scope may change, listing just a few of them:
1. Taking the first step often unleashes many new ideas
Once you can actually click through the early version of your product, you may notice things that you had not thought about earlier. You may want to change something, add something, or go in a totally different direction. With a fixed price contract, it poses a problem as the scope of the project should be clearly defined at the very beginning.
2. Confronting your idea with an experienced team often sparks discussions that may change your idea
Sometimes the change is slight, sometimes it is bigger. In the most extreme case we’ve had in Neoteric, after completing a 3-day workshop with us one of our clients decided to discard six months of their previous work and redesign their product in a completely different way (that’s the power of experience mixed with honest and direct feedback!), which led to the development of a superior product.
3. When you show work-in-progress to your future customers, their opinions may differ from what you thought they would be
This is perfectly normal and is one of the most common scenarios (read more here: Do NOT start your app with an MVP!)
4. Your market may change during the development
The competition may release their new product or a feature, and if you don’t react to this change, you may easily lose your competitive advantage. A new law may be published and it may turn out that the way your product is supposed to work is not legal anymore – it may, for instance, require a different way of authentication or handling payments in some different way.
5. Your business model may change
6. A third party service that you rely on also can change
A quick example: you use a live feed source and it stops working! Or it turns out that it’s not as reliable as you thought it would be. In any case, you need to search for another one and change the scope of your project.
Every change that you need to apply will hit you directly in this fixed-price contract because you have to renegotiate its scope, budget, and timeline. Every time. It slows you down.
The solution? Your own mix of both
The two types of contracts have their advantages and disadvantages, and as it may sometimes be difficult to make a definite decision to stick to one or the other, we chose to mix the best of both of these solutions. We’re listening to each client’s needs and requirements to identify what the best proportion of FP and T&M will be. You may, sometimes, choose a fixed price contract, for example when the scope is small (under 300 man hours) and well-understood, when Proof of Concept or Prototype phases occur, to keep the cost predictable, or to see how both companies fit together. You can also go for a time and material contract which will be a good option for you when the trust between you and the contractor is already high (maybe they were recommended to you by someone you know well), or when the requirements are not complete or clearly specified.
In our experience, we’ve found that starting small with a fixed price and later migrating to time and material is the best model. During the first stages of development, fixed price will work in most cases (unless you’re dealing with highly R&D project), so you can see how the cooperation is going, the process will be predictable and transparent. Later on, as the complexity of your product unfolds, you will need more flexibility, dynamic work scope, and better timing. That’s when T&M steps in. Nothing is 100% predictable now, but you are highly involved in the development process, which means that you know what’s happening and you still have control over your project.
If you’re still in doubt about whether you should go for a fixed price, time and material, or a combination of both, ask for opinions. Get some references from other customers, ask around, or simply lay your cards on the table and tell your potential vendor about all your expectations and worries, so they can advise you on which way to go.
