Fixed Price Contract For Software Development Projects
The fixed price approach always affects the process of software development. In this case, the constraints of the well-known Project Management Triangle – scope, time, and cost – are all fixed. They don't have the ability to go over budget, and that's the most favorable outcome for both parties. First the scope must be defined; with the Client putting forth the product requirements. After that, the contractor will calculate the price and timeframe. This makes it easier for the project manager to control the process. The contractor will bear more risks, and the team maximizes the precision of their estimates. What's more, to a non-IT Client this approach can be more beneficial than hourly rate.
The main problem is that there is almost no flexibility for the Client. Flexibility becomes a necessity in midsized and large projects, which are under constantly changing business and technology conditions. Fixed price works well for small- and midsized projects that take on average up to 3 months: more documented requirements, less backend logic.
In order to understand how we make a fixed price project successful, let's take a closer look at the process.
How Does A Fixed Price Project Run?
1. A fixed price project is never started without fully documented requirements:
• Product specification, where all requirements are described in detail.
• UI/UX design – software product mockups ready for implementation.
• Acceptance criteria, which define what must be treated as a ready product. They may comprise: checklists of actions with expected results, selected test devices, supported browser and platform versions.
These requirements must either be created by the Client or elaborated together with the contractor, and then clarified and approved. When the scope is fixed, an estimate for development can be made. The Client and the contractor should know precisely what they want and come to an agreement on it.
2. After the requirements are elaborated and approved, the contractor receives an offer of implementation, which typically includes type of collaboration, goals, a fixed scope divided into milestones with indicated intermediate results, scheduling of work and payments, possible risks and ways of solving them, terms of acceptance, and procedure of work with change requests.
3. A pre-payment is conducted. Typically it amounts to 50%. The further payments are due upon achieving each milestone.
4. The result of each milestone is an intermediate product build with implemented features that is provided to the Client in order to track the progress.
5. Any change in requirements is handled via a change request – an additional agreement, created by the project manager. Mid-development changes affect scope and cost, and the team makes re-estimations, including them into the change request. Then it either gets approved and signed by the Client, or rejected, and the development goes according to the initial approval.
6. The penultimate milestone results in the alpha build with all the features being implemented. The team makes sure that the product works properly on a test server.
7. The final milestone is refinement and polishing. It results in the beta build (the final build). The product is put into the Client's actual work environment on a production server. The product starts its work with real users and real data.
8. After the Client is provided with the final build, the acceptance period begins. During this time, the Client checks the product according to the approved acceptance criteria and sends feedback to the contractor. The acceptance period usually lasts 5 days. If there is a bug on an approved test device, or a mismatch with the checklists is found, it is corrected by the contractor and the Client does not pay any additional costs. The time spent on these fixes is not included in the acceptance period.
9. After the test period is successfully completed, the contractor receives the final payment, sends the source code to the Client, receives feedback, and generally finalizes the project. Here the product may be deployed on the application store – as a separate operation at the Client's will.
This is how a Fixed Project is managed.
What Are The Possible Risks?
#1. Scope-related risks are carried by the Client. They can be resolved through the abovementioned Change Requests.
#2. The Client also bears the risks that concern third-party services, which have to work under certain approved conditions, defined by the Client in product requirements. The contractor should be aware of them from the beginning.
#3. Human risk factors are carried by the contractor. They can affect scheduling. In case a developer cannot perform their duties, the Client is warned, and a substitution is selected.
#4. Risks concerning third-party libraries, services, API, SDK, or other tools selected by the contractor for development, become the contractor's responsibility.
After the delivery, the Client (as the Software Product Owner) starts getting feedback, bug reports, suggestions of new features from users, and so on. The understanding of product functionality may change – it may as well be dictated by business and technology. Therefore, the Product Owner has two options: either to collect feedback and continue the iterative evolution of the product, or employ the team for minor updates and fixes (usually 10-20 hours per month).
Agile software outsourcing companies try to avoid projects with fixed price because situations can always change. Sometimes it's the Client's will, sometimes it's a technological necessity or a business condition. When there is trust between the Client and the contractor, iterative development of a complex product is an advisable solution. It's faster – no Change Requests and lengthy re-estimations. It shows the progress, since the Client receives intermediate builds upon each milestone anyway.
But what's most important, it allows changes and flexibility, and immediate reaction to any change on the market. The product's relevance is easier to maintain. Otherwise, if the Client's project fits well into the fixed price approach, it surely is the better way.
August 22, 2013
We have previously touched upon the issue of software project estimations, and why it's impossible to present a precise... more →
August 20, 2013
When you employ a software development company to implement your custom project, the first things you want to know is whether... more →
March 15, 2013
Setting a fixed price for a project seems to be a perfectly attractive decision for software owners. They know how much they... more →