A Mandate to Be Cheap
-
@Dashrender said in A Mandate to Be Cheap:
@coliver said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@scottalanmiller said in A Mandate to Be Cheap:
@DustinB3403 said in A Mandate to Be Cheap:
The term cheap to me (and I think others) means it needs to perform to the level that we can still run production (or whatever the use case is) and save more money than what we may have been proposed before.
That's an undefinable definition. Cheap but not the cheapest, good but not the best for us. So not the best option for the business, but not recklessly cheap. How do you make decisions around that? How do you decide what is "cheap enough" while being "not so bad" but not just choosing "what is best for the financial interest of the business?"
I'm seriously, without a clear definition but also without the goal of doing what is right for the business... what's the motivator for this? What makes something the lesser choice, but good enough?
Isn't part of being the best solution also having the lowest cost while still getting all of the needed items from that solution?
Right, but cheap denotes that you are making sacrifices that would stop you from getting the best solution for you business. At least to me it does.
So can it be cheaper and still solve the problem and not be the best?
Xen Orchestra from the sources is as cheap as it gets (because of the functionality of it). Meaning that you download the XO Update Script, and have all of the functionality, and capability of XOA, but at a literal $0 price point.
The fact that XO by it's self is disposable, and recreated in minutes.
Not that I don't love @olivier for the work he's created, but the source option is literally the best choice for this business.
-
@Dashrender said in A Mandate to Be Cheap:
@DustinB3403 said in A Mandate to Be Cheap:
A business owner should understand the value of the people they have employed. Without understanding that, the owner would look around and immediately think everyone employed by them is there to rob from them.
Of course they should but you can read countless encounters where they don't. Hell, I think you've given some of those points from time to time.... i.e. you're dealing with learning XO instead of just purchasing a know good working backup product. Of the fact that your company won't shell out the $900/yr for XOA which would keep you from having to jump through hoops to keep XO updated manually, etc.
$900/yr is a LOT, though. In a five year solution, that's $4,500. If you earn $90,000/year that's $450,000 during that window. Which is exactly 1% of your time for XO.
1% of a 40 hour IT guy is 104 hours during that time. That's a LOT of hours for maintaining a single application. It's very, very easy for a shop to support XO for that long with far less time than that. And it's not like XOA uses zero time itself. Only the delta between the two needs to be 104 hours.
And if you have staff that is idle and/or earning less than 90K or works more than 40 hours a week.... the numbers skew towards the free solution quickly.
-
@DustinB3403 said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@coliver said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@scottalanmiller said in A Mandate to Be Cheap:
@DustinB3403 said in A Mandate to Be Cheap:
The term cheap to me (and I think others) means it needs to perform to the level that we can still run production (or whatever the use case is) and save more money than what we may have been proposed before.
That's an undefinable definition. Cheap but not the cheapest, good but not the best for us. So not the best option for the business, but not recklessly cheap. How do you make decisions around that? How do you decide what is "cheap enough" while being "not so bad" but not just choosing "what is best for the financial interest of the business?"
I'm seriously, without a clear definition but also without the goal of doing what is right for the business... what's the motivator for this? What makes something the lesser choice, but good enough?
Isn't part of being the best solution also having the lowest cost while still getting all of the needed items from that solution?
Right, but cheap denotes that you are making sacrifices that would stop you from getting the best solution for you business. At least to me it does.
So can it be cheaper and still solve the problem and not be the best?
Xen Orchestra from the sources is as cheap as it gets (because of the functionality of it). Meaning the XO Updater script, the capability to install it in a matter of minutes.
The fact that XO by it's self is disposable, and recreated in minutes.
Not that I don't love @olivier for the work he's created, but the source option is literally the best choice for this business.
is it? Could you spend the time you spend updating XO doing other things that are more valuable to the company? Maybe? Maybe not?
-
@Dashrender said in A Mandate to Be Cheap:
@scottalanmiller said in A Mandate to Be Cheap:
@DustinB3403 said in A Mandate to Be Cheap:
The term cheap to me (and I think others) means it needs to perform to the level that we can still run production (or whatever the use case is) and save more money than what we may have been proposed before.
That's an undefinable definition. Cheap but not the cheapest, good but not the best for us. So not the best option for the business, but not recklessly cheap. How do you make decisions around that? How do you decide what is "cheap enough" while being "not so bad" but not just choosing "what is best for the financial interest of the business?"
I'm seriously, without a clear definition but also without the goal of doing what is right for the business... what's the motivator for this? What makes something the lesser choice, but good enough?
Isn't part of being the best solution also having the lowest cost while still getting all of the needed items from that solution?
Acquisition cost is a factor in the TCO, but only the TCO is the cost, not the acquisition cost. And ROI is more important regardless of TCO.
-
@Dashrender said in A Mandate to Be Cheap:
@dafyre said in A Mandate to Be Cheap:
@coliver said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@scottalanmiller said in A Mandate to Be Cheap:
@DustinB3403 said in A Mandate to Be Cheap:
The term cheap to me (and I think others) means it needs to perform to the level that we can still run production (or whatever the use case is) and save more money than what we may have been proposed before.
That's an undefinable definition. Cheap but not the cheapest, good but not the best for us. So not the best option for the business, but not recklessly cheap. How do you make decisions around that? How do you decide what is "cheap enough" while being "not so bad" but not just choosing "what is best for the financial interest of the business?"
I'm seriously, without a clear definition but also without the goal of doing what is right for the business... what's the motivator for this? What makes something the lesser choice, but good enough?
Isn't part of being the best solution also having the lowest cost while still getting all of the needed items from that solution?
Right, but cheap denotes that you are making sacrifices that would stop you from getting the best solution for you business. At least to me it does.
But in this case, the "best solution" just happens to have all the features they want and need at the lowest price point.
The cheapest solution isn't always going to be the best solution for a business... but sometimes it is.
Please give an example of a solution that isn't the best while meeting the goals and is cheaper than the best solution.
PowerCAMPUS vs Jenzabar's POISE product lines... (this was a real choice at my last job)... We went with PowerCampus, because it did most of the things we wanted it to do, but it still lacked several features of the more expensive POISE product that would have made many things much better across our campus.
PowerCAMPUS did most of what we wanted, it met most of the goals, and came out cheaper than POISE.
Edit: I was agreeing with you, @Dashrender , lol.
-
@coliver said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@scottalanmiller said in A Mandate to Be Cheap:
@DustinB3403 said in A Mandate to Be Cheap:
The term cheap to me (and I think others) means it needs to perform to the level that we can still run production (or whatever the use case is) and save more money than what we may have been proposed before.
That's an undefinable definition. Cheap but not the cheapest, good but not the best for us. So not the best option for the business, but not recklessly cheap. How do you make decisions around that? How do you decide what is "cheap enough" while being "not so bad" but not just choosing "what is best for the financial interest of the business?"
I'm seriously, without a clear definition but also without the goal of doing what is right for the business... what's the motivator for this? What makes something the lesser choice, but good enough?
Isn't part of being the best solution also having the lowest cost while still getting all of the needed items from that solution?
Right, but cheap denotes that you are making sacrifices that would stop you from getting the best solution for you business. At least to me it does.
Exactly. "Best" is no longer the decision factor... something else is. Anything else, is bad. Cheap is just one of many bad options.
-
@Dashrender said in A Mandate to Be Cheap:
@scottalanmiller said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@DustinB3403 said in A Mandate to Be Cheap:
And I know of very few businesses that would say it must be Free
Free is just dangerous, as it's all on "you" to maintain. Sure you save 100% of the cost.
The term cheap to me (and I think others) means it needs to perform to the level that we can still run production (or whatever the use case is) and save more money than what we may have been proposed before.
But if it doesn't solve the problem you're trying to solve, then what difference does the cost make? So to use your example, if you buy the 'cheaper' NTG option, yet they can't fix your problems, did you really get the cheaper option? I'd say no, instead you just wasted money.
We assume that it solves the problem, or isn't in the decision matrix. If "solving the problem" wasn't a goal, you'd literally do nothing at all - not even drive into work any more. Solving the problem is obviously implied or this discussion would not even arise.
Well then, considering my 1 min ago question - Best means option that solves problem while being lowest cost... then NTG would be the BEST solution.. it also happens to be the cheaper but really, less expensive option.
Certainly cheapest and best can overlap and often do. Linux is free and one of the best options for many things. But not always, Windows has value too and is sometimes the right solution, for example.
-
@Dashrender said in A Mandate to Be Cheap:
@DustinB3403 said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@coliver said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@scottalanmiller said in A Mandate to Be Cheap:
@DustinB3403 said in A Mandate to Be Cheap:
The term cheap to me (and I think others) means it needs to perform to the level that we can still run production (or whatever the use case is) and save more money than what we may have been proposed before.
That's an undefinable definition. Cheap but not the cheapest, good but not the best for us. So not the best option for the business, but not recklessly cheap. How do you make decisions around that? How do you decide what is "cheap enough" while being "not so bad" but not just choosing "what is best for the financial interest of the business?"
I'm seriously, without a clear definition but also without the goal of doing what is right for the business... what's the motivator for this? What makes something the lesser choice, but good enough?
Isn't part of being the best solution also having the lowest cost while still getting all of the needed items from that solution?
Right, but cheap denotes that you are making sacrifices that would stop you from getting the best solution for you business. At least to me it does.
So can it be cheaper and still solve the problem and not be the best?
Xen Orchestra from the sources is as cheap as it gets (because of the functionality of it). Meaning the XO Updater script, the capability to install it in a matter of minutes.
The fact that XO by it's self is disposable, and recreated in minutes.
Not that I don't love @olivier for the work he's created, but the source option is literally the best choice for this business.
is it? Could you spend the time you spend updating XO doing other things that are more valuable to the company? Maybe? Maybe not?
./xo-update.shIt's a 15 second command at most, that installs the most current updates. How much value can be squeezed out of 15 seconds?
It can even be scheduled via cron...
-
@dafyre said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@dafyre said in A Mandate to Be Cheap:
@coliver said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@scottalanmiller said in A Mandate to Be Cheap:
@DustinB3403 said in A Mandate to Be Cheap:
The term cheap to me (and I think others) means it needs to perform to the level that we can still run production (or whatever the use case is) and save more money than what we may have been proposed before.
That's an undefinable definition. Cheap but not the cheapest, good but not the best for us. So not the best option for the business, but not recklessly cheap. How do you make decisions around that? How do you decide what is "cheap enough" while being "not so bad" but not just choosing "what is best for the financial interest of the business?"
I'm seriously, without a clear definition but also without the goal of doing what is right for the business... what's the motivator for this? What makes something the lesser choice, but good enough?
Isn't part of being the best solution also having the lowest cost while still getting all of the needed items from that solution?
Right, but cheap denotes that you are making sacrifices that would stop you from getting the best solution for you business. At least to me it does.
But in this case, the "best solution" just happens to have all the features they want and need at the lowest price point.
The cheapest solution isn't always going to be the best solution for a business... but sometimes it is.
Please give an example of a solution that isn't the best while meeting the goals and is cheaper than the best solution.
PowerCAMPUS vs Jenzabar's POISE product lines... (this was a real choice at my last job)... We went with PowerCampus, because it did most of the things we wanted it to do, but it still lacked several features of the more expensive POISE product that would have made many things much better across our campus.
PowerCAMPUS did most of what we wanted, it met most of the goals, and came out cheaper than POISE.
Edit: I was agreeing with you, @Dashrender , lol.
In your own example, you didn't actually meet the goals, instead, you changed the goals to meet the price, aka were being cheap.
-
@Dashrender said in A Mandate to Be Cheap:
@coliver said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@scottalanmiller said in A Mandate to Be Cheap:
@DustinB3403 said in A Mandate to Be Cheap:
The term cheap to me (and I think others) means it needs to perform to the level that we can still run production (or whatever the use case is) and save more money than what we may have been proposed before.
That's an undefinable definition. Cheap but not the cheapest, good but not the best for us. So not the best option for the business, but not recklessly cheap. How do you make decisions around that? How do you decide what is "cheap enough" while being "not so bad" but not just choosing "what is best for the financial interest of the business?"
I'm seriously, without a clear definition but also without the goal of doing what is right for the business... what's the motivator for this? What makes something the lesser choice, but good enough?
Isn't part of being the best solution also having the lowest cost while still getting all of the needed items from that solution?
Right, but cheap denotes that you are making sacrifices that would stop you from getting the best solution for you business. At least to me it does.
So can it be cheaper and still solve the problem and not be the best?
Correct
-
@dafyre said in A Mandate to Be Cheap:
@coliver said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@scottalanmiller said in A Mandate to Be Cheap:
@DustinB3403 said in A Mandate to Be Cheap:
The term cheap to me (and I think others) means it needs to perform to the level that we can still run production (or whatever the use case is) and save more money than what we may have been proposed before.
That's an undefinable definition. Cheap but not the cheapest, good but not the best for us. So not the best option for the business, but not recklessly cheap. How do you make decisions around that? How do you decide what is "cheap enough" while being "not so bad" but not just choosing "what is best for the financial interest of the business?"
I'm seriously, without a clear definition but also without the goal of doing what is right for the business... what's the motivator for this? What makes something the lesser choice, but good enough?
Isn't part of being the best solution also having the lowest cost while still getting all of the needed items from that solution?
Right, but cheap denotes that you are making sacrifices that would stop you from getting the best solution for you business. At least to me it does.
But in this case, the "best solution" just happens to have all the features they want and need at the lowest price point.
The cheapest solution isn't always going to be the best solution for a business... but sometimes it is.
Often
-
@dafyre said in A Mandate to Be Cheap:
@coliver said in A Mandate to Be Cheap:
Cheap has, to me, always been related to quality. Something that is cheap is inferior to other products. Inexpensive is different, again to me, then cheap. Inexpensive on the other hand meets your needs without sacrificing quality. Cheap = / = Inexpensive in my mind.
This is a good way to look at it.
No one is prioritizing "junk", though. That's not how anyone in this situation is meaning it. That would truly be sabotage.
SPend as much as you want... as long as it doesn't work.
Um... what?
-
@scottalanmiller said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@DustinB3403 said in A Mandate to Be Cheap:
A business owner should understand the value of the people they have employed. Without understanding that, the owner would look around and immediately think everyone employed by them is there to rob from them.
Of course they should but you can read countless encounters where they don't. Hell, I think you've given some of those points from time to time.... i.e. you're dealing with learning XO instead of just purchasing a know good working backup product. Of the fact that your company won't shell out the $900/yr for XOA which would keep you from having to jump through hoops to keep XO updated manually, etc.
$900/yr is a LOT, though. In a five year solution, that's $4,500. If you earn $90,000/year that's $450,000 during that window. Which is exactly 1% of your time for XO.
1% of a 40 hour IT guy is 104 hours during that time. That's a LOT of hours for maintaining a single application. It's very, very easy for a shop to support XO for that long with far less time than that. And it's not like XOA uses zero time itself. Only the delta between the two needs to be 104 hours.
And if you have staff that is idle and/or earning less than 90K or works more than 40 hours a week.... the numbers skew towards the free solution quickly.
@DustinB3403 said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@DustinB3403 said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@coliver said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@scottalanmiller said in A Mandate to Be Cheap:
@DustinB3403 said in A Mandate to Be Cheap:
The term cheap to me (and I think others) means it needs to perform to the level that we can still run production (or whatever the use case is) and save more money than what we may have been proposed before.
That's an undefinable definition. Cheap but not the cheapest, good but not the best for us. So not the best option for the business, but not recklessly cheap. How do you make decisions around that? How do you decide what is "cheap enough" while being "not so bad" but not just choosing "what is best for the financial interest of the business?"
I'm seriously, without a clear definition but also without the goal of doing what is right for the business... what's the motivator for this? What makes something the lesser choice, but good enough?
Isn't part of being the best solution also having the lowest cost while still getting all of the needed items from that solution?
Right, but cheap denotes that you are making sacrifices that would stop you from getting the best solution for you business. At least to me it does.
So can it be cheaper and still solve the problem and not be the best?
Xen Orchestra from the sources is as cheap as it gets (because of the functionality of it). Meaning the XO Updater script, the capability to install it in a matter of minutes.
The fact that XO by it's self is disposable, and recreated in minutes.
Not that I don't love @olivier for the work he's created, but the source option is literally the best choice for this business.
is it? Could you spend the time you spend updating XO doing other things that are more valuable to the company? Maybe? Maybe not?
./xo-update.shIt's a 15 second command at most, that installs the most current updates. How much value can be squeezed out of 15 seconds?
It can even be scheduled via cron...
I was just asking a question. But one thing neither of you mentioned was the original setup time. I'm sure Dustin spent over 20 hours when first working with it... But that goes to Scott's TCO, not ROI, so I see his point.
-
@Dashrender said in A Mandate to Be Cheap:
@DustinB3403 said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@coliver said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@scottalanmiller said in A Mandate to Be Cheap:
@DustinB3403 said in A Mandate to Be Cheap:
The term cheap to me (and I think others) means it needs to perform to the level that we can still run production (or whatever the use case is) and save more money than what we may have been proposed before.
That's an undefinable definition. Cheap but not the cheapest, good but not the best for us. So not the best option for the business, but not recklessly cheap. How do you make decisions around that? How do you decide what is "cheap enough" while being "not so bad" but not just choosing "what is best for the financial interest of the business?"
I'm seriously, without a clear definition but also without the goal of doing what is right for the business... what's the motivator for this? What makes something the lesser choice, but good enough?
Isn't part of being the best solution also having the lowest cost while still getting all of the needed items from that solution?
Right, but cheap denotes that you are making sacrifices that would stop you from getting the best solution for you business. At least to me it does.
So can it be cheaper and still solve the problem and not be the best?
Xen Orchestra from the sources is as cheap as it gets (because of the functionality of it). Meaning the XO Updater script, the capability to install it in a matter of minutes.
The fact that XO by it's self is disposable, and recreated in minutes.
Not that I don't love @olivier for the work he's created, but the source option is literally the best choice for this business.
is it? Could you spend the time you spend updating XO doing other things that are more valuable to the company? Maybe? Maybe not?
That's the right way to look at it. XO leans towards the free because it is non-critical. So the time spend can be saved for free time or idle time rather than pulling from projects or fires.
-
@DustinB3403 said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@DustinB3403 said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@coliver said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@scottalanmiller said in A Mandate to Be Cheap:
@DustinB3403 said in A Mandate to Be Cheap:
The term cheap to me (and I think others) means it needs to perform to the level that we can still run production (or whatever the use case is) and save more money than what we may have been proposed before.
That's an undefinable definition. Cheap but not the cheapest, good but not the best for us. So not the best option for the business, but not recklessly cheap. How do you make decisions around that? How do you decide what is "cheap enough" while being "not so bad" but not just choosing "what is best for the financial interest of the business?"
I'm seriously, without a clear definition but also without the goal of doing what is right for the business... what's the motivator for this? What makes something the lesser choice, but good enough?
Isn't part of being the best solution also having the lowest cost while still getting all of the needed items from that solution?
Right, but cheap denotes that you are making sacrifices that would stop you from getting the best solution for you business. At least to me it does.
So can it be cheaper and still solve the problem and not be the best?
Xen Orchestra from the sources is as cheap as it gets (because of the functionality of it). Meaning the XO Updater script, the capability to install it in a matter of minutes.
The fact that XO by it's self is disposable, and recreated in minutes.
Not that I don't love @olivier for the work he's created, but the source option is literally the best choice for this business.
is it? Could you spend the time you spend updating XO doing other things that are more valuable to the company? Maybe? Maybe not?
./xo-update.shIt's a 15 second command at most, that installs the most current updates. How much value can be squeezed out of 15 seconds?
It can even be scheduled via cron...
Scheduling is the really big deal - it's a five minute fix and then it is set and forget.
-
@Dashrender said in A Mandate to Be Cheap:
@dafyre said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@dafyre said in A Mandate to Be Cheap:
@coliver said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@scottalanmiller said in A Mandate to Be Cheap:
@DustinB3403 said in A Mandate to Be Cheap:
The term cheap to me (and I think others) means it needs to perform to the level that we can still run production (or whatever the use case is) and save more money than what we may have been proposed before.
That's an undefinable definition. Cheap but not the cheapest, good but not the best for us. So not the best option for the business, but not recklessly cheap. How do you make decisions around that? How do you decide what is "cheap enough" while being "not so bad" but not just choosing "what is best for the financial interest of the business?"
I'm seriously, without a clear definition but also without the goal of doing what is right for the business... what's the motivator for this? What makes something the lesser choice, but good enough?
Isn't part of being the best solution also having the lowest cost while still getting all of the needed items from that solution?
Right, but cheap denotes that you are making sacrifices that would stop you from getting the best solution for you business. At least to me it does.
But in this case, the "best solution" just happens to have all the features they want and need at the lowest price point.
The cheapest solution isn't always going to be the best solution for a business... but sometimes it is.
Please give an example of a solution that isn't the best while meeting the goals and is cheaper than the best solution.
PowerCAMPUS vs Jenzabar's POISE product lines... (this was a real choice at my last job)... We went with PowerCampus, because it did most of the things we wanted it to do, but it still lacked several features of the more expensive POISE product that would have made many things much better across our campus.
PowerCAMPUS did most of what we wanted, it met most of the goals, and came out cheaper than POISE.
Edit: I was agreeing with you, @Dashrender , lol.
In your own example, you didn't actually meet the goals, instead, you changed the goals to meet the price, aka were being cheap.
That's different entirely, lol.
-
@dafyre said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@dafyre said in A Mandate to Be Cheap:
@coliver said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@scottalanmiller said in A Mandate to Be Cheap:
@DustinB3403 said in A Mandate to Be Cheap:
The term cheap to me (and I think others) means it needs to perform to the level that we can still run production (or whatever the use case is) and save more money than what we may have been proposed before.
That's an undefinable definition. Cheap but not the cheapest, good but not the best for us. So not the best option for the business, but not recklessly cheap. How do you make decisions around that? How do you decide what is "cheap enough" while being "not so bad" but not just choosing "what is best for the financial interest of the business?"
I'm seriously, without a clear definition but also without the goal of doing what is right for the business... what's the motivator for this? What makes something the lesser choice, but good enough?
Isn't part of being the best solution also having the lowest cost while still getting all of the needed items from that solution?
Right, but cheap denotes that you are making sacrifices that would stop you from getting the best solution for you business. At least to me it does.
But in this case, the "best solution" just happens to have all the features they want and need at the lowest price point.
The cheapest solution isn't always going to be the best solution for a business... but sometimes it is.
Please give an example of a solution that isn't the best while meeting the goals and is cheaper than the best solution.
PowerCAMPUS vs Jenzabar's POISE product lines... (this was a real choice at my last job)... We went with PowerCampus, because it did most of the things we wanted it to do, but it still lacked several features of the more expensive POISE product that would have made many things much better across our campus.
PowerCAMPUS did most of what we wanted, it met most of the goals, and came out cheaper than POISE.
Edit: I was agreeing with you, @Dashrender , lol.
So they actually prioritized cost OVER meeting the needs? Or were the goals not really needs and therefore the process exposed bad goal making?
-
@Dashrender said in A Mandate to Be Cheap:
@dafyre said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@dafyre said in A Mandate to Be Cheap:
@coliver said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@scottalanmiller said in A Mandate to Be Cheap:
@DustinB3403 said in A Mandate to Be Cheap:
The term cheap to me (and I think others) means it needs to perform to the level that we can still run production (or whatever the use case is) and save more money than what we may have been proposed before.
That's an undefinable definition. Cheap but not the cheapest, good but not the best for us. So not the best option for the business, but not recklessly cheap. How do you make decisions around that? How do you decide what is "cheap enough" while being "not so bad" but not just choosing "what is best for the financial interest of the business?"
I'm seriously, without a clear definition but also without the goal of doing what is right for the business... what's the motivator for this? What makes something the lesser choice, but good enough?
Isn't part of being the best solution also having the lowest cost while still getting all of the needed items from that solution?
Right, but cheap denotes that you are making sacrifices that would stop you from getting the best solution for you business. At least to me it does.
But in this case, the "best solution" just happens to have all the features they want and need at the lowest price point.
The cheapest solution isn't always going to be the best solution for a business... but sometimes it is.
Please give an example of a solution that isn't the best while meeting the goals and is cheaper than the best solution.
PowerCAMPUS vs Jenzabar's POISE product lines... (this was a real choice at my last job)... We went with PowerCampus, because it did most of the things we wanted it to do, but it still lacked several features of the more expensive POISE product that would have made many things much better across our campus.
PowerCAMPUS did most of what we wanted, it met most of the goals, and came out cheaper than POISE.
Edit: I was agreeing with you, @Dashrender , lol.
In your own example, you didn't actually meet the goals, instead, you changed the goals to meet the price, aka were being cheap.
I should have clarified. The goal was to find a product that worked and that the campus could afford, while retaining the same level of functionality that we had with the old system. PC was not the
cheapestmost inexpensive at all. But the next step up to the Jenzabar product was out of our price range.So we chose the best product that could meet our price point. (Although I do not argue that we did have to make adjustments to meet this price point).
-
@Dashrender said in A Mandate to Be Cheap:
I was just asking a question. But one thing neither of you mentioned was the original setup time. I'm sure Dustin spent over 20 hours when first working with it... But that goes to Scott's TCO, not ROI, so I see his point.
Right, those hours certainly matter, but are way below the 104 hour value envelope. And XOA would take at least one hour itself.
-
So cheap in this discussion doesn't mean changing the stated goals to find a less costly solution, it just means finding a less expensive (cheaper) solution that still fills all the goals - I'm still lost how the new found solution wouldn't be the best? I suppose it could be that the 'cheaper' solution could require 10 hours of manual work by IT, where the more expensive option would require none or 1 hr, as an example.
