At Aava, we are committed to delivering our projects on a fixed price model. Intuitively, this sounds like the only right model from the customer’s point-of-view, but it becomes less so obvious, if the solution provider is performing its work using traditional development tools.
Fixed pricing problems with traditional development methods
Fixed pricing system delivery project is absolutely the best solution for the customer, provided that the customer gets for the fixed price what he imagined getting when signing the agreement. The model turns problematic when the solution provider works using old development methods and hasn’t been able to estimate the delivery work effort correctly. This might end up in the system not being ready for delivery when the project costs allocated by the vendor are full. As a consequence, the vendor doesn’t necessarily have an interest to finalize the delivery, because after reaching the allocated work estimates, the remaining work becomes pure cost. In the worst scenario, the errors done in work estimation are so great that the vendor simply cannot finalize the project work profitably.
A more typical model has traditionally been a one in which the project delivery has a certain base price including certain amount of project-related work. Work to be done after that is priced by the hour, or by man day, and the customer has no certainty as to how much the delivery will end up costing at the end. The problematic issue in this model is that the vendor has no real incentive to do its best; the vendor makes the best profit by making the worst possible work, by working for as long as possible, and with as cheap as possible resources.
The Aava way
With Aava – technology, it is possible to provide a truly fixed price – project without risking that the solution provider wouldn’t be able to complete the delivery profitably. This is based on Aava having been able to standardize all business logic-related abstraction concepts – meaning data management fundamentals – to the degree that in project deliveries there is no need to re-learn to do new things, and everything can be completed by repeating the same logic. The required work in a project delivery is significantly reduced compared to traditional methods, and the work estimates can be given with much greater accuracy. In addition, the technology enables such a good productivity that the acquisition cost for the customer can be made reasonable. Yet, the pricing leaves enough of a buffer, allowing for the inevitable surprises to remain under the vendor’s projected cost level.
The construction industry realized the same a long time ago
The construction and building industries are way older than the software industry. They realized the same issues a long time ago and today, practically all larger building projects are completed with fixed pricing models. If, for example a house would be build by the hour and with an open tab, the results would be very similar to traditional software deliveries. The constructor’s interest would be to provide the worst work possible, do it for as long as possible, and with cheapest possible resources. The work would hardly ever be completed.