Creating working software is relatively easy. Creating high quality software that exceeds expectations is hard. In my last two blog postings I've discussed the challenges of managing software projects, in particular when dealing with external customers. On the one hand a customer wants to know how long a project will take and how long it will cost. On the other hand we simply don't have accurate ways to measure how long a project will take, due to all of the variables involved. One can try traditional project management techniques to pretend to know how long a project will take, or one can use agile techniques which don't lend themselves to determining the cost all up front.
I fully understand why a customer wants to know how much something will cost. When I go to my mechanic with a problem, they provide me with an estimate of what they think is wrong and how much it will cost. Of course once they pop the hood and start working they often find unexpected issues, and they call to notify me. Fortunately for me, I've found a good mechanic that I've been using for years so I trust what they tell me. Nothing has seemed unreasonable, and the times I've done my own investigation into the issue what they tell me is in line with that. After they have worked on the car, it's always comes back with the problem fixed. Sure, it's possible they are taking advantage of my trust, but they are well known in the area as a trustworthy shop so I take them for their word.
Coming back to the world of software, it's often a much more complicated situation. Most times a customer has a rough idea of what they want, and it will evolve over time as they see the software come to life. Priorities change, ideas evolve, and complexities are discovered. Now if you've developed a similar piece of software for your last five customers, there's going to be a lot more certainty. However, in my experience you're rarely asked to develop cookie cutter solutions. Customers are coming to you because they want something special and unique. (If they are looking for something cookie cutter, they'd be better off using a common platform then having something custom developed for them.)
Another analogy that I like to use is products versus services. If I buy a product off the shelf, I'm of course going to expect to know the cost. If I customer order a Lamborghini, even though it's a custom order they are using an existing blueprint, common parts, and it's something they have done before, so they can quote me a price. However, if I walk into a law firm for a court case they can tell me their rate, but they can't promise me how long it will take. They might provide a very rough guess, but even then there are no expectations that they will be held accountable to that guess. They are simply providing a service and not building a product.
The reality for the vast majority of the software development that is built, even though there is a finished "product", everything that goes into making it is more like a service. Working with a customer to understand needs, makings changes as you go based on feedback, these are all things that are flexible and evolve as the software is built. I'd even argue that software projects don't have a true end. Even after a solution is deployed there's ongoing maintenance, enhancements, and even monitoring and analysis. The real end to a system is once it is no longer used, which can often be many years (even decades) after it is first deployed to production.
Yes, the idea of not providing an up front cost can be a hard sell. Currently the common line of thinking is one must know the cost before they can commit to a software project. However, there are few things in life with such certainty. Even in the business world lots of decisions are made without certainty. Forecasts are made, investments are planned, and budgets are dedicated to marketing, yet there's no certainty on the returns. We think things will work so we try them, and if our decisions were wrong we reevaluate and make new decisions. If there was no risk involved, there would be no reward at the end.
I pick my mechanic because I trust them. After a long search I've finally found a doctor that has my best interest in mind and I trust with with my health. Law Firms and other businesses are chosen because of their reputations. My boss doesn't stand behind me all day to ensure that I get work done. It's because trust is a fundamental part of business and life as a whole. Sure, we like to minimize risk when we can but the reality is that it exists no matter how careful we are.
When it comes to software, contracts might help with a false sense of security. But what does it really guarantee? I've worked on many fixed date, fixed price contracts. Usually the end result was that 80% into the project a lot of rushing and less than idea compromises were made to meet those deadlines. Often at the end there would be squabbling with the customer over wether certain expectations were met. A contract is not going to ensure that customers like the product; it just ensures that something will be delivered. Even then there's no certainty; some companies won't deliver and you're now stuck with a contract, software that doesn't work, and a whole lot of wasted time and energy
If it were my product, I'd pick quality over false sense of security. If a mediocre product if good enough, than perhaps focusing on a contract is a way to go. However, if you're more concerned about quality and the success of the product then perhaps that's the wrong way to look at things. Yes, it would be nice to know for sure that it would all work out. But in life there's no certainties. By simply accepting this reality, you can spend your time on what really matters; the product. Find a partner that will work with you, that you can trust, and you're more likely to have a positive result.
I fully understand why a customer wants to know how much something will cost. When I go to my mechanic with a problem, they provide me with an estimate of what they think is wrong and how much it will cost. Of course once they pop the hood and start working they often find unexpected issues, and they call to notify me. Fortunately for me, I've found a good mechanic that I've been using for years so I trust what they tell me. Nothing has seemed unreasonable, and the times I've done my own investigation into the issue what they tell me is in line with that. After they have worked on the car, it's always comes back with the problem fixed. Sure, it's possible they are taking advantage of my trust, but they are well known in the area as a trustworthy shop so I take them for their word.
Coming back to the world of software, it's often a much more complicated situation. Most times a customer has a rough idea of what they want, and it will evolve over time as they see the software come to life. Priorities change, ideas evolve, and complexities are discovered. Now if you've developed a similar piece of software for your last five customers, there's going to be a lot more certainty. However, in my experience you're rarely asked to develop cookie cutter solutions. Customers are coming to you because they want something special and unique. (If they are looking for something cookie cutter, they'd be better off using a common platform then having something custom developed for them.)
Another analogy that I like to use is products versus services. If I buy a product off the shelf, I'm of course going to expect to know the cost. If I customer order a Lamborghini, even though it's a custom order they are using an existing blueprint, common parts, and it's something they have done before, so they can quote me a price. However, if I walk into a law firm for a court case they can tell me their rate, but they can't promise me how long it will take. They might provide a very rough guess, but even then there are no expectations that they will be held accountable to that guess. They are simply providing a service and not building a product.
The reality for the vast majority of the software development that is built, even though there is a finished "product", everything that goes into making it is more like a service. Working with a customer to understand needs, makings changes as you go based on feedback, these are all things that are flexible and evolve as the software is built. I'd even argue that software projects don't have a true end. Even after a solution is deployed there's ongoing maintenance, enhancements, and even monitoring and analysis. The real end to a system is once it is no longer used, which can often be many years (even decades) after it is first deployed to production.
Yes, the idea of not providing an up front cost can be a hard sell. Currently the common line of thinking is one must know the cost before they can commit to a software project. However, there are few things in life with such certainty. Even in the business world lots of decisions are made without certainty. Forecasts are made, investments are planned, and budgets are dedicated to marketing, yet there's no certainty on the returns. We think things will work so we try them, and if our decisions were wrong we reevaluate and make new decisions. If there was no risk involved, there would be no reward at the end.
I pick my mechanic because I trust them. After a long search I've finally found a doctor that has my best interest in mind and I trust with with my health. Law Firms and other businesses are chosen because of their reputations. My boss doesn't stand behind me all day to ensure that I get work done. It's because trust is a fundamental part of business and life as a whole. Sure, we like to minimize risk when we can but the reality is that it exists no matter how careful we are.
When it comes to software, contracts might help with a false sense of security. But what does it really guarantee? I've worked on many fixed date, fixed price contracts. Usually the end result was that 80% into the project a lot of rushing and less than idea compromises were made to meet those deadlines. Often at the end there would be squabbling with the customer over wether certain expectations were met. A contract is not going to ensure that customers like the product; it just ensures that something will be delivered. Even then there's no certainty; some companies won't deliver and you're now stuck with a contract, software that doesn't work, and a whole lot of wasted time and energy
If it were my product, I'd pick quality over false sense of security. If a mediocre product if good enough, than perhaps focusing on a contract is a way to go. However, if you're more concerned about quality and the success of the product then perhaps that's the wrong way to look at things. Yes, it would be nice to know for sure that it would all work out. But in life there's no certainties. By simply accepting this reality, you can spend your time on what really matters; the product. Find a partner that will work with you, that you can trust, and you're more likely to have a positive result.
Comments
Many of your examples, while possible to find, are examples of Bad Management.
Assume there is Good Management.
The example of the car is the "price" of the car, not the "cost." The cost is known by the manufacture and the difference - minus all the other expenses is profit.
The paradigm of "for profit business" - for non-trivial business - requires we know something about the cost to produce the products or services that we sell for a price. Since these costs are for the most part in the future, and are themselves probabilistic, we can only make decisions about the choices around these by making estimates of all the elements of the product or service.
The issues of estimating or not estimates are raraly in the hands of those on the "cost" side of the balance sheet. The Developers are on the cost side of the balance sheet.
Those providing the money to be consumed by the developers have a fiduciary objective to the investors or funders of the firm to know something about the future cost, revenue, retained earnings from expending that cost. Since this is in the future, and estimated cost, revenue, and retaied earnings needs to be made.
This is NOT about the developers, it's about the business of managing in the presence of uncertainty and the MicroEconomics of making decisions in the presence of this uncertainty.
I also understand that a business needs to make plans. What I'm advocating for is that business focus more on the value side of the equation as opposed of the cost side. It's easy to cut cost ... but often it comes with a price that is less tangible; the quality of the product.
One final thing. Perhaps I could have been clearer but topic of the article has to do with working with external customers. Often there are very tight margins, as multiple companies bid on the project. Usually the lowest bid wins, so there's often not much wiggle room to work with for padding or anything unexpected. That's why I'm suggesting that a services based approach is best for both parties. It doesn't work in every situation, but in many situations it works best. I have seen this in real world projects, and it's great when companies can just focus on getting the job done, and doing it right.