"We want an agile project approach - but with a fixed price!" Do you know this situation? You want an agile project approach, but you feel safer with a previously mentioned fixed price than starting with a vague price range? The problem of the matter is the demand for an agile methodology and a fixed price contradict each other. How can an agile price combine both approaches?
Estimating software projects is very complex and only about ten percent of the requirements are clear in the planning phase. In order to be able to call a fixed price, however, it is necessary to have a complete and detailed description of the product as well as the complete requirements exactly in front of you. Thus, the estimated price can never cover the final product, as some requirements change over the course of each project.This leads to the problem that the specifications can hardly be defined, which services - especially unforeseen change requests -, are actually included in the fixed price and which are not. If there are changes in the scope that are not clearly defined, this will have a massive negative impact on the course of the project. Because who will pay for the costs of change requests? If these points are ambiguously defined in the planning, this weakens the relationship between customers and suppliers, as both defend their budgets.
Fixed prices often lead to higher costs at the end of the project due to change requests
Our clients tell us about previous projects that exceeded their budget or deadline, did not include essential functionality, did not achieve the desired business value, or they simply did not accept the product. An agile transparent pricing model counteracts from the very beginning and allows maximum customer satisfaction and maximum project efficiency.
How can you value a project if I do not know all the requirements yet?
The goal of agile pricing is to determine a price that is attractive and understandable for customers. The agile prize will be elaborated jointly by both sides as part of a goal-oriented workshop. This includes the analysis of the main requirements and these are usually only roughly described at the beginning of the project.
Many more ideas for the product are not yet completely planned in detail at the time and exist only as epics. An appendix to the classification of requirements into effort can be used to produce initial estimates. Thus, the workshop can set an order of magnitude for existing requirements that will serve as the foundation for the further requirements that will become more concrete during the project. (Read more about Magic Estimation)
Agile project management enables a cost-effective and transparent final price
It is important to keep in mind that the reference value of the first order of magnitude must be regularly adjusted in terms of team velocity and technical challenges. Why is that necessary?
Epics and user stories may turn out to be more complex or simpler during the development than are assumed in the planning process. Thus, the actual effort, the time and the budget are regularly checked and monitored by effective agile controlling. (Read more about Agile Project Controlling)
Therefore, it is possible that the price at the end is lower than the first mentioned fixed price.
It is possible that the agile price is much lower than the initially estimated fixed price
Agile project management is based on the estimation and planning of the requirements known at the start of the project. Agile estimation methods allow a very good estimation of the project plan with rough requirements. Not all features need to be explained in detail to create an agile project plan. This knowledge is constantly increasing as the project progresses, so information about effort and costs is becoming more and more accurate.
In addition to the project costs due to the main requirements, technical uncertainties must also be taken into account. For example, internal processes (Do you need time to schedule firewall clearing, database activation, and collaboration with other IT teams?), The IT environment (Do you need to prepare and customize them?), internal and external interfaces, their requirements, and stability levels as well as documentation.
When working in a new business, how much time do you have to spend to apply specialized domain knowledge to proactively generate the best features and intelligent content? Do not forget to include time for the initial setup, your individual test strategy or CI / CD. It is important to design quality assurance as a transparent factor of the project plan. How long does the data migration take and does an internal or external team do this? In addition, how much work do you plan for user experience and frontend requirements?
Fixed price contract models include a high risk uplift to cover inaccuracies and unplanned dynamics
A fixed price includes a high risk uplift that covers not only these inaccuracies, but also changes and dynamics – no matter if they appear or not. Signing a fixed price contract has one essential condition: It´s very important to define clearly what will be delivered and what will be still out of scope.
Fixed price contract models don´t necessary guarantee the best price
A project might look successful but to meet the deadline within the budget it´s often necessary to reduce the scope or simplify requirements. In the end, the result may not have the desired quality, although it met the deadline. Those reductions and simplifications of requirements can lead not only to a loss of quality but also to harm the mutual trust between customer and supplier.
An agile price for "time and material" with precise controlling leads to the optimal solution
An agile price in the form of an iterative pricing model is a transparent and fair solution based on time and material. Therefore, a transparent and clear controlling is essential. Qualysoft provides detailed monitoring about all efforts and time to have full control about the current project status all the time.