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:
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.
-
@dafyre said in A Mandate to Be Cheap:
@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).
That's definitely cheap driving the decisions - even beyond what we are discussing here. You are leading with a price point and willing to fail to meet goals in order to achieve the price point. What made those things goals if they didn't matter compared to the price? Sounds like the price was the actual goal.
-
@scottalanmiller 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.
So they actually prioritized cost OVER meeting the needs? Or were the goals not really needs and therefore the process exposed bad goal making?
Yes, pretty much to all of that. My last employer did not have an infinitely deep purse from which to pull money out of their... hat. So we had to stay with in limits. The implementation of PC was cheaper by more than 50%, while retaining the largest portion of features that were actually needed.
Edit: The final decision was made by administration and not IT, as it were. We did what you would have done, @scottalanmiller : We let them make the decision.
-
@Dashrender said in A Mandate to Be Cheap:
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.
What is best is "what improves the company's bottom line the most."
If the cheaper solution does not improve it the most, it's not the best. Period. Meeting base requirements or costing less to acquire aren't what do those things. They might, easily, but there is no direct connection.
-
@dafyre said in A Mandate to Be Cheap:
@scottalanmiller 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.
So they actually prioritized cost OVER meeting the needs? Or were the goals not really needs and therefore the process exposed bad goal making?
Yes, pretty much to all of that. My last employer did not have an infinitely deep purse from which to pull money out of their... hat. So we had to stay with in limits. The implementation of PC was cheaper by more than 50%, while retaining the largest portion of features that were actually needed.
Of course they didn't have a deep purse, they were not focused on maximum profits but on being cheap - so they had problems because making money was not driving their thinking and they were demonstrating the problems that I am highlighting in this thread.
If they had the "best" solution and could not afford it, a bank would certainly loan them the money to do it because it would be so obviously the way to make money.
-
@dafyre said in A Mandate to Be Cheap:
Edit: The final decision was made by administration and not IT, as it were. We did what you would have done, @scottalanmiller : We let them make the decision.
Technically, whoever makes the decisions is IT. So they just turned into IT management.
-
@scottalanmiller said in A Mandate to Be Cheap:
@dafyre said in A Mandate to Be Cheap:
@scottalanmiller 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.
So they actually prioritized cost OVER meeting the needs? Or were the goals not really needs and therefore the process exposed bad goal making?
Yes, pretty much to all of that. My last employer did not have an infinitely deep purse from which to pull money out of their... hat. So we had to stay with in limits. The implementation of PC was cheaper by more than 50%, while retaining the largest portion of features that were actually needed.
Of course they didn't have a deep purse, they were not focused on maximum profits but on being cheap - so they had problems because making money was not driving their thinking and they were demonstrating the problems that I am highlighting in this thread.
If they had the "best" solution and could not afford it, a bank would certainly loan them the money to do it because it would be so obviously the way to make money.
No. The bank did not loan them the money, lol. They asked about that.
-
@scottalanmiller said in A Mandate to Be Cheap:
@dafyre said in A Mandate to Be Cheap:
Edit: The final decision was made by administration and not IT, as it were. We did what you would have done, @scottalanmiller : We let them make the decision.
Technically, whoever makes the decisions is IT. So they just turned into IT management.
It seems like I'm always hearing you tell us to do whatever management says? How does that factor in here?
-
@scottalanmiller said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
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.
What is best is "what improves the company's bottom line the most."
If the cheaper solution does not improve it the most, it's not the best. Period. Meeting base requirements or costing less to acquire aren't what do those things. They might, easily, but there is no direct connection.
Time out here - if the ongoing support makes the product more expensive, then clearly it's not the cheapest solution, and IT is failing to make management (IT management) understand this. Thought, this still breaks into the TCO, not ROI, so I'm not sure where ROI becomes more important?
-
@dafyre said in A Mandate to Be Cheap:
@scottalanmiller said in A Mandate to Be Cheap:
@dafyre said in A Mandate to Be Cheap:
Edit: The final decision was made by administration and not IT, as it were. We did what you would have done, @scottalanmiller : We let them make the decision.
Technically, whoever makes the decisions is IT. So they just turned into IT management.
It seems like I'm always hearing you tell us to do whatever management says? How does that factor in here?
Because the reality is because they have made themselves IT management, not you. It's like a company that has a bunch of accountants, all of them do their part, giving reports on accounting about the company to the CFO, but the CFO is the HNIC and makes the decisions
-
@Dashrender said in A Mandate to Be Cheap:
@dafyre said in A Mandate to Be Cheap:
@scottalanmiller said in A Mandate to Be Cheap:
@dafyre said in A Mandate to Be Cheap:
Edit: The final decision was made by administration and not IT, as it were. We did what you would have done, @scottalanmiller : We let them make the decision.
Technically, whoever makes the decisions is IT. So they just turned into IT management.
It seems like I'm always hearing you tell us to do whatever management says? How does that factor in here?
Because the reality is because they have made themselves IT management, not you. It's like a company that has a bunch of accountants, all of them do their part, giving reports on accounting about the company to the CFO, but the CFO is the HNIC and makes the decisions
This was prevalent for a number of years at my job... As I was leaving, it did not seem to be quite as large of a problem.
-
@Dashrender said in A Mandate to Be Cheap:
@scottalanmiller said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
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.
What is best is "what improves the company's bottom line the most."
If the cheaper solution does not improve it the most, it's not the best. Period. Meeting base requirements or costing less to acquire aren't what do those things. They might, easily, but there is no direct connection.
Time out here - if the ongoing support makes the product more expensive, then clearly it's not the cheapest solution, and IT is failing to make management (IT management) understand this. Thought, this still breaks into the TCO, not ROI, so I'm not sure where ROI becomes more important?
ROI is the most important on static style purchases.
For example if you have to purchase a new 300Ton punch press, which cost $3million to purchase.
Do you want to purchase it with a loan from a bank, or business capitol. When will the machine have paid for its self.
Support never factors into the ROI equation, unless the RTO is meant for a mission critical business function (IE support fixes an issues that saves the business a lot of money, that otherwise would have been lost without that support)
-
@dafyre said in A Mandate to Be Cheap:
This was prevalent for a number of years at my job... As I was leaving, it did not seem to be quite as large of a problem.
Why is it a problem at all? As long as everyone knows who is the IT decision maker, that's all that matters. That's the person you (I dislike saying this) blame when things don't work because of some decision that was made.
