I actually thought it would be a good idea to get an MBA part time. My best classes were economics and the worst were accounting and business law. Coming from an engineering background, I found the whole cencept of law illogical.
I actually though it would be a good idea to get an MBA part time.
When I finsihed my engineering degree, since I finished so far back in the pack, I decided that I wouldn't be a good engineer. I then did an MBA. It seemed to me an engineer as a manager was a good plan since a) you could get further organizationally and b) there were always managers who needed to understand what the engineers were doing.
Circumstances conspired and got me into engineering rather than management, and I have only recently moved part-time into management.
Exactly!! I tried doing MBA part-time while doing job but found finance a boring subject. Mathematical problems finance were interesting to solve but I found accounting horribly confusing...the balance sheet...oh!! I had to give-up for other reasons, but I was happy that I got rid of that...after all I like to spend time with electronics during that extra time became available...
But I agree that to be a good engineering manager or an entrepreneur, once should have good understanding of finance.
I think why the product failed really matters in this case. As I understand it, the reason Beta lost in the US was pretty much random chance--there were a few more movies available in VHS, and that tipped the market just a bit in the favor of VHS. Positive feedback then ensued--more movies were made for VHS because there were more VHS players, and vice versa.
There is also a camp that believes that super-long recording time (6 hours?) was first available on VHS; this probably had some effect as well, and may have been just enough stimulus to get the above-mentioned positive feedback going. I don't remember how long it took Sony to respond to this, but I think it was quite a while--well over a year. If that's the case, then it's really bad Engineering (in the broad sense--including management and marketing, but also the product developers as well) to allow a competing format to have a key feature for some months with no response.
I think this is correct. VHS and Beta were both viable standards, but VHS developed the rental market faster. It was a virtuous cycle (or a viscious cycle if you were in the Beta camp). The slight VHS rental market share advantage led more people to get VHS players. Then more outlets concentrated on VHS in response to the larger number of players. Then VHS players were heavily in demand, and the rental outlets focused even more on VHS. And so forth until there was only VHS. Had Beta gained a matching share early on in the rental market, the whole industry could have switched to Beta.
We saw the same thing play out on Blu-Ray vs. HD DVD. Here is was the movie studio adoption that swung the advantage to Blu-Ray.
Larry, Speaking of failures, we've both been around the test business long enough to have seen a few there. Remember the HP Logic Dart? The first version was an engineering mess (very hard to use). The released version was so much better that it went on to win Test & Measurement World's Test Product of the year. It was off the market in less than two years.
I also remember the LeCroy Scopestation, the first oscilloscope (1993 I think) with a PC motherboard. This DOS-based scope was ahead of it's time and it failed.
Can you think of any otherS? If we can come up with 5 or more, it could be a slideshow.
I'll think about it. High tech is characterized with risk, as a commentor below has pointed out. There are no sure things. Part of portfolio management is to accept that some failueres will occur, so your winners must be robust enough to pay for all the lost investments.
Remember the USAF MATE program, and the CIIL programming language? I wonder if ANY of those products were financially successful.
I personally like ROI better for comparing individual project, as the ratio lets you combine multiple projects for better return. Given the scenario of N projects of which you don't have funding for all of them, however, I think NPV of sets of projects--each of which maxes out the funding available (each of which has a positive NPV)--is the best comparison. I wouldn't try all possible combinations; I'd start with the ones that have the highest ROI and come up with several possible groupings that uses up the available funding, then pick the one with the highest NPV.
This assumes, of course, that each project is risk-free. That is rarely the case. As part of this exercise I'd try to make some reasonable guesses about how risky each project is. Is this something the team has done before (not very risky)? Is it new to the team (pretty risky)? Is it new to the world (very risky)? What's the likelyhood that a competitor will emerge that drops your sales--do you have strong barriers to entry (such as patents, regulations, customer relationships, or proprietary technology or distribution channel that's hard to duplicate), or is this an area that a strong competitor would naturally want to enter? What's the likelyhood that there is a supplier gets too much control and sucks up all the profit (think Intel and Microsoft for PCs). Discounting ROI & NPV for risk is not an easy task--there is no simple formula you can use. But to not include this as part of the analysis neglects what happens in the real world!
I also personally like the idea of doing some portfolio-style analysis on projects--some portion are low risk with low return, and some portion are higher risk with higher return. If the high-return projects pay off, that's great. If not, you've still got the low-risk projects to keep you going.
Thanks for being the first commentor to take a shot at the NPV vs. ROI question. I'll write you down as a vote for ROI. I will refrain from answering yet, to see if we have more comments on this subject.
Yes- risk is a crucial element! Good comment. There are many ways to handle risk, each with their own peculiarities.
On the NPV vs ROI question, I think maybe NPV is more important for strategic direction, where ROI might be used to solve a tactical problem. It seems kind of obvious that a company wanting to survive in the long term, and keep its employees paid, cannot do so based on ROI alone. But if you have to decide whether or not to invest money on a component, or buy off the shelf, then ROI would answer that question for you.
The graphs you draw are clear and straightforward, the problem being that rarely if ever does anyone have good enough data to draw them. They are the kinds of graphs one sees in marketing presentations, often without any numbers on the axes, more useful to present a concept than accurate predictions. Engineers should know very well the concept of measurement tolerance. The analogy in this case might be, designing a system with components with high tolerance for error, which wil lead to designs that are going to be much less than optimal.
The VHS vs Beta race was one where VHS seemed to have the upper hand on recording time, just about throughout. At the beginning, Beta was good for only one hour, and VHS for two. If you're wanting to record prime time TV shows for time-shift viewing, that's pretty critical. In spite of the popular wisdom, there were other technical advantages to VHS that took Beta several years to match (heads retracting on rewind, stereo audio capability designed in from the start, not to mention availability of format from multiple vendors, also from the start).
You make a good point about the idealized graphs. Even if they don't exist in nature, they are still useful. Many decisions are binary: Do THIS or THAT. In those cases, you only need to have enough information to make the right decision- you don't have to be precise in exactly how much better alternative A is than B. Additionally, there is still value in at least trying to state your best guess- whether its schedule, sales volume, or price elasticity. Before spending big bucks on a project, there should at least be a reasonable scenario where the investment makes sense. The inaccuracies that you noted is exactly why I like rules of thumb and simplified analysis. The math is easier, and very little accuracy is lost compared to the raw assumptions.
The problem with using ROI to select doing one project over another is that it doesn't account for the time value of money and doesn't account for the difference in total revenue between each project, or the timing of that revenue. If I must choose between doing a smaller project (lesser lifetime revenue) with a huge ROI or a much bigger project (greater lifetime revenue) but with a smaller ROI, then choosing the higher ROI project may ultimately mean I make less profit. The NPV of the larger project could be much higher -- especially if it's revenue stream starts earlier than that of the smaller project.
Quite agree that its nice tohave engineers with financials baiscs. As one grows up the ladder, you got to understand revenue part and if you have basics in finance it helps a lot. Even if you remain in technical side its hard to stay away from finance because everything boils down to numbers.
Just as a comment, ROI can take into account time value of money. That is, future cash flows may be discounted before the ROI calculation. However, you are correct that ROI doesn't take into account the total size of the investment or revenue, and this is the big deviation from the NPV ordered list.
MBAs are really only worth anything from the top half-dozen schools, and then only for the contacts you make, rather than the course contents. There's nothing about the basics of finance that you can't teach yourself from books. Just remember you always work to 2 decimal places.
The inspiration for my remark about 2 decimal places was a complaint by (IIRC) Norbert Wiener, who had accountants as "computers", (the term in those days meant people), to work on ballistics tables for artillery. He said something along the lines of "It didn't matter if the number in question was the calibre of the gun in millimetres, or the range of the shell in miles, they always worked to 2 decimal places".
(Find the missing spacecraft lurking in that quote. :-)* )
I'm lucky to be an engineer and to also have earned an MBA from a top school. A lot of what I learned in both disciplines is impractical, or "not how things are done in the real world."
For engineering managers, I always preach they know and understand two things: (1) Sunk costs, and (2) Opportunity costs.
For sunk costs, if you've ever heard someone say, "We have to keep going on this project. We've already spent $1M and 6 months...", then you know sunk cost. I still hear statements like this from people who are very intelligent. The issue is framing: Decisions based on cost need to be framed from now ("time zero"), not when expenses started accruing for a project.
The other key concept is opportunity cost. If you've ever heard an engineering manager say, "We can develop that in house because I have people who have done it before...", then then next thing you should say to her is, "But should you?" In this example, the opportunity cost is the difference between the value of the work the engineering manager says her team can do versus the other, perhaps higher value, work the team could do. Opportunity cost is the most important factor in make vs. buy decisions.
If an engineering manager can grok these two concepts, then her financial education is (mostly) complete :-)
You are absolutely right about sunk costs. An organization should always be looking at incremental costs and incremental returns when prioritizing projects. A dilemma that faces high tech, is that it takes some investment to even forecast schedule, investment, and revenue. This can work for or against a project: A product that forecasts weaker sales than hoped may still be executed, because the incremental effort to complete the project is low. Conversely, a project may be cancelled even if there is already a good investment behind it, it the remaining investment does not justify the return.
The opportunity cost comment is true as well.In general, if you propoerly ranked the projects, you should be comparing a new idea against your best unfunded project.
Before I give the final answer on my NPV (Net Present Value) vs. ROI (Return on Investment) question, I'd like to give an analogy that I invented in order to explain why the answer is what it is. As I wrote, even finance people can get this one backwards.
Imagine you have a large barrel. Your objective is to fill it with sugar water, and to have the most sugar in the barrel as you can.
You must fill the barrel from an assortment of different sized glasses and mugs, each with different concentrations of sugar within them. The CONCENTRATION of the sugar in each vessel is the ROI. It is just a ratio. The TOTAL sugar dissolved in each vessel is the NPV.
You have more water in the combined totals of vessels than can possibly fit into the barrel.
Do you pour in the most concentrated (highest ROI), or with the most absolute sugar (NPV)?
You goal is to maximize the sugar in the barrel (NPV). Does it also maximize ROI?
Just to clarify: I should have said that you have more water in the TOTAL of all vessels than can possibly fit in the barrel. Each vessel is smaller than the barrel by itself. This is exactly the situation when you have more project ideas than you can fund. Which ones do yo choose first?
When I went to VA Tech, one of the introductory engineering courses was "Engineering Economy," in which we learned about things like the time value of money, expected value using probabilities to assess risk, and other fiscal basics that could inform our design decisions. I found the class gave me a perspective on design and its relationship to business issues that allowed me to communicate more effectively with corporate level executives and better justify my projects, even without my pursuing an MBA.
It also helped me at home, to figure out the payback of home improvements and to better understand mortgage financing.
So I agree, engineers should have at least an introduction to finance as part of their basic education.
The was an Engineering Economic Scxience major at Stanford when I went there for grad school. Though I didn't take any EES classes, I knew people who did. They related this peculiar calculation:
When do you decide to put a guard rail up on a mountain corner? Well, you can look at statitics of accidents on mountain roads due to driving too fast for a corner, the probability of the guard rail preventing a fatal accident, and the cost of the guard rail. What you finally end up with is cost/life saved.
But then how do you calculate the value of a life to see if it is worth it? They were instructed to estimate the income potential of the average driver (or passenger), and discount back to Net Prevent Value. Not their total lifetime income- the income for the remaining years of their lives. Yes- NPV- ignoring sunk costs and sunk income!
I was taken back buy this calous calculation. I think the idea was, looking at only economic factors, this maximized society's total net economic activity. Less guard rails and you lose income, which represents the value of the goods and service that individual would have produced. Invest more, and society is investing more than the goods and services they are saving. I'm not advocating this cutoff, but I found it interesting.
Whatever the cutoff criteria, rank ordering investments by cost/life saved is a good way to prioritize safety investments.
Should you prioritize projects by NPV or ROI? That was the question behind my fifth and final scenrio. The answer is ROI.
If you rank order all projects in order of ROI, and keep selecting the highest ROI projects until you have used all your funding, you will create a portfolio that has the highest ROI...and NPV.
If you saw my analogy above with the concentratioin of sugar in different containers, you may have already come to this conclusion. But let me make an actual financial analogy. Let's say you have $10K. You see two US savings bonds you can purchase. You can by $1000 bonds at 3%, or $100 bonds at 6%. The ROI of each is 3% and 6% respectively. The NPV of a $1000 bond at 3% is 5 times that of a $100 bond at 6%. If you chose NPV, you would have loaded up your portfolio with $10K of 3% bonds. If you chose ROI, you would have loaded it up with 6% bonds. Clearly, investing in the higher bond rate is better, regardless of the denomination of the bonds.
NPV can mislead you in another way- combine two lousy projects into one, and you get the sum of the two NPVs, and they go higher up in the rank. Their ROIs don't budge much when combined- the combined ROI is between the two. Combining the projects didn't make them better, so this is another indication that ROI is a better rule.
OK, those of you that remember your IE instructor saying something about NPV ranking will reflect ROI ranking are now scratching your heads. Here's the key to unlocking that dilemma: This is true for same sized investments, and is true on a portfolio level. If you looked at 10 different portfolios you could fund, the ROI ranking of the entire portfolio will generally match the NPV ranking of the entire portfolio. This is not true for individual projects, because they don't take into account the returns you can get with the remaining funds. A small project with a high ROI may have less NPV than a giant project with low ROI, but because more money is left over to fund other good projects in the portfolio, it is the better choice as you rank order the programs.
Larry, the analysis works for organizations that do not have resource constraints -- i.e., are able to do all the smaller but higher ROI projects. But what happens when resources are constrained?
To use your sugar water analogy, what happens when the organization cannot produce enough small mugs of highly concentrated sugar water to fill the barrel? Are they not better off producing a fewer number of large mugs that, although the sugar concentration is smaller, the quantity fills the barrel?
Mathematically, it is easy to show that the organization should add more resources to complete all those smaller, higher ROI projects. But in the real world, that is sometimes easier said than done.
Small or large, it is better to choose the high ROI projects first. I gave the small vs. large examples to show why NPV does not prioritize the projects correctly. You can also have large projects with large ROIs too. These are winners. iPhone, for example.
There may be some quantization effects at the margin- the next project on the list is too large for the remaining resources. Here you could shuffle projects a little. At some time, you are at the limit of the accuracy of the estimates anyway.
THis makes almost perfect sense. My earlier comment about using NPV to rank sets of projects can be illustrated by imaging that you only have 2 projects to fund--one with high ROI but low NPV, the other one with low ROI and high NPV. Again, you can't pick both. In this unusual case you'd want to pick the one with the lower ROI--just like you might pick the one with the lower concentration of sugar water, if that was the only way to fill (or nearly fill) the barrel. In the bond example, say you could only choose a $5001 bond at 6% or a $9999 bond at 5%. If those where the only choices for your $10,000, the later is the better choice. Yes, this is a contrived example, and usually picking the higher ROI projects are better. I would think that it only matters for the final project you pick, but I haven't worked through any scenarios to see if this is true.
Actually I agree with you. Ranking sets of projects is exactly the same as ranking different complete portfolios. Different terms for the same concept. Ignoring the granularity issue, filling a portfolio with the hghest ROI projects will deliver an optimal portfolio- it leads to a portfolio that has both, highest ROI and highest NPV compared to any other portfolio. Of cousre, with granularity of projects you may choose a lower ROI program that has higher NPV so you don't have resources doing nothing. At this level of debate, all sorts of other factors are considered in creating a proper portfolio. This brain teaser was just to isolate a pure financial look at the problem and illustrate a difference between ROI and NPV.
By the logic of this article, managers, accountants, and possibly the janitors should all study engineering. Then they would have the ability to understand why specific technical decisions are made and what are the implications for the product.
If you are really into ROI, what would be a better investment of the engineer's time, learning finance, or getting more advanced technical training in their field to make them perform better as engineers? Frankly finance people are less rare than good engineers, so unless you want to turn them all into accountants, financial concern should be left mainly to the bean counters.
There is a reason for specialization and why some people are into finance, and some are into management. One possible outcome of finance education in engineering is an increase in unsafe products, especially if they decide it is cheaper to allow x lawsuits/year than to increase the safety of the product. Of course the problem with that is you can never know what the cost is going to be. Maybe a good lawyer could bankrupt the company with one death or injury. By the logic of this article the engineer should also study law as well so that they can make informed judgements on the likely cost of unsafe products.
Also they should get training in political science so they know how to influence lawmakers to help protect the company and develop standards. Perhaps they should also study psychology and NLP so they can influence other people to accept their designs.
No I think finance people should stick to finance, engineers to engineering, and lawyers to the law. I think the world is diminished whenever a good engineer becomes a bad manager, or worse, a bad accountant.
Thanks for spicing up the debate. I'm surprised that no one has replied to your contrarian view.
Of course you are right: All employees do not need to know everything about a business. But knowing some things outside of your specialized domain can be advantageous- for your company, but especially for you. A lot of innovation occurs at the nexus of business and technology.
In my own case I took single semester cousres on intellectual property and industrial engineering. Those legal and financial courses laid the groundwork for me to contribute at a higher level than pure engineering, especially when combined with engineering. I've also noted that top engineers in development centers I've managed have a nice handle on the business as well, and are the ones most likely to become thought leaders in their organizations and advance either on technical ladders or management ladders. That's why I recommend engineers knowing the basics of business and finance.
But if you're happy with a pure technical focus- go for it!
David - The big difference between finance folks and engineers is that engineering creates things that are new. As such, a broader knowledge base, even outside of the field leads to a broader perspective, which leads to more practical designs.
Finance people track what's already been created, or already specified.
I don't think engineers need to be able to do detailed financial analysys, but an understanding of the principles can be helpful.
In simple terms, I believe it is ROI. NPV is used to measure how long it takes to payback an initial investment, and stops there. ROI is a continuous calculation, which measures the return in terms of the costs of the goods during each period of the exercise.
Break Even time is the preferred method to measure how long it takes to realize the payback of the initial investment, measured in months. NPV is the total value (returns-cost) of an investment. It is measured in dollars. ROI is a single measure of return, measured as a percentage. It can be compared directly to an interest rate.
regardless which metrics you use they are close to impossible to be predicted on advanced R&D products...in my 20+ years carreer I have seen hits and missed on ROI and break even points by 10x in each direction to the point that I consider them largely useless in the decision making process
@Larry, for question number two your math seems overly complicated.
"Here's how I would look at it. Calculate the increased gross profit over the original lifetime due to increased sales volume. Then subtract an entire quarter of the new gross profit. Ouch."
Wouldn't a simple area under the curve analysis work? Using the overlapping graphs you provide, subtract out the common area and then compare the area above that ccommon area to the area to the left of it. In this case I'd say go for the change - the top's much larger.
What am I missing?
And, btw, I do love this statement: "...since the death of the product is defined by the marketplace, and is fixed." Not only does that remined us all who's boss, it helps put urgency into perspective.
Yes, "area under the curve" would lead to the correct result, as long as the area we are measuring is the Gross Profit (Revenue - Manufacturing Costs). The chart I had showed revenue. If the two are related by a simple ratio, your math is still valid. If the feature changed the gross margin (the ratio of gross profit to revenue), then the gross profit curves would be needed as a substitute.
And yes, going for the change would be correct if my handdrawn figure was accurate, as you stated. However, I just drew the chart to illustrate the concept, any given project will be different.
"There is a reason for specialization and why some people are into finance, and some are into management."
The reason is the result of a type of intelectual "fractional distilation". The heavy brains sink to the bottom while the mostly empty ones float to the top and are directly transfered into government.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.