IRR

You are currently browsing articles tagged IRR.

Over the past year I’ve had several opportunities to spend some time working with MBA students at two local business schools.  Judged a business plan competition at Daniels (Denver University), and then led a market assessment and am also a mentor for Leeds (University of Colorado Boulder).  Got to hang with MBA students and hobnob with professors.  All  heady stuff, with a dose of irony since my business degree is from the school of hard knocks and managing real P&Ls.  So I learned quite a bit myself, and hopefully gave back a wee bit too.

What engineers can learn from MBAs:

1. Every decision should include a financial aspect.  Spec a part; look at the cost.  Design a process; look at the cost.  It’s not good enough just to say “hey this part functions best.”

2. Look at everything from a total cost of ownership point of view. It’s not just piece part cost, it’s yield, it’s field returns, it’s overhead, it’s inventory tied up on the water.

3. Understand cash flow.  This probably should be number one, but it’s tough.  If you buy a part in China, have it sit in WIP in a factory for a month then two months on the water, that makes a difference.

4. Learn to calculate IRR.  Use it to make financial decisions (1), calculate total cost of ownership (2), and to do an IRR calculation you gotta understand cash flow (3).  Hint: IRR = Internal Rate of Return, an ROI type calculation, but better suited for development type projects with uneven cash inlays and outlays.  It’s the inverse function of NPV = Net Present Value.  And it’s in Excel, although it can be tricky to use (it’s an iterative calculation so sometimes it needs a seed…).

What MBAs can learn from engineers:

1. What a BOM is (Bill of Materials); what an ECN is (Engineering Change Notice); what EOL is (End of Life).

2. Understanding the age old engineering adage: On time. On budget. Works. Pick Two.  Engineering is about compromise. And Murphy was an engineer.

3. What a product development schedule really entails, and how to budget and schedule for the real world.  Engineers know what it really takes to get a product out the door; they know that real product development involves iterations; and that novel products and technologies take a lot of efforts.  Yes DFMEAs and validation testing cost money up front, but they decrease the total cost of ownership. See above.

4. That engineering is very often about good enough; that no product will be perfect; that compromises are in order. And that saving money does no good if the dang product doesn’t  function properly

Of course there is always the option for engineers to just plain enroll in a b-school, but not all of us have the luxury of the time and money to do so.  But that doesn’t mean we engineers shouldn’t learn the key points.  And maybe teach an MBA a key point or three about engineering as well.

Chuck

 

Tags: , , , , , ,

In this dreary economy it’s natural for companies large and small to look for every way possible to cut costs. Organizational fat gets slashed, bill of materials (BOM) costs are scoured, vendors are beat up or replaced, and off-shoring is investigated.  Products can be redesigned to save costs; designs and process can be optimized for manufacturability (shameless plug: Zebulon Solutions offers such redesign and DFx services). And at one level, as long as one is looking at holistic cost of ownership with ROI or IRR factored in and appropriately adjusted for risk, these are good steps.

But it’s not all about cost.  At the product level its also about functionality, branding, reliability, performance–really the right metric is, pardon the cliche, bang for the buck. A poorly designed, cheap product will not sell just as surely as a good, overpriced product.

The right approach is that cost should be a factor in every decision, but not the only factor.  We’re working with a company right now whose 3rd party design house choose a cheap clone of a high performance IC for their new design.  The product functions, but it’s power dissipation, a key spec for this class of product, is way above marketing’s target. It may be solvable, with enough engineering thrown at it, but that also has a cost from an ROI / IRR perspective.  Or it may be that there is indeed a trade-off here of product cost vs a performance spec, in which case management will need to make a tough, yet informed decision of how to resolve.,  Maybe cost will win, but then again maybe not.

Cost is one element, a key one, but it’s not the only element.  Just as the days of cost is no object design are long since past, the days of low cost no matter the result are also numbered.

Chuck

Tags: , , , , , ,

It’s shockingly easy for guys like me to get up on our virtual soapboxes and basically say, “You gotta do the right thing.”  Let’s face it—we all want to take the high road; we all thinkthat we do take that road more times than not.  So wanna be blog-meisters like me can easily say “thou shalt test more” or “thou shalt conduct design reviews” or whatever and it sounds good, albeit a bit pompous.  But let’s face it: business is, for better or for worse, about making money.  So when we make decisions on productization—or most other topics—we gotta do the right thing  and make money.

So to the question at hand—how do we make the right decisions on investing (incurring expenses) on productization?  The answer can be summarized in two words: Risk and IRR.

Risk is easy to understand but tough to quantify.  In general productization efforts lower risk.  Examples of risks that proper productization efforts can mitigate include:

  •  Risk of delays
  • Risk of field failures
  • Risk to brand / image
  • Risk of damage to property or person
  • Liability risks
  • Inventory risks

Examples of productization efforts that fundamentally reduce risk include:

  • Design Validation Testing (see our earlier Productization blog on this topic http://www.zebulonsolutions.com/productizationblog/?p=50/ ), which can mitigate the risk of field failures, property damages, risk to life and limb, and liability risks.
  • Production test development basically mitigates the risk of test escapes that can lead to field failures, returns, and damage to brand, as well as potential risk to property, life and limb
  • DFx reviews address schedule risks, can mitigate inventory risks if proper attention is paid to Design for Supply Chain, etc

The other topic is IRR—Internal Rate of Return—is not so easy to comprehend but easy to calculate.  IRR is a form of return on investment calculation that better handles non steady state conditions than traditional ROI or ROIC calculations.  IRR calculates the return from a series of disparate cash flows—often a negative cash flow representing monthly investments in say a cost reduction redesign and then positive cash flows in the term of lowered cost in production.  Sounds complicated but fortunately spreadsheets can do this calculation easily (almost easily—it’s actually an iterative solver at least in Excel so sometimes needs help to converge, and there is the tricky issue of salvage value.  I can expand on either of these offline if anyone is interested in the details…).  IRR is thus a way to quantify the benefits received from investments in productization.  IRR can deal with time easily by using appropriate time units—months, quarter, weeks, years.

Then the really cool part (I show my age—does anyone use “cool” anymore?)  is one can combine both risk and IRR by using an expected value methodology for calculating IRR.  For example, if one can reduce the risk of field returns by say 10% by doing extensive Design Validation Testing, then one should calculate an IRR using 10% of the current cost of field returns as the payback. In fact even for mundane tasks such as cost reductions the return is never 100.0% certain (Murphy’s Law if nothing else) so one should really use expected value, in such cases as a derating factor,  in any IRR calculation.

The tricky part of course is assigning the right costs, the right risks, the right expected values and the right time frames.  But even if the calculation is not perfect, it’s far better than nothing or the omnipotent finger in the air.

Chuck

Tags: , , , , , , , , ,