A successful software project does not only adhere to time and costs. The provided solution should be accepted by users and should bring a great added value. Does this requirement sound familiar to you?
Described differently – be agile but please at a fixed price. This inevitably raises the question: How should the whole thing work? A contract with a fixed price needs precise definitions of what needs to be delivered. The tendency is to have many pages of specification, but these are outdated after a few months of implementation in a software project at the latest. Without precise requirements, a contract again feels more like a blank check, with never-ending effort.
There are a few points that play an important role in agile fixed price projects. To anticipate – yes, agile fixed price projects are indeed possible.
Trust as a basis
No matter how much is in a contract, in the end, people work together. If the cooperation does not work, the result will not save any specification in a contract. A fixed price does not automatically reduce the risk. On the contrary, it can end in tedious change requests and discussions about small changes.
The basis is open communication from the first meeting. If the customer and provider cannot talk transparently about procedures, backgrounds and goals, no joint projects should be started. One possibility is to start with small projects in order to build trust, see if ideas match and continuous progress is visible. Then adapt project teams to the needs in order to develop large solutions together.
Cost cap and easy exchange
The agile fixed price project needs sufficient flexibility to deal with problems and changes. This should not be a free ticket for an endless budget. An upper limit is agreed with a cost cap. Within this limit, a solid basis with the core functionalities is first developed. In this way, a provider guarantees that the basic problem is solved. Subsequent functionalities are estimated transparently and discussed openly. Thus, a function block can be exchanged for another one in priority or even omitted at any time if a function block is no longer relevant.
The challenge lies in a structured approach. Focusing on the critical functionalities at the beginning is easier said than done. This also includes rejecting functionalities, even if they seem very useful at that moment. The end result should be a fair solution for both sides – for customer and provider.
It depends upon the need
Everyone defines a project success differently. It is therefore important to clarify expectations and clearly define what is to be achieved with the project. This will determine what added value the software provided will bring, rather than defining what the solution will look like.
If there is a need to get from A to B quickly, there is no need to specify the colour of the car. Not even that it should be a car. When the need to be solved is fixed, it is important to quickly develop a first version of the solution to the problem. After that, further optimisation can be made continuously. This is the only way to respond to feedback and changes during the development period. In the end, a motorboat may come out which covers the needs of the users much better than the originally assumed car.
Result: fixed price, agile way
An agile fixed price project is not a contradiction and works very well if the customer and provider stick to certain rules.
A price is fixed as an upper limit. The provider transparently communicates the effort and estimates of functionalities so that the project can be successfully implemented within the set framework. Functionalities that do not contribute to the set goal are postponed to later projects.
The contract defines which problem or need is solved. Mandatory criteria are defined as goals for the implementation project. How the solution is implemented is continuously elaborated and optimized based on feedback.