What is Agile Fixed Price

The agile fixed price is a contract model for suppliers and customers in IT projects that are carried out using agile methods. The contract model stipulates that after an initial test phase, costs and deadlines are set and a procedure for controlling the scope is agreed upon within a fixed framework.

Classic fixed-price projects strive for an accurate, detailed description of the subject matter of the contract right from the start of the project. The risk of subsequent changes should thus be kept as low as possible. On the other hand, the agile fixed price at the start of the project strives for a complete, but not yet detailed description of the subject matter of the contract.

Instead, supplier and customer make joint assumptions regarding the business value, implementation risk, effort and costs. Based on these assumptions, an indicative fixed price framework is agreed upon, which is not yet binding. This is followed by a test phase (checkpoint phase), in which the implementation already begins. At the end of this phase, both sides compare their experience with the initial assumptions. They decide on the implementation of the overall project and determine the conditions under which changes may take place. Other components of the agile fixed price are the sharing of risks, i.e. both parties bear the additional costs for unplanned changes and the possibility for both parties to exit at any time (exit points).

Steps/Process of Agile Fixed Price

In the first step, the subject matter of the contract is described on a rough level. This includes the main project objectives, themes, software requirements and epics. The legal framework is also negotiated and agreed upon at this point.

Subsequently, an epic representative of the project is selected and specified down to the level of user stories. With a suitable epic, a sufficient number of user stories of different types and with different functions are created, which may be regarded as reference user stories.

In the workshop, the supplier and customer then determine the expenses for the entire project based on the reference user stories, the other epics and with the help of story points. Assumptions regarding implementation risk and business value are also estimated. This results in an indicative fixed price framework, which is not yet contractually binding and will only be fixed in a later step (namely at the end of the checkpoint phase).

In the fourth step, the checkpoint phase is defined, which is considered a test phase for the cooperation, as implementation is already being started there and the first empirical findings are being gained. A length of between two and five sprints is recommended (with a sprint length of two weeks). At the end of the checkpoint phase, the customer and supplier review the initial assumptions and decide whether they want to implement the overall project. The initially indicative fixed price framework is then also contractually binding. In the checkpoint phase, the distribution of risks is also agreed upon, which determines the extent to which costs incurred are charged to the customer if the maximum price range is exceeded.

In addition, the roles responsible for the management of the project must be named and filled. This includes the product owner on the customer side and the project manager or scrum master on the supplier side. In addition, it is recommended to have an independent IT expert selected by mutual agreement by both parties. From these roles, a steering committee emerges as a decision-making authority that meets regularly and ensures that the continuous specification process works and that the highest prioritized requirements are defined as user stories.

In contrast to classic fixed-price projects, the agile fixed price ends the project when the customer considers the expected benefit from the deliveries already made to be fulfilled. This may well occur before all agreed functionalities have been delivered. For this flexibility to be advantageous for customers and suppliers, agreements must be made. For example, the supplier can receive a percentage of the price of the remaining scope or be assured of a new order in the value of the remaining volume.

Criticism

The success of this contract model stands and falls with the first and last process step:

The “description of the main project objectives” and
the “termination of the project when the customer considers the expected benefit from the deliveries already made to be fulfilled”.

In most cases, the mistake is made not to define the project goal by quantifiable quality characteristics (such as “Reducing the costs of a certain workflow by a certain value” would be a quantifiable goal). Instead, vague definitions are used for the goal (e.g. “ideal and comprehensive support of a workflow”) that are not objectifiable. Or the goals defined in the first step only repeat the functionally assumed scope of the solution (e.g. “all functions must be implemented comprehensively”).

This causes major problems, especially in the last process step, when the “expected benefit” is to be evaluated as a criterion for the end of the project. Since the goal is not quantifiable, only subjective ad-hoc assessments can take place, which almost always leads to disputes between client and supplier. It is often forgotten to define what happens if the desired goal turns out to be unattainable, which is quite possible with complex IT projects.

Vaguely defined project goals lead to problems even before the desired end of the project: They prevent the ongoing prioritization of the functions according to expected benefits since its achievement (= the project goal) cannot be quantified. Likewise, the implementation of complex IT projects requires so-called “safe-to-fail experiments” (e.g. spikes or releases of partial functionalities), for which quantifiable goals are also required as evaluation criteria.

The agile fixed price is particularly suitable as a contract model for complex IT projects in which the scope, course and costs are difficult to predict. When it comes to standardized projects that have already occurred in the same or similar form, the test phase customary in the agile fixed price and the joint review of the project progress can be superfluous. The success of the contract model presented here also requires that the supplier and customer are prepared to cooperate closely over the entire duration of the project. A certain degree of mutual trust is also essential to enable agreement on costs, effort and functionality. It is also important to ensure that the very rough requirements (epics) that are worked with at the beginning are broken down into smaller, manageable requirements (user stories) as soon as possible. Otherwise, there is a risk of too much uncertainty and the associated risks.