Some Thoughts on Overhead

In considering a 'better pricing system,' what role should overhead play? Is it necessary to figure out overhead costs? If we've gone through the trouble of figuring out overhead costs, how should we then apply those costs in a price calculations?

Defining Overhead

I'll define overhead for the purposes of this discussion as, "Business costs not being tracked by some other process." The most common "other processes" that are accounted for independently are materials consumed and "direct" shop labor.

This definition leads us to the answer to the question, "What should we include in overhead?" by saying, "Any and all costs that are not being allocated in some other way." If direct labor is part of our pricing system, then overhead should account for everything that is not ‘direct labor.’ If there is no direct labor element to the pricing system, all costs (besides material) are 'overhead.'

Quantifying Overhead

In calculating overhead costs, one method is to move from area to area and make sure costs in each area are included. Beginning with the office, make sure each person and each office expense is included. Next, make sure that all costs associated with running the shop are included. Finally, look at expenses for the overall facility and the business as a whole. An incomplete list would include accounting costs, advertising, banding/strapping cleaning, computers, equipment leases, insurance, markers, office schtuff, subscriptions, telephone, training, travel, uniforms, utilities, vehicles, and waste collection. Have we forgotten anything? By looking through the bills for the month we might catch some things we haven't accounted for. Our goal in this process is to figure out how much money it costs to keep the business open for any given period of time (a month, a day, and hour.)

The Value

The most important reason to do all this is the awareness we gain of what these expenses are, and the realization that these costs are related to time. If the overhead expenses totaled $50,000 per month and we were only open for business for 5 hours a month, we would only have 5 hours to recover, to "pay for," all those overhead costs. If we are "open," or more precisely "producing," for 200 hours per month, we have to somehow "earn" $250 per hour (beyond labor and material)  we want to pay for that overhead. This is the reason that the most logical way to apply overhead is based on the amount of time the job will take to produce. The argument goes, "Since overhead itself must be recovered based on how many hours the business is producing each month, the only logical way to assign overhead is based on the time it will take the company to produce each job."

We will look at how to do that in later articles.

A Better Pricing System

I've visited a sizable number of component manufacturers over the years and one thing that I've always found remarkable is the wide range of pricing systems employed. To say, "There's no standard pricing model for the industry" is an understatement. Quite a few managers have expressed feelings ranging from ambivalence to outright embarrassment, many saying "It certainly could be better." The goal of this article is describe what "better" might look like.

Right and Wrong

Let's begin with the assumption that there is no right and wrong pricing system, and rather than debate the merits of competing systems, we'll instead describe what we use these systems for. We’ll also describe some desirable characteristics of any pricing system, and then compare those ideas to our own pricing system to see how they measure up.

Features

Here are the basic things I think a good pricing system would deliver:

·         Tell me what price I should give to the customer (naturally!)

·         Tell me the point below which I would start to lose money. I want to know, "How much 'room' do I have?"

Those are the two big ones, but since I'm aiming high, I'd also like it to do a little more for me:

·         Tell me how long it will take me to build. This would help me know how it will affect other work in production and how quickly I can deliver it.

Other characteristics of a good pricing system

A good pricing system is logical, explainable, understandable, repeatable and consistent.

I don't want a system that "works" but no one knows why - it's just mysterious voodoo. Why? If I don't understand why it's working, I won't know what’s wrong or know how to fix it if it starts 'not working.' A consistent, repeatable system would be one that produces the same results with the same input, and is not dependent on a person or ‘impossible to define’ criteria.

Let’s describe a system that’s the opposite, that might work, but not have these characteristics. The statement “This job seems like it has about a 1.7 difficulty factor” might be used in such a system. But if I showed you that same job a week from now, would you still tell me “it’s a 1.7?” On what basis are you arriving at “1.7” as opposed to “1.6?”

Take the Test

So I'll invite you to apply these ideas to your pricing system and see how you make out.

“In considering my pricing system…”

·         Does it tell me what price to give the customer? (Or does it tell me a number that I have to do more operations to in order to arrive at the price I give the customer?)

·         Does it tell me where my ‘break even’ point is?

·         Does it tell me how long it will take my shop to produce?

·         Given enough time, could I explain it to another person?

·         Is it logical; does it "make sense?"

·         Is it consistent and it is used consistently?

If the answer to any of the above is "No," I submit that "it could be better." We’ll talk on ways to go about finding a better system in future articles.

Software Meeting

Every component manufacturer should hold a ‘software meeting’ as a regularly scheduled event. The software meeting is a recognition of the importance of design and management software to the organization and a proactive attempt to use that software to gain the fullest advantage for the organization.

Why hold a software meeting?

The software that plays such a significant role in our businesses is complex and ever-changing. How do take maximum advantage? We have to invest time as a company to review all aspects of our software use. What’s new in the latest release? Should we be using it? How does it work? What problems do we have? What do we most need that we don’t have? These are all questions that are best answered in a group setting, with everyone participating and contributing – even the boss!

How often?

At least once every quarter, but it also makes sense to hold one every time a software release is announced. For MiTek customers this means five time a year. This may seem like a lot, but the features and fixes are coming fast, and the only way to stay on top is to have frequent group reviews.

Proposed Software Meeting Agenda

This meeting, like all meetings in the organization, needs to be time-boxed and laser-focused.

Feature Review – Two weeks prior to the meeting the design manager reviews the latest Release Notes and assigns one (or more) new features to each designer to research. Each designer comes prepared to show the feature, describe what its intended uses are, and offer an opinion as to its value to the organization.  A general discussion then decides if the organization is going to begin using the new features and what steps are needed to implement it. The group should be mindful of how to use the feature to the organization’s best advantage and how to do so consistently. This means everyone is on board, doing things in the same way so as to deliver a consistent product to customers.

Problem Review – What’s slowing me down or holding me back? What’s annoying me? What do I wish I could do that I can’t now? Every designer and software user should be called on to contribute. The group should attempt to expose as many of these problems as possible, Having participated in many software discussion like this, you can expect that between 25% and 50% of the problem raised will be solved by other software users who have simply learned (better) how the software works, or developed tricks or workarounds that take much of the sting out of the problem. The others should be noted on a “Problem List” that is then forwarded to the software rep.

Idea Time – What could really make us more productive? What would we like to know that we don’t know now? What part of my job would I most like to unload, and why? These type of questions frequently touch on both software and business processes and the Software Meeting is a good time to talk about improvements in both. It is essential that managers participate and talk about the information that they need to allow them to manage better. Every organization could improve if it knew more about itself, particularly about performance. Can we get that data? How? Again, a software wish list may be the result – a list that should be shared with the software rep. Alternatively, why not invite the rep to the meeting?

The software being discussed should ‘cover the field;’ it should not be restricted to one vendor. In many companies the ERP software plays a key role, in others, several different vendors provide design and estimating software. Its best to look at the overall picture to look for duplication of effort or discovering ways to integrate the different solutions.