Fixed price is not only a payment model of custom development, it also defines the process of the project creation and responsibility of all parties involved. First things first, all restrictions of well-known project-management triangle “scope-time-speed” are taken into account too. they cannot go beyond the budget and that is the most appropriate for all parties. Primarily, you should specify the budget. Customer has to plan all of his project requirements precisely. Then provider will calculate costs and terms. Consequently, a project manager will have no difficulties to manage the development process. Provider takes responsibility for risks and a team maximizes clarity in the planning.
The main problem of fixed price is absence of any flexibility for Customer which is necessary for the projects of medium and big scale, as such projects are constantly changing. In this case, a dedicated team and their cost become an optimal solution from business point of view and the price depends on provider’s hourly rate. Based on the contrary, fixed price is appropriate for small and medium-sized projects that take about up to three months: there are more unchangeable requirements and less backend logic.
In order to understand how successfully we work with fixed price projects, let us take a closer look at the process itself.
How is a fixed price project going?
1. A fixed price project is never started without fully documented requirements:
- product specifications where all requirements are thoroughly described
- UI/UX design - production mock-ups ready for use
- compliance criteria that define what product is supposed to be finished. They can include: activity lists with results, chosen test devices, supported platform or web versions.
These requirements must be either prepared by Customer or planned together with provider and then accepted. After having figured out the scope you can proceed to estimation stage. Customer and provider must have a clear understanding of what they want and come to an agreement.
2. When the requirements are planned and accepted, provider gets an implementation request which often includes a model of cooperation, goals, fixed scope, sprint division, with intermediate results, work and wages schedule, possible risks and ways of their solution, acceptance terms and work procedure with changes.
3. A prepayment is conducted. It is usually 50%. The further payment is at the end of every sprint.
4. Sprint result is product intermediate build with implemented functions. It is provided to Customer for him to control the progress.
5. Any requirements changes are carried out through a request - an additional agreement made by a project-manager. Development changes influence work scope and Software development cost, so a team reassess including changes. Then reassessment is claimed by Customer and development is keeping on with changes taken into account.
6. The last sprint result is alpha build with all functions. A team confirms the product is working right on test server.
7. During the last sprint finishing and polishing are made. It is shown in beta build (final build). Product testing is being started by real users.
8. After providing Customer with the final build, an acceptance period begins. During this time, Customer is checking the product according to acceptance criteria and he is giving feedback to provider. It usually lasts up to five days. If any bugs or inconsistency with checklist reveal on testing device, they are corrected by provider and Customer doesn’t pay for that. Time spent in this correcting isn’t included in the acceptance period.
9. After the testing is over, provider gets the final payment, sends source code to Customer, gets instant feedback and finishes the project in general. The product must go on Appstore at this stage, when Customer has made full payment for the project according to provider’s pricing.
Fixed price contract: pros and cons
What risks are possible in Software fixed price development?
- Scope risks are transferred to Customer. They can be soluted through change request discussed above.
- Customer also takes outsourced services risks which must work according to the terms established by Customer in his requirements. Provider must be aware in advance.
- Human error factor is transferred to provider. It can influence the schedule but not the final development cost. In case when provider cannot carry out his duties, Customer is told about that and replacement is being looked for.
- The risks related to outsourced libraries, services, API, SDK and other tools chosen by provider, are transferred to provider.
What is the next step?
After finishing, Customer receives feedback, bugs reports, customers’ new functions offers and so on. Concept understanding and its functionality can change. This solution may be decided with business and technologies. Therefore, Customer has two variants: either continues the product multiple proving or hires a team for little updating and fixes (usually 10-20 hours per month). Pricing depends on provider’s hourly rate.
Conclusion: what model of payment should be chosen for Software development?
Outsourcing companies using Agile methodology try to avoid fixed price as everything is constantly changing in the world of Software custom development. Sometimes to change something is Customer’s wish, sometimes it is technically necessary, sometimes it is market conditions. If the product is constantly developing, cyclical development is the best solution. It is faster as it doesn’t have any change requests and long reassessment. It gives an opportunity to see progress as Customer receives intermediate builds after every sprint.
What is the most important, it gives an opportunity for flexibility and changes and also for immediate reaction to market changes. The product relevance is easier to maintain. However, if a definite product is within fixed price model well, so this approach is the best for Customer. Feel free to contact us for more detailed information.