When you are about to work with another company that will provide you with the required services, you need to define the scope of work, allocate your budget and resources, and decide on the type of contract model that both parties will follow. As a custom software development company, at XB Software we are always open to finding middle ground in order to provide our clients with the best solutions and let them spend less resources.
When customers come to us with their requests, some of them want to work according to a certain contract, while others may be unsure of which type is the best in their case. It is not a surprise, because there are different types of contract models, including Time and Materials (T&M), Fixed Price (FP), and more, which is why it may be difficult to choose. In today’s article, we want to talk about the Budget with Float Scope (BFS) contract type and how it differs from Time & Material and Fixed-Price types of contracts.
Being on the Fence Between T&M and FP
Is it possible to develop a product while working with a vendor according to the Time and Materials contract? What about the Fixed-Price contract type? Is it better?
Yes, yes, and it depends.
You can definitely choose to work with a vendor based on a T&M or FP contract if you want. For example, our company is not new to working in different types of collaboration, which you can check for yourself on our How We Work page. However, your choice of a contract will greatly depend on the initial requirements.
Based on our experience, we know the strong and weak points of choosing T&M and FP contract models, so let’s see what each of them can offer.
Time and Materials Contract
If one chooses this type of contract and follows Agile principles, the development process starts with the disclosed idea and then proceeds with the iterative or incremental development models. This way, you save your time and money on creating Software Requirements Specification (SRS). The features transform into tasks, and you just submit them into the task management system to know what should be implemented.
When choosing this type of contract model, the success of your project depends on how explicitly you defined the end goal and how clearly you understand the cost of achieving it. There are no methods of creating an accurate estimate based on a disclosed idea, because you can refer only to analogies. For example, a product development project with an idea similar to yours lasted 5 man-years. It doesn’t mean that the schedule of your project will be the same. It may or may not.
Fixed Price Contract
FP is good for Minimum Viable Product (MVP) development and other small projects, especially if the deadline matters. If one goes for this type of contract model, everything starts with the creation of a detailed SRS document. It helps to establish a more or less accurate budget and define a Project Execution Plan (PEP) as well as evaluate the necessity of your endeavor. When choosing the Fixed Price contract type, the success of your project depends on how explicitly you defined the end goal.
Do you need all the features included in your idea? Do you even need them to be implemented in the same manner you determined them in the SRS? You will be able to find out answers to these questions only after you finish the project and show it to your target audience. And statistics show that users don’t like or use each and every feature of a product.
Eventually, you will probably get a product that will need refinement at the end of your project. It means that you will have to spend more of your time and money. Thus, your illusionary confidence in planned budget and schedule shatters in pieces, because you were too sure about the features your users expected to see and thought that you got them right.
Read Also The Intricate Art of Maximizing Value. How To Make Every Coin Spent Worth its Weight In Gold
As you can see, on one hand, both contract models demand clear and explicit understanding of the end goal. On the other hand, they may not give you confidence about your budget and schedule and, as a result, about the project success.
Killing Two Birds with One Stone
If choosing a T&M or FP contract doesn’t seem applicable to your project, you may go for a mixed type. We call it the Budget with the Float Scope (BFS) contract, but you may also know it by the name Product Development Agreement. Just like any other contract type, it has its own pros and cons, so let’s take a closer look.
Let’s say you have an idea, and you are ready to spend some money to get a product by a certain date – these are your initial requirements. So, the input is an idea, budget and deadline, at the output you have a valuable product. Your budget and deadline are a part of the FP model, while your idea and a valuable product are a part of a T&M or Agile model.
Combining everything together, you get a product development project that leads you to the implementation of your idea and creates the maximum value within the budget and deadline. This is what the Budget with the Float Scope contract model is.
The approach of implementation of this method differs from T&M and FP. It is based on the following rules:
- Cooperation;
- Every stakeholder is well-informed about the idea, budget, and deadline;
- It is possible to increase the budget allocated for one feature only after decreasing the budget for another feature.
These rules create certain process of implementation of such a project, which include the following steps that need to be made:
- In order to understand the scope of the project, an idea should have a rough description;
- The product is then broken down into features that should be implemented;
- Budget is allocated between those features, and also don’t forget to have some amount for the unexpected situations. Usually, it is about 10%;
- The process of developing features starts with the creation of the scope of a feature, then it is broken down into tasks. The tasks should be evaluated, and it is vital to define their priority. Based on the allocated budget, the feature is then implemented, and other tasks are for the other versions of the product. If for some reason the allocated budget wasn’t enough, you need to pay attention to rule 3.
- When ready, the demo with the implemented features is done to get feedback from the loyal users who are able to assess the value of the product.
Keeping Close Watch on the Process (3 Useful Tips)
Any process should be monitored and controlled, otherwise it will have power over you. In order to be able to manage it, you can follow the Earned Value Management (EVM) method. It demonstrates the project implementation status compared to the initial plan. EVM is a critically important tool, because it helps to see the first traces of the deviation from a schedule or budget in case it happens. Thus, you will be able to make alterations by having control over the situation and identifying that something is wrong.
Read Also Earned Value Management (EVM): How to Forecast Project Outcome and When Does EVM Help?
It is vital to avoid the traps of self-deception that lead to the loss of control over the project and budget increment. Therefore, we want to share some useful tips and recommendations to make the process more clear.
Tip #1
According to the third rule we mentioned above, the increment of one thing comes after the decrement of another. However, you should understand that only the known should be reduced. It means that you need to describe the feature, break it down into tasks, evaluate them, and only then you will be able to understand which features may require less budget. By decreasing the budget blindly (for example, by setting 250 hours instead of 300h and expecting to somehow deal with the lack of time later), you get more and more “decreased” features. As a result, you will have to deal with a lot of unfinished features without having enough budget.
Tip #2
Users’ feedback that you get after showing them a demo of your product should be registered the same way you registered other tasks for each feature. Each task should be assessed in order to understand the priorities and clear out if a feature is even that necessary based on the budget you have. You may be tempted to please all users and implement anything they ask for, but you shouldn’t forget about the budget allocated for each feature.
Tip #3
When you don’t disclose the budget for your project to the vendor you are going to work with, suspecting that the company will spend any sum you say, these doubts reduce the effectiveness of the recommendations a vendor can offer. The value of a feature and the allocated budget highly depend on the way you implement it. And the decision of how a feature will be implemented is based on the budget and value. So, how can a vendor help to define the optimal way knowing only half of the truth?
Besides that, all features should comply with their value. Without knowing the available budget, the vendor will most probably advise to develop the ones with high value first, leaving the features with low value closer to the end of the project.
Let’s say you tell the vendor that you have X amount of money allocated for the project budget, but in reality, you are ready to spend two times more. It doesn’t matter how much money you have, however the amount you are ready to spend on the development process matters.
Therefore, if you said that your budget is X, then you should stick to your guns. If a higher amount will be needed for the feature implementation, and the vendor tells you about it, but you tell them that everything is fine and that they should proceed, the vendor will understand that the team doesn’t know the real budget. This is confusing for a vendor, because the team doesn’t have a clear idea what to expect and how to act: according to budget or not?
If nothing unexpected happens, closer to the end of the project, you will find out that you have 10% of your budget in spare to complete the tasks according to the set priorities. And, you will be able to deal with more valuable tasks that were created based on the gathered feedback.
Unfortunately, sometimes unexpected events may happen, and the implementation of first features will require more of the allocated budget. For example, a miscommunication between parties occurred while describing and understanding the idea or a vendor decided to do something the other way than was discussed. The tasks weren’t evaluated thoroughly for some reason or something new emerged. In any of these cases, you need to pause the project and find out what is happening with it. Maybe you will need to reevaluate some features or decide whether the development process should even continue.
Read Also Cannot Decide on the Right Type of Contract? The Answer Can Be Found Easier Than You Think
Conclusions
The first rule of the BFS model is cooperation. If you don’t follow it but stick by the “take it or leave it” rule instead, it will be much easier for you to fall in a trap and finish the project unsuccessfully. Have you managed to create a pleasant environment based on collaboration and clarity with your vendor? Usually, the answer can be found when you describe your idea to the vendor, when the features are broken down into the tasks, when you discuss the budget for each feature, etc. This is basically before starting the development process and spending the budget. So, be prepared and responsible, and the BFS model will help you to make your dream come true.
If you want to know more about the Budget with the Float Scope contract type or want to have a free consultation and describe your idea, please contact us, and we will be ready to assist.