- Type Three Error
- Posts
- Feasibility vs Viability
Feasibility vs Viability
How to define your problem space
Last week I walked through a detailed example about placing a grocery order. We can consider many options of what might be a reasonable alternative if your order could not be filled exactly. We covered someone who decided to have lasagna for dinner and ordered a take & bake lasagna, versus someone else who orders the ingredients to make it themselves.
I like thinking about the alternatives because it gives a richer perspective on the problem you are facing. If there was a stockout, is the true problem statement “I need this exact food” or is there some other version of the problem statement that better captures my needs? Usually there is more than one viable solution to my problem, but unless my favorite choice is unavailable, it almost doesn’t matter.
There are two similar ideas that touch on this idea. I already mentioned one: the concept of viability. For a solution to be viable, there is some sense that it has to be an option I would consider. If I had a choice between paying $1 for something or I could pay $20 for that same thing, the first option is a no brainer. There is no way I would seriously consider paying 20 times as much for something because… well, for no reason. Viability really depends on context though. If I have the option to buy a one-of-a-kind piece of art and the price tag happens to be $1000, the only viable way to get that artwork is to pay the price.
The other related idea is the concept of a “feasible solution.” A feasible solution meets all defined constraints and limitations. If I want lasagna for dinner, a feasible solution meets that need. If I am unwilling to spend more than $10 for lasagna? Well, a feasible solution would need to meet that constraint too.
Interestingly, these two ideas can diverge significantly depending on the situation and how you write down your problem. A couple posts back I wrote about putting less of your problem statement into the constraints and more of it into your goal. If you followed my advice, you might end up with almost no constraints and only a multi-criteria goal guiding you. That would make the set of feasible solutions huge. Viability on the other hand might be a much more limited set of alternatives.
This means the set of feasible solutions to a more constrained problem statement might look a lot more like viability for a generous problem statement. Like so much of what I like to write about, that means we are considering different problem framings for a problem. Is it better to keep your constraints loose and assess viability, or make them more strict and consider the whole feasible region?
Like many posts in this series, I like viability because it opens the door for the softer discussion of tradeoffs. When I was teaching a systems engineering class I had a homework problem which said that your stakeholder had set a budget of $20,000 for a new car and asked if you should consider a vehicle that costs $20,001. About a third of my students thought the answer was no. It exceeded the constraint and therefore should be thrown out as a possibility. This is the feasible region view of the problem.
Viability wise, would anyone really say that option should be thrown out? What if the car dealership throws in a free cup of coffee, can we consider the “over budget” option then?
One other note for consideration, sometimes you do need to rule out some solutions that seem like they should be viable, but they are not. Being able to push the question (but not too far) and then gracefully accept defeat is important if you want to put this theory in action.
Reply