Software development always costs more than you think in advance. Why is that?
In his book “Clean Agile” Robert C. Martin explains in an appealing way that this can be traced back to industrial thinking; through analysis and design you know exactly what you are going to build. The idea is that through all the knowledge, experience and scientific insights, you are guaranteed to get the result you want. And good, and cheap, and fast, and complete.
Martin calls this the “Iron Cross of (project) management”. He explains that this does not work for software development. At best, you can get three out of four with this approach. And that’s because people don’t know exactly what they want. Broadly speaking, they know what problems they want to solve, but translating that into a system is not easy. That’s why requirements are constantly reevaluated and reconsidered during the build. New features are added and old ones removed. The user interface changes weekly, if not daily.
In a software project, it is therefore better to assume good enough, fast enough, cheap enough and as much as can be done. My claim, therefore, is that a fixed-price software project never produces the best results. In fact, you’re always fooling someone. Either the developer goes completely wrong and it costs him a lot of money, or the customer at the end of the project is frustrated and/or spends a lot more money and time than expected. If both the customer and the developers understood the principles of Agile, I am convinced that many more software projects would be successful.
Software development always costs more than you think in advance. Why is that?
In his book “Clean Agile” Robert C. Martin explains in an appealing way that this can be traced back to industrial thinking; through analysis and design you know exactly what you are going to build. The idea is that through all the knowledge, experience and scientific insights, you are guaranteed to get the result you want. And good, and cheap, and fast, and complete.
Martin calls this the “Iron Cross of (project) management”. He explains that this does not work for software development. At best, you can get three out of four with this approach. And that’s because people don’t know exactly what they want. Broadly speaking, they know what problems they want to solve, but translating that into a system is not easy. That’s why requirements are constantly reevaluated and reconsidered during the build. New features are added and old ones removed. The user interface changes weekly, if not daily.
In a software project, it is therefore better to assume good enough, fast enough, cheap enough and as much as can be done. My claim, therefore, is that a fixed-price software project never produces the best results. In fact, you’re always fooling someone. Either the developer goes completely wrong and it costs him a lot of money, or the customer at the end of the project is frustrated and/or spends a lot more money and time than expected. If both the customer and the developers understood the principles of Agile, I am convinced that many more software projects would be successful.