Recently I was reading a discussion on Twitter about software projects, and it reminded me of something. Many years ago I had a conversation with my dad about moving. After just having moved, he wasn't too pleased with the moving experience. He mentioned that there was essentially two models that movers operated under. The first was you paid a fixed price for the move. I don't remember the exact details, but the movers quoted a price most likely along the lines the square footage of the house, or some similar metric. The other model, was simply to pay the movers for their time. If it took them 20 hours to complete the move, you paid for those 20 hours.
Now the catch was, as he described it, if you paid for a fixed price the movers didn't really put a lot of care into the move. They simply wanted to get the job done as quickly as possible. I seem to recall that if they broke something, they would reimburse you. However, that wasn't a pain free process. More importantly, nobody wants to have their things broken. In the other model, the movers would be extremely careful. The downside is that as they were paid for their time, so there was little motivation to move quickly. While they packed up everything securely, they moved so slowly that it was cost prohibitive. To generalize you had to choose to between a higher cost with better results, or a more reasonable cost and something that was not ideal but adequate.
The parallel with software is that traditionally most software projects work similar to the fixed cost moving model. That is to say there is an upfront cost assessment made, and based on that cost a fixed price is quoted. Now software is more complicated than moving, but the end result is similar. The customer pays a fixed price, and while they usually aren't delighted with the results in most cases they get something that's good enough. (In my experience most software projects tend to go a bit late, and there's also usually back and forth arguments over whether requirements were met, but in the end something is delivered.) To summarize it works, but it certainly isn't ideal.
What about the other option? Time and materials based software projects exists, although they aren't very popular. The reason being quite obvious; in most cases customers don't want an open ended project. The great thing with modern software development, which doesn't apply to moving, is there are more nuanced options.
Moving is relatively simple. You have either moved someone or you haven't. However, when it comes to writing software, things are more nuanced then that. For example, a client might come to you with an idea of what they want. However, what we often try to do is better understand their needs and help come up with something that suits those needs. Most often things change from their initial request to the realization of the vision. Sometimes the best approach isn't to build out the app with all envision features, but instead build an MVP to help the client quickly get feedback from their customers. The point is, software development isn't just about writing to a spec; it's a ongoing process to ensure that you're providing the best value for your clients.
The other great thing about how software is written today is that it is an iterative process. That is to say, you don't need a big upfront commitment. You can work in 2 week increments (for example), and at any point the client could decide it's not working for them. Of course you wouldn't go into the process expecting either party to back out, but that option is there if things start to go bad. It's definitely better then investing many months into a project, only to find out that it's not going well until the very end.
Fixed scope, fixed scope projects have their limitations, so it's great to look at other options. Unlike moving, in software we have a lot more flexibility when going with the higher quality option. Also, unlike moving, if the project is smartly managed, it can even end up costs less than the fixed price model. The reason being that once you get into a project, you may discover some of the things initially desired are no longer needed, and instead focus on what's really needed.
In summary, there's a lot more options than the tradition fixed scope, fixed price projects. While there will always be tradeoffs, alternate approaches may result in better results. While it does put more onus on the stakeholders to manage priorities and costs, the potential payoffs are much better.
Now the catch was, as he described it, if you paid for a fixed price the movers didn't really put a lot of care into the move. They simply wanted to get the job done as quickly as possible. I seem to recall that if they broke something, they would reimburse you. However, that wasn't a pain free process. More importantly, nobody wants to have their things broken. In the other model, the movers would be extremely careful. The downside is that as they were paid for their time, so there was little motivation to move quickly. While they packed up everything securely, they moved so slowly that it was cost prohibitive. To generalize you had to choose to between a higher cost with better results, or a more reasonable cost and something that was not ideal but adequate.
The parallel with software is that traditionally most software projects work similar to the fixed cost moving model. That is to say there is an upfront cost assessment made, and based on that cost a fixed price is quoted. Now software is more complicated than moving, but the end result is similar. The customer pays a fixed price, and while they usually aren't delighted with the results in most cases they get something that's good enough. (In my experience most software projects tend to go a bit late, and there's also usually back and forth arguments over whether requirements were met, but in the end something is delivered.) To summarize it works, but it certainly isn't ideal.
What about the other option? Time and materials based software projects exists, although they aren't very popular. The reason being quite obvious; in most cases customers don't want an open ended project. The great thing with modern software development, which doesn't apply to moving, is there are more nuanced options.
Moving is relatively simple. You have either moved someone or you haven't. However, when it comes to writing software, things are more nuanced then that. For example, a client might come to you with an idea of what they want. However, what we often try to do is better understand their needs and help come up with something that suits those needs. Most often things change from their initial request to the realization of the vision. Sometimes the best approach isn't to build out the app with all envision features, but instead build an MVP to help the client quickly get feedback from their customers. The point is, software development isn't just about writing to a spec; it's a ongoing process to ensure that you're providing the best value for your clients.
The other great thing about how software is written today is that it is an iterative process. That is to say, you don't need a big upfront commitment. You can work in 2 week increments (for example), and at any point the client could decide it's not working for them. Of course you wouldn't go into the process expecting either party to back out, but that option is there if things start to go bad. It's definitely better then investing many months into a project, only to find out that it's not going well until the very end.
Fixed scope, fixed scope projects have their limitations, so it's great to look at other options. Unlike moving, in software we have a lot more flexibility when going with the higher quality option. Also, unlike moving, if the project is smartly managed, it can even end up costs less than the fixed price model. The reason being that once you get into a project, you may discover some of the things initially desired are no longer needed, and instead focus on what's really needed.
In summary, there's a lot more options than the tradition fixed scope, fixed price projects. While there will always be tradeoffs, alternate approaches may result in better results. While it does put more onus on the stakeholders to manage priorities and costs, the potential payoffs are much better.
Comments
I like your ideas here. And I can tell you it is actually how we always promotes working with our customers.
Having worked like this, I have one comment regarding this:
"in most cases customers don't want an open ended project"
Yes and no. As I said, we always promotes working with an open price. Just like the movers. The benefit of obvious: you pay what it costs, nothing more nothing less. When on fixed price, someone always "lose". What I mean is that for fixed price you always add risk. That is you pad the price so you don't end up losing money if things takes longer than expected. But if things doesn't take longer, the one paying has paid an "overprice" actually. But not that seldom things takes even longer even with the risk padding included. Then the one doing the job still loses money.
Thus, open price is more "honest". But there's a catch. *No one* wants to go "cart blanche". When you hire movers, you want a rough idea of cost. Same goes for software.
The way we have "solved" that is by using thresholds. Or call it "shared risk". We have an open price up to a limit, after that it's half the price up to another limit, after that is on us.
This has often resulted in customers paying less than they thought and it has resulted in the opposite. Quite seldom we go half the price and almost never we reach the free limit. Our customers are usually happy with this approach. At least when we tell them what it could've cost if we gave them a fixed price.
So I don't agree that fixed price is cheaper. Then you're probably doing it wrong (added too little risk padding). In my experience, open price is cheaper for the one paying. But no one accepts a full cart blanche. You wouldn't either (when eg hiring a mover).
Kind regards
If I understand correctly, your company still needs to provide a cost estimate at the start of the project. This would seem to imply that the scope needs to be known at the start the project, in order to try to predict the cost. (Perhaps a range is provided for the cost, but that still requires an understanding of the scope.) A potential downside I see here is that both entities are basically locked in to this scope/price commitment. This results in a loss of flexibility, especially if the duration of the project is more long term. In contrast a more open ended commitment allows for your and your client to quickly respond to change, such as a new competing product.
In regards to your comment about the fixed price being cheaper, that was a reference to moving. While some will assume that is also the case for a software development project, I agree that the more open commitment can actually be the cheaper option.
Thanks again for commenting!
Yes, we give a cost estimate at the start. That doesn't mean that we "lock" the scope or that everything is known - it's a dialogue. And since price is open they are free to add/remove things and we can also "influence" changes when we discover things - it's a dialogue. But adding things aren't free either, it isn't possible to squeeze in everything, better to keep things simple to start with - it's a dialogue.
But again, we don't lock anything. That seems unwise. Unless there's a date we must have things ready before, or if client has a restricted amount of money. Then we have to lock the cost/time and thus flex the scope.
But again, no one wants to go cart blanche. At least I've never experienced it. Have you?