![]() |
|
|
|
Cars & Coffee Killer
Join Date: Sep 2004
Location: State of Failure
Posts: 32,246
|
Business Project Lessons
Some thoughts I had bouncing around today...
Most business problems don't have a 100% solution, but those that do are usually very simple. I can build you a 70% solution for $X. I can build you a 90% solution for $2X. I can build you a 95% solution for $3X. I can build you a 97% solution for $4X. I can build you a 98% solution for $5X. I can build you a 98.5% solution for $6X. You get the idea. 100% is usually an asymptote and it gets more expensive the closer you get. Whenever I hear "always" or "never" when doing project requirements, it sends a red flag. When a person says "always" or "never", what they really mean is: "Except in cases I haven't thought about or I assume you already understand." It's best to drive out these exceptions during requirements, not design and not when you are building the thing. A 70% solution is usually a good choice for a small business. They can deal with the other 30% with internal procedures and probably won't see the ROI on paying for a more expensive solution. A 90% solution is usually a good choice for a medium-sized business. They can deal with the other 10% with internal procedures and probably won't see the ROI on paying for a more expensive solution. A 95% solution is usually a good choice for a large business. A 97% solution may even be economical for a very large business. Their scale means they can see ROI where smaller competitors do not. If your project is doing some sort of iterative process (like agile), you won't get any benefit unless you revisit requirements after each iteration. You should be adding new requirements, dropping those that no longer make sense, and reprioritizing all of them. It's okay if you end up with something completely different than you intended to start with as long as it addresses the business problem better.
__________________
Some Porsches long ago...then a wankle... 5 liters of VVT fury now -Chris "There is freedom in risk, just as there is oppression in security." |
||
![]() |
|