The Code, The Client and The PIClist

This is a compendium of several threads that occurred in the Fall of 2003 on the subject of business practices.

1. Customers
2. Contracts:
3. I Canna Change the Laws o’ Physics, Captain: Bidding Time and materials
4. A Cheap Customer if Worse than No Customer At All:
5. YAPGI = Yet Another Penniless Garage Inventor. How to sort real customers from dreamers
6. Did the Butler do it? What about hiring paid staff:
7. Borrowing Money, Using Bank Loans, Mortgaging you home, borrowing money from your uncle for startup capitol, loans to get through cash flow crunches, loans for new equipment.

Customers

Q. Does anyone have any learned experience they're willing to share regarding getting started as a small design company (a one-man operation) - particularly in the UK? I'm confident in my technical abilities, but what's the best way to get in contact with prospective clients?

Wouter van Ooijen:

Main experience: contrary to what you might think the number one factor in starting your own business is not technical qualities but existing contacts with potential clients. If you don't have such contacts think twice (thrice, or how often it takes) before starting your own business.

What Wouter said is VERY important.  I have had several friends that started there own business. The ones who succeeded were the ones who were doing work on a "hobby" basis first or working for someone else doing it before they went into business for themselves. The ones who had the idea that "I am good at this and nobody else is doing it". All they did was lose money starting their own business.  Basically "Have the clients before you start" Q. Speaking of finding customers, has anyone had any luck with using on-line technical forums as a source of customers? I'm thinking of starting RF design consulting, and was wondering if participation in some of these forum's would help attract customers. Something simple, like a home page url in my signature is what I'm thinking of. I know lots of folks on the PicList consult, and I was hoping to get their opinion.

Tom Deutschman of Wizbang Designs, Inc. Spokane, WA: I've picked up a few customers this way because they were reading the discussions in order to find someone to help them. More importantly I've learned much by both participation in and reading the discussions.

Mike:

I've gotten 5 in just a year or so. 1 RF, 1 analog, 1 PIC, 1 mixed that's on hold for more funding, and 1 software. Then there's another one WITH funding but the guy's dragging his feet. One guy found me by lurking and e-mailing me directly. 4 others by me responding to requests for free-lancers, and the (very small) software job came up out of the blue when I mentioned ActiveX in an EE or CAD discussion. I'm doing that as a favor in return for a license key to that guy's product, which he already gave me for maybe 30 seconds worth of work. I may never even use his app, but what the hell. No ads, web addresses, nothing. As soon as I'm geared up a little better lab-wise I might actually try to find work. Find someone I can trust to help run the biz I've been in for 12 yrs. Good Luck - if you're the guy who said something about hoping skill would figure in, I can point you to someone who will give you a dissertation on the fact that skill won't get you squat without luck. Spehro (hi!) knows who I mean if his memory's as good as I suspect. Hey, look at how many incompetent managers and politicians there are. Skill? Luck? I've picked up a few customers this way because they were reading the discussions in order to find someone to help them. More importantly I've learned much by both participation in and reading the discussions.
^^^^^ last sentence - muy importante ^^^^ I went ahead and bid on a job while others in the group blabbed on about specs and crap and considerations and possible solutions. I even picked up a hint on what to charge! I guess they just wanted to talk :-) In fact, they were talking as if the OP wasn't even there. I took it all in while I was querying the potential customer, shot him a price, and got the job. One customer got no group response at all and rejected all email responses but mine because other respondents appeared to be mining ideas.

2. Contracts:

Mike Harrison:

Once you have customers (your first priority) you will need contracts (your second priority IMHO).

Many consultants work without contracts, figuring that if they are gonna screw you they will do it anyway.  Other people call these types fools, but there are proponents of each method.  I won't argue about it but I have a standard contract. In any case you need a clearly stated written scope of work for each project that outlines the deliverables, the fee, when the fee will be paid, and what happens if it is not paid on time, and which deliverables will be withheld against payment.

Contracts can work both ways. It can be hard for them to pin any liability down to you if there isn't a formal contract specifying exactly what your responsibilities were....

I usually state something like "I reserve the right to withhold design files (source.object code, PCB artwork etc.) and/or support if any invoices are overdue". Where possible, supply code-protected devices for testing, invoice when the customer has approved them, and hand over code when invoice is paid. This can also be a good way to speed up payments.

You may need Professional Liability insurance just to operate at all. In electronics, this is often not done in the US. But Professional engineers that work on public buildings, such as structural engineers, absolutely must have liability insurance or their clients run away screaming. My answer to this is something like : "The customer is responsible for testing the (code/hardware etc.), and determining its suitability for purpose. Significant time spent fixing bugs discovered after customer has approved prototypes etc. may be chargeable."

John:

I could write books and bore y'all to death with my business background. 20 years of it, pleased as can be, these days. In days gone it was a different story...

Be prepared for `upsets', like customers with endless promises of 1. Repeat orders of product (never comes). 2. We owe you, but you're a small outfit so it can't hurt you to wait. 3. Sure, you've finished this fandangle the way we asked, but it's         no use to us if it doesn't have these mods done first.

As others have said, I suppose the best insurance is to have committed customers in whom you have confidence.

That's to start off with, then ask yourself `Does this customer expect me to work exclusively on their behalf, on products meant for them alone?' `What will their attitude be if I find others who would like to buy the finished item from me?'   (naturally, these folks are their competitors).

I've concluded there are two extremes in financing the development of a new product. Case Alpha. Customer pays the lot up front, no questions. He's confident of a return. Case Omega. Developer funds the project, hopes to sell end product & make profit.

In case Alpha., customer owns everything & scores providing the product takes off. In case Omega., developer owns the product and wants only to sell it a price point that gives him the maximum return over a chosen period, life-of-product or suchlike. Down the list of priorities comes the welfare of the original client.

Judge your customer carefully, see where they fit in this spectrum. Do *they* have a proper understanding of these issues? Both of you can easily be in a cuckoo-land of misunderstandings before you even start.

Sean Alcorn - Avion Sydney:

I have been dealing with Asian companies for the last 20 years - buying from, selling to, working for - you name it. In cases of buying and selling the procedure is pretty much the same;

1. Screw around for ages trying to work out what is wanted
2. Purchase Order is placed
3. Proforma Invoice is raised
4. Corrections made - Goto 3.
5. Money is sent electronically (in all cases up to say US$20,000)
6. Money is received (and confirmed) into bank account
7. Goods are shipped.

For orders above the range of say $10~20 000 then a "Letter of Credit" is usually raised.

If you were dealing with any other Asian country other than Korea, I would advise you to operate *exactly* this way. However, for some strange reason, *every* Korean supplier I have dealt with has got to step 4 and shipped goods to me. They may have known me for years or just one week! And we are talking some big dollar orders.

So in my experience, Korean companies tend to operate on more of an element of trust than other Asian companies. So if they are an honest company and you say "Send me the money first, and I'll send you the code", you may offend them and risk losing the business and future work for them.

At the moment, I can think of the following options;

1. Get on a plane and make a bit of a trip out of it. Visit their operation, get some ideas, make some suggestions. Go to dinner (watch out for those canine dishes), have a few drinks and then have a formal handover of the software a day or two later. Have them have a bank cheque prepared (drawn on a US Bank) and hand over a CD-ROM with the code. Have them have the tools ready to burn a set of chips and confirm they are satisfied.

2. Another option would be to ask for a "Letter of Credit" for the software. This is generally used for containers of goods, but I see no reason why it could not be applied to a CD-ROM. They raise an L/C which you take to your bank, you send the CD-ROM by FedEx to them, you submit documents to your bank (including the FedEx Airwaybill) and you get paid.

3. A Bank guarantee. They simply raise a "Bank Guarantee" (preferably drawn on a bank in your country) guaranteeing that they will pay you X by a given date, provided that you supply X by a given date. The bank simply MUST pay your demand for payment unless they can prove that you did not supply what you said you would. - Very common in international business, and not as expensive as an L/C, but fees vary.

4. Could Fedex (or the likes of) offer you a COD service? You send them a CD-ROM, and the Fedex guy does not leave it unless he leaves with a cheque. - I would only use this for small amounts of money - if the service is available at all - I am not sure.

I would go with option 1 and tell them you are a vegetarian. :-)

3. I Canna Change the Laws o’ Physics, Captain: Bidding Time and Materials

Lawrence Lile:

Scotty:   "I canna change the laws o' physics, Captain.  It'll take at least 3 hours to get the warp drive back online"

Captain Kirk: "We don't have much time, Scotty! The Klingons are gaining on us!"

... One and a half hours later ...

Scotty: "Captain, the warp drives are back online!"

Captain Kirk: " Warp factor 8! Good work Scotty, how did you do it so fast?"

Scotty" I always tell my Captain twice the time I think it'll take. "

This is from memory, but the gist of it follows a script from a Star Trek Episode.

Engineers, always remember Scotty's rule and quote projects about double what you estimate it will take.  The administrative details, change orders, compiler bugs, contract negotiations,   and 18F parts that won't run at 20MHz will eat up the rest of the time. Mauricio is on target with doubling his time estimate.  Perhaps Wouter is more experienced and could do the job in less time. Or perhaps poor Wouter would lose money on this one! (I would expect it is the first case. )

If your client says your quote is too high, then your client is probably a cheapskate. Many managers try to talk contractors down with these tricks. This is just bluffing. I treat that as a red flag and a warning sign that they may not be prompt payers at the end of the job. Two or three red flags and I'll give them a "no quote".   I have dealt with hundreds of contractors and have never told one that his price was too high, at most I will tell them what their competitors are charging and leave them with the facts.

My lawyer asks for 2/3 of the fee up front when he takes on a job for me, so that is what I charge with customers.  2/3 up front on signing of a contract, 1/3 on delivery. Subsequent billable hours after that on an hourly basis.  Goofs fixed for free. Any project after the final delivery that will take more than an hour or two I treat as a new job and send a proposal.  The up-front money weeds out the mad inventor crowd, the cheapskate crowd, and gets you doing business with more reputable customers.   The contract spells out intellectual property issues and limits my liability.

I know other consultants that just work on verbal contracts. If the client's word is no good, he is going to screw you anyway, and he has more expensive lawyers, contract or no contract.

Be ready to sever the relationship with a new client early if it looks like he is not going to be a good client.

           

Oh, i estimate 1~1.5 months of developing time.

Months...?? 1-1.5 Weeks maybe, tops.

Well, that brings up another issue. I'm and independent worker. I might be working max with 1 more person, helping on the software stage, but the hardware and firmware will be done entirely by me. The time is bigger than estimated, but not so much. Lets see.

2 days to complete the hardware design and defines which pin do what 7-15 days to have a PCB board for testing (meanwhile I can write the software) 1 more week to finnish the details

That’s about 3 weeks, so I double this time for security reasons....

So?

4. A Cheap Customer if Worse than No Customer At All- Red Flags List:

Usually, if a potential client tells me my quote is too high, I offer to redo it. The new quote is almost always higher ;-). I have found this method to be a great filter for eliminating potential clients that would cost more money than the profit on the project. My experience has shown me that sometimes it's more profitable to turn down certain clients in the long run.

Edward Gisske, P.E. Gisske Engineering 608-523-1900 gisske@offex.com:

Having been in the consulting/independent engineering biz for about 30 years, I can attest to the observations of Lawrence as put forth below.

A few more:

A cheap customer is worse than no customer at all.

A customer that doesn't understand the technology or the magnitude of what he is asking is worse than a cheap customer.

There is a genetic flaw in software types that makes them assume that they write perfect code the first time, will have to do no debugging, and all the algorithms will work as imagined. *None* of the above is true. Read Fred Brooks' book "The Mythical Man-Month" or any of the "Programming on Purpose" columns of P.J. Plauger in Embedded Systems Journal or Computer Languages for some additional insight. Fred says that coding is about 15% of the effort when writing software. Debugging is 55%. He was talking about developing the IBM 360 OS in his book. Real-time programming of micros is *much* harder.

Basement inventors are the scourge of the business. They are the most demanding and the least reasonable of all clients. They are inevitably so wrapped up in their idea that they have lost all perspective with regards to the time, money and effort required to make their fantasy real. Their understanding of the technology is usually shallow and they have mentally dismissed all those pesky issues like agency approval, manufacturing, distribution, marketing, warranty fulfillment, etc. as trivial items that will all work out.

"It will just take a little work" is a huge red flag. Another is "I couldn't get along with my last engineer". Yet another is "I have this great idea. You make it work, I will sell it and we will share the profits"

Doing work on speculation is better than Atkin's for losing weight. You will seldom eat if you do speculation.

Working with flint axes is for savages. Writing code without an effective set of tools is also. You cannot write code efficiently without an in-circuit emulator. Yah, I know, there are some "churn and burn" heroes out there. They aren't doing it for a living, however.

Marketing geeks are morons. They learn the technology from reading the magazines that are in the seat pouches of airplanes. They inevitably want their product wet dreams turned into reality faster than is humanly possible. They play games like the old "We need it for the trade show next month" gambit or "We put it in the catalog and now we need to design it." or " We have been talking about this product for months and have sold a bunch, now get it started and finished by next week."

So there!

Mike Harrison Wrote:

I would amend this by adding that this only applies to customers who aren't prepared to learn about the above things. A customer who knows little but is prepared to admit it is fine. In some cases it can even be good as they take anything you say as Gospel. Conversely, a customer who thinks he knows it all, but doesn't is even worse.

There is a genetic flaw in software types that makes them assume that they write perfect code the first time, will have to do no debugging, and all the algorithms will work as imagined. *None* of the above is true. Read Fred Brooks' book "The Mythical Man-Month" or any of the "Programming on Purpose" columns of P.J. Plauger in Embedded Systems Journal or Computer Languages for some additional insight. Fred says that coding is about 15% of the effort when writing software. Debugging is 55%. He was talking about developing the IBM 360 OS in his book. Real-time programming of micros is *much* harder.

I'd add that every hour spent in design saves at least twice as long in implementation and debugging, especially for projects that are likely to be expanded/changed later on. In many types for work, doing a good, detailed design first makes the coding much quicker, easier and as a consequence less prone to bugs.

Similarly for PCB layout (manually routed 1 or 2 layer boards) - time spent in careful placement is more than saved in routing.

Working with flint axes is for savages. Writing code without an effective set of tools is also. You cannot write code efficiently without an in-circuit emulator. Yah, I know, there are some "churn and burn" heroes out there. They aren't doing it for a living, however.

I'd totally agree, but if you must live without one, at least make sure your debug-burn cycle is as fast as possible, and ideally debug on a larger part that allows extra pins & resources for debug info.

Similarly, a decent scope (digital, with deep memory) will pay for itself very, very quickly for almost all types of embedded work..

Tim McDonogh wrote:

My additions to the red flag list...

"All we want it to do is..." frequently accompanied by not so much as a scribbled list of features.

A client with only a general idea who is not willing to pay for the time it takes to define what the thing will or will not do.

Suggestions:

1) Don't include features unless they specifically ask for them.

2) In many cases your perspective client has come to you because they realize they don't have a clue about this piece of the development. In these cases agreeing on a spec may help you legally but you can still be in for a lot of hassles. One way to put the client at ease and give yourself some solid metrics for success is to work with the client and agree upon how the results of your work will be tested to determine that it "works." This lets them define your part in terms they hopefully understand and if they ask for price justifications you can explain based on what they have told you needs to happen for it to work acceptably. A written acceptance test that defines stimulus and required results makes a nice target.

Alan B. Pierce wrote:

My additions to the red flag list...

"All we want it to do is..." frequently accompanied by not so much as a scribbled list of features.

Yeah, just been there done that, worked from the back of a cigarette packet circuit. when delivery was getting close it became obvious that the gear I was developing as a dummy load for them was to become a complete calibrated piece of test gear. They were told in no uncertain terms "No Way Hosea"

1) Don't include features unless they specifically ask for them.

This was part of my mistake. The other trouble was they had there own feature creep in mind as well. :)))

2) In many cases your perspective client has come to you because they realize they don't have a clue about this piece of the development. In these cases agreeing on a spec may help you legally but you can still be in for a lot of hassles. One way to put the client at ease and give yourself some solid metrics for success is to work with the client and agree upon how the results of your work will be tested to determine that it "works." ...

To help over this bit, is it worth developing the end item in a modular manner, so that a certain agreed set of minimal functions is provided as a first step, and then a re-evaluation of the project done, to see if the continuation should go ahead? Has anyone worked in this manner? I am assuming that when doing the code for this that suitable hooks would be put in the code, possibly by using dummy routines that could be expanded during the next stage.

Jim Tellier wrote:

That's all true, but there's one more red flag that only surfaces once the project is underway (or nearly completed): "can you add [whatever extra feature they happen to think of that day]? It shouldn't be too difficult!". This kind of input, whether it comes from a client, boss, marketing guy, team-mate or whatever... is often the kiss of death to a project.   My contracts always contain a clause that says "quote is based on the (attached) agreed upon specification; any changes to the specification after [date] will result in a revision of the quote, and possible termination of this contract".   It does wonders for my sanity and ability to deliver!

Mike Singer wrote:

Another [bad] customer in my experience - The customer's manager, ex-developer, who tried to work out the task, semi-succeeded in it, muddled desperately on it; and for this reason finally turned into manager to govern my participation to solve this task.

After having spent two hours discussing why his solution is better than mine, we prudently stopped our cooperation. (The one-sided discussion or monologue: he talked, I listened to him)

Mauricio Jancic Janso Desarrollos Microchip Consultant (54) - 11 - 4542 - 3519 wrote:

Have one of those recently, and one day I found myself listening why, that modification we was trying to make to the predefined spec, wasn't that hard to make....

He was a system engineer who once programed a MCU (hobby) he even explain me how to make the modification, even with out any knowledge of the program or language I was using.... Very interesting monologue that I know will end with me saying, sorry, cant do it with out re-quoting.

Richard Kendrick wrote:

OK, fair enough. Based on Mauricio's initial design spec, I made the following assumptions and breakdown for my time estimate.

• shift register module: 4 hours
• low level LCD routines for 2 x 20 display: 16 hours (assumes I don't have these prebuilt, which I do and will reuse)
• push button routines: 24 hours (assumes lots of code based on context sensitivity)
• encoder routines (assume rotary encoder) low level: 16 hours (assumes I have to build these, but knowing I can probably get something cloneable off the Internet)
• assume 20 menu screens with each screen customer defined: 5 main screens with each main screen having 3 sub screens menu
• navigation module: 16 hours
• code to support each screen: assume 24 hours per screen, 20 x 24 hours = 480 hours
• because a 10 page specification is provided, assume context sensitive calculations of some sort based on user input values and results to be saved and transmitted through RS232 interface
  calculation module: 36 hours
• user program module: save and recall: 4 hours each = 8 hours
• low level RS232 interface module: 16 hours (assumes I have to build these, but knowing I can probably get something cloneable off the Internet)
• high level RS232 module: 32 hours
• DS1307 routines: 24 hours (never worked with this chip, research time included)
• pc control program (probably Visual Basic for simplicity): 40 hours
• schematic creation (assume AutoTrax, Eagle, PADS or equiv.): 8 hours

Initial time estimate: 4+16+24+16+16+480+36+8+16+32+24+40+8=720 hours

I always double the initial time estimate to cover the usual unforeseen stuff, which brings the adjusted estimate to 1440 hours.

Experience has taught me to add what I call the piss off factor into the final estimate. This number starts at 1.0 and depending on how things go, stays the same or increases. The final estimate is equal to the piss off factor x the adjusted estimate.

Please keep in mind, it's not my intention to take advantage of a potential client, or his naiveté, but sometimes you can tell that the customer will be very difficult to work with. That usually translates into a higher cost for the customer. And, as I said before, sometimes you just have to walk away from certain jobs.

Yikes. At the doubled estimate, that's 36 x 40 hour work weeks. That's over 8 months!

What I've found is, unfortunately, it really ends up that way. When I'm actually working on the project, it is about 80% planning and about 20% coding. The other time is inserted to handle dealing with the customer, suppliers and the other details associated with the project.

The time estimate is just kind of answer I'd give without really having a customer provided spec to work from. A formal quote would probably be much less, but could be more depending on the circumstances.

BTW, I'm not criticising you or anything, just surprised at the times once they add up.

It gives me a jolt every time I do it, too!

I do love the piss off factor idea!

It has saved my derriere many a time ;-).

Edward Gisske, P.E. wrote:

I was remiss in my initial "red flag" list:

"Oh, by the way..." is a feared lead-in. Marketing types fancy themselves as creative individuals that are constrained by neither the bounds of gravity, power consumption, or in some cases reality. I generally write in a product definition phase for any project. This I do at a fixed price. All other phases of the project are given budgetary numbers that are recalculated after the definition phase. The sentence "Any change to the specifications as defined in phase one will require a requote" is prominently featured in the phase one final document. I then trot out my stock sermon about how the price of infinite flexibility in a design is never to market, followed by bankruptcy. It is obvious to most folks, but there are a surprising amount of rookies out there to which it has never occurred. In my experience, feature creep has killed more products than all other reasons combined.

Bozos with a meager grasp of the technology, but a *need* to put their stamp on the design are a little weird to work with too. I did a design for a company about 15 years ago where the president (an ex-county executive political type) decreed that the design had to have a serial port. When asked why, he said that "Everybody has one on their product". When asked what it would communicate, he said "I don't know, but we have to have one". The customer pays the bills, so I put one in the design. It was informally labeled "The President Jonathan B. B***y memorial serial port". Every one of the products manufactured since has a serial port. There has never been a line of code in the product to support the port, but it is there and the pres is happy and secure knowing that it is there. There is an old axiom in product development: "The VP gets to choose the color". I wish they would confine themselves to that.

In another case, the product manager gave the decree that he needed the security of portability for the code in his product, therefore it must be in C. This product ran a couple of linear actuators in and out with a low end PIC. When it was explained to him that a 12C505 was not the best vehicle for C coding, he would have none of it. He now has his code in C and he is secure. It also cost him substantially more for a program that could have been done in a page or two of assembler written on a bar napkin.. He is, however, rapturous in knowing that when the '505 gets replaced with a PowerPC G5, his code will compile for the new chip. It won't work, but that doesn't matter.

I could recite war stories forever about the problems that occur when a customer starts mucking with the user interface. Unlabeled tri-modal pushbuttons with cryptic pictogram hieroglyphics, warning leds which flash when an alarm condition is true in one mode, but also flash when all is well in another mode are just the start.

Aaackk, my mind is exploding!!

\* Philosophical Rant ON:

There are some things that it is necessary to think through carefully when designing a user interface for an embedded micro product. The PC geeks have it easy. A CRT and a full keyboard? Way too plush for us bottom feeders. What we have to work with is almost always an absolute minimum set of switches and indicators. It is necessary to use them in completely obvious fashion.

There is a set of things you need to do to make a successful user interface:

**Any control input must have visual, audible or (less preferred) tactile feedback.

**Modal indicators should be avoided. Indicators should always mean the same thing, regardless of what mode the product is in.

**"Switch function overloading" should be minimized. For instance, a switch that does one thing if just popped and another if held for a second or so. It can be tricky to get the timing right, as people push buttons in different ways. The real problem, however, is how to communicate just what that button will do to the user. Not easy....

**If using an alphanumeric display with nested menu items, make sure that the user can back out of any menu decision. The method used to back out should be blindingly obvious. Always back completely out of a menu branch before allowing entry of another one.

**No hidden modes, except for test purposes. The user needs to know what the button will do before he pushes it. Universal TV/VCR/Sat remote controls are particularly skanky with respect to letting the user know which device he is controlling. Test modes actuated by combinations of buttons should not be easy to do, so the user doesn't stumble into a test mode.

**About 15% of the male population is Red/Green color blind. Be careful what you do with bi-color leds.

**There are more, and I invite others to contribute.....

More to the point, none of the above is particularly difficult to puzzle out, even without formal training. Except to marketing geeks! They seem always to feel that they have their finger directly on the pulse of the consumer as far as how the device ought to work. So they screw with the interface and turn it into a dark and stormy goo. Drives me nuts! It is a constant fight to fend off the heathens. Particularly pernicious is the almost irresistible urge to add more features than controls/indicators to make them work. This is why we have the same LED having different meanings for ON/OFF/FLASH SLOW/FLASH FAST.....Ugly!

I usually have to fend them off by bringing in a "Person off the Street" cold to see how they interact with the interface when tasked with making the device do something. Even then, ego often gets in the way of science and some real interface abortions are foisted on the planet. Think about the venerable VCR or microwave oven flashing 12:00 or the car radio buttons that are not programmed to anything...

It is a lonely fight.......

Rant OFF*\

Responses to Lawrence Liles Questionare:

Bob Ammerman RAm Systems

1. How do you deal with health insurance? Just pay a lot? Have a spouse with another job where insurance is available?
Just play an awful disgusting horrific lot.

2. Is roller-coaster pay a problem for you? Boom and bust business?
Not for me too much. But it drives my wife nuts. I've been in business for 20 years now and (praise God) have never been at a loss for work.

3. How about long hours or travel? Does that stress out your family?
It used to. Then I put my foot down and got smarter by learning how to say 'later' rather than 'yes' to some client requests.

5. What specifically does a consultant need to have around besides a computer, a scope, some hand tools, a compiler, an Eprom burner and an ICE?
Depends on what they are working on. Whether they are primarily developing HW or SW or working on integration. I used to do all SW, but in the last several years have branched out to the HW and integration world.

6. Do you have a standard contract?
No. This is probably a mistake on my part.

7. Do you have a home office or a remote office? Does the remote office allow you to leave the job behind?
I have I home office. But I spend a lot of my time at client sites. Many of my clients are in the computer/software/systems integration business themselves.

8. How many hours a week do you spend working - 50? 70?
I try to keep it under 40, including non-billable time for keeping up on technologies. However, there are times when I am working under deadline when it goes way above that.

9. How do you advertise your business - word of mouth? Long term customers? Bingo cards? Ads in Circuit Cellar? Spam to alt.suckers.news? ;-)
Mostly long term customers wanting more work. Some word of mouth.

10. Without divulging salary per se, do you feel you make more or less money as a consultant or as an employee?  Per year? Per Hour?
I feel I make more doing consulting than I would as a salaried employee.

Someone?

2. Is roller-coaster pay a problem for you? Boom and bust business?
> Not for me too much. But it drives my wife nuts. I've been in business for 20 years now and (praise God) have never been at a loss for work.
Same here - I would often actually prefer to have less work and more spare time..!

3. How about long hours or travel? Does that stress out your family?
It used to. Then I put my foot down and got smarter by learning how to say 'later' rather than 'yes' to some client requests. Absolutely 'Training' your customers is important! I'm not good at mornings, and tend to work 10-7ish, and have just about managed to stop people calling at 8:30AM..!

4. How do you go about capitalizing the business? pay as you go, loans, a combo?
Pay as you go.

5. What specifically does a consultant need to have around besides a computer, a scope, some hand tools, a compiler, an Eprom burner and an ICE?
Pay as I go - after you have the essentials of a good scope, ICE etc., capital outgoings are relatively low, until I decide to buy myself a new toy...! If startup funds are tight, you can make do with fairly minimal equipment, or oldie-but-goody testgear (Ebay can be your friend here,,,!) , but a decent digital scope and ICE are very high on the shopping list as soon as you can afford them.

6. Do you have a standard contract?
No - in fact I have never had any written contract with any customer. However I'm in the UK where things are generally less litigious. What I usually do is write down my understanding of a customers's spec and get them to agree it. I also have a few standard terms like I have the right to withold source/object code until invoices are paid. My feeling is that formal contracts can be a 2-edged sword - most of the time the company you are doing work for has deeper pockets than you, so if there is a formal contract and you screw up and they threaten lawyers, you can say  'show me where I guaranteed X in writing' - they can't and the worst outcome is you lose a customer, probably one you don't want to keep anyhow. If things go bad the other way , the worst case is you have spent time and don't get paid.

7. Do you have a home office or a remote office? Does the remote office allow you to leave the job behind?
Workshop at the bottom of the garden - much cheaper, and convenient. Makes it easier to work when you feel like it (e.g. work over the weekend when you won't be interrupted by phonecalls, and then go shopping in the week when it's less busy!)

8. How many hours a week do you spend working - 50? 70?
Almost infinitely variable, depending on what's on, and how guilty I feel about not getting stuff done that's due soon..... I do regular-ish work for about 6 companies. This is good for variety, steady flow of work etc., but there are times when they suddenly all decide they need something doing quickly....!

9. How do you advertise your business - word of mouth? Long term customers? Bingo cards? Ads in Circuit Cellar? Spam to alt.suckers.news? ;-)
Mostly long term customers wanting more work. Some word of mouth.

..and people I've worked with for one company moving to another company. I did some work for company A - someone left there and went to Company B - I did work for them. Someone else from Company B moved to Company C - I did work for them. His brother then needed some work doing for his own company....

I've found that if you do a good job, people come back for more, and they keep your number! I've never had to actively advertise. The only other two ways way I've got work are : 1) going to seminars and asking several awkward questions which incidentally show that I know what I'm talking about, and subsequently chatting over lunch. I've found a few cases of people in small-ish companies going to seminars hoping that it will teach them everything they need to know about <x company's products> so they can use them themselves, but then realising that it's not that simple, and instead asking someone else (i.e. me) to do it for them. 2) Being on the list of Microchip consultants.

In this, as in most businesses, good people are always busy. Only the poorer ones have to advertise frequently. I would be very hesitant about giving work to a company who has a regular ad in the technical press.

10. Without divulging salary per se, do you feel you make more or less money as a consultant or as an employee?  Per year? Per Hour?
Regardless of anything else, I've got so used to the flexibility of working when I want, usually on what I want, that I really don't think I could ever go back to working for one employer.

Edward Gisske, P.E. Gisske Engineering 608-523-1900 gisske@offex.com

1. How do you deal with health insurance? Just pay a lot? Have a spouse with another job where insurance is available?
Suck up and dig deep. It is my biggest expense. A wife with a day job is how most of the farmers do it around here. Some other consultants in the area teach part time at the local university just to get insurance. I just pay...

2. Is roller-coaster pay a problem for you? Boom and bust business?
Lumpy cash-flow is endemic in the biz. The cardinal rule is *pay cash*. Installment debt forces you to work for people you don't want to. If you want a toy or a new piece of equipment or a new car, save up for it and then buy it outright.

3. How about long hours or travel? Does that stress out your family?
It can be difficult for a spouse used to punching a time clock to understand life as a one-man-gang. You work hard when you have work and slack as you get the chance. I have been able to structure my practice so I don't have to travel a huge amount. The amount of travel goes up dramatically if you have a very specialized practice. My PhD consultant friends spend a whole lot of time on the road. I seldom do, as I am more of a generalist.

5. What specifically does a consultant need to have around besides a computer, a scope, some hand tools, a compiler, an Eprom burner and an ICE?
It depends on what you are doing. I have a pretty complete machine shop in the basement as I consult in both mechanical and electrical engineering. A minimum for an electronic-only practice is a computer, a plotter, an ICE, and a high-speed internet connection. Software only geeks can get away without the plotter. I have a lot of specialized detritus left over from decades in the biz. If I need something really specialized, I put it in the project budget or rent it for the occasion. I am also part of an informal collection of techno-whores that trade around equipment as necessary.

6. Do you have a standard contract?
No. I haven't found it to be particularly useful. I write up a very detailed proposal and acceptance of it is treated as a contract.

7. Do you have a home office or a remote office? Does the remote office allow you to leave the job behind?
There are various levels of "consultancy".
**1. The "job-shopper", who will almost always have to camp out at his customer premises.
**2. The "lost my last job and don't have another one yet" consultant who often has an office at a customer location as a waypoint to being hired by his customer full-time.
**3. The "Retired from the biz and doing a little consulting on the side" consultant usually works out of his home.
**4. Me. I have a home/office/workshop that I designed just for my lifestyle. It works nicely. The problem with a home office is that it can be difficult to drill into the rest of the family that just because you are home doesn't mean you aren't working. Particularly while writing software, interruptions from family members can multiply the bug count dramatically. I don't set up on a customer's premise at all. I am much more productive in my own "nest" surrounded by familiar tools and references and knowing where to come up with a .01uF disc ceramic at any time of the day or night. My clients would also be appalled by how I work. I often, particularly while coding, do manic all-nighters. Other times, if the day is nice, I jump on my Gold Wing and cycle around admiring the scenery while I consider a knotty problem or algorithm. Definitely not American Industrial Standard Practice, but it works for me.

8. How many hours a week do you spend working - 50? 70?
Depends on how much there is to do... It is useful to differentiate between billable time (BT) and work in general. I seldom bill over 75% of actual work time. All of the rest of the things you have to do to stay in biz (like clerical, janitorial or keeping up with the state of the art) get in the way.

9. How do you advertise your business - word of mouth? Long term customers? Bingo cards? Ads in Circuit Cellar? Spam to alt.suckers.news? ;-)
I have not spent a dime on advertising in the 25 years I have been independent. Circuit Cellar ads and the like seem as though they would be most likely to bring you biz from the dreaded "Basement Inventor" type (See my earlier rant on this thread). Referrals are wonderful! You have been already sold by the referer, so you generally don't have to work too hard to close on a job. I have long term informal relationships with contract manufacturers and Industrial Design shops that bring me into a project as necessary to do work. This has worked out well for me.

10. Without divulging salary per se, do you feel you make more or less money as a consultant or as an employee?  Per year? Per Hour?
It depends. Some years I am fat, others lean....

Mauricio

Let me tell you how things work for me, here in Argentina.

1. How do you deal with health insurance? Just pay a lot? Have a spouse with another job where insurance is available?
I pay, too much may be, but that’s the way for me...

2. Is roller-coaster pay a problem for you? Boom and bust business?
Sometimes yes. Specially this days, I have an enormous amount of bills, and I'm getting a little desperate...:S

3. How about long hours or travel? Does that stress out your family?
I try to keep the job in-house, only travel to take my customers his product done, one or twice for each project.

5. What specifically does a consultant need to have around besides a computer, a scope, some hand tools, a compiler, an Eprom burner and an ICE?
I think that that's pretty much that what I have. Unfortunately, I have to work with a 5Mhz old valvular scope and a Picstart plus. No ICE, just bootloader, trying to get and ICD...

6. Do you have a standard contract?
No, like someone said, I just write a very detailed spec, that’s the best around here, like the UK'er said before.

7. Do you have a home office or a remote office? Does the remote office allow you to leave the job behind?
home office, best, when you just had it from one "no way" code, you can take a nap and continue on the night...

8. How many hours a week do you spend working - 50? 70?
50 - 60 (its too much ah?) well, I guess I can do it for a while more, since im still young (just 23 yo)

9. How do you advertise your business - word of mouth? Long term customers? Bingo cards? Ads in Circuit Cellar? Spam to alt.suckers.news? ;-)
no need of advertising, well actually, no positive results. I work with microchip consultant list and word of mouth

10. Without divulging salary per se, do you feel you make more or less money as a consultant or as an employee? Per year? Per Hour?
Well, very tight here in my country. I'm trying to get some overseas jobs, in order to take advantage of the currency conversion, I mean, in previous messages, I can see that a job I can bill 1500 U$S can cost (in the us) 3000 U$S and I need about U$S 500 to live (monthly) so its relatively good money.         Unfortunately, thing are not going very good with economy around here, so I having now a thigh budget, but I'm sure it will go away soon (hope!!)

Someone else?:

5. What specifically does a consultant need to have around besides a computer, a scope, some hand tools, a compiler, an Eprom burner and an ICE?
depends on the job

6. Do you have a standard contract?
yes

7. Do you have a home office or a remote office? Does the remote office allow you to leave the job behind?
SOHO

8. How many hours a week do you spend working - 50? 70?
varies but yes

9. How do you advertise your business - word of mouth? Long term customers? Bingo cards? Ads in Circuit Cellar? Spam to alt.suckers.news? ;-)
That is the hard part....im looking for work right now

10. Without divulging salary per se, do you feel you make more or less money as a consultant or as an employee?  Per year? Per Hour?
more per hour contract.....employee....more consistent

Edward Gisske, P.E. Gisske Engineering 608-523-1900 gisske@offex.com

You bring up a good point. Stealing my customer by one of my sub-contractors is punishable by summary curbside execution. He will never work for me again.

That law, although unwritten, is understood by all of my "work-sharing" group

If a client that I am working for as a subcontractor from another consultant wants me to work for him, I won't do it directly. I refer him to my original contractor and tell him to work through him to get me. I charge just as much, but the other guy gets to add a bit for finding the customer. If the customer is asking for me specifically, the cost of hiring me is usually secondary to him wanting me to get the job done.

Andrew Warren -- aiw@cypress.com

1. How do you deal with health insurance? Just pay a lot? Have a spouse with another job where insurance is available?
When I was consulting, my wife's health-insurance covered me. It's a huge expense otherwise, at least in the USA.

2. Is roller-coaster pay a problem for you? Boom and bust business?
No, business varied between booming and really REALLY booming... Which is a mixed blessing at best.

3. How about long hours or travel? Does that stress out your family?
I've heard of people who treat their one-person consulting business like any other job -- work 8:00 to 5:00, take weekends off and maybe a couple-week vacation every year -- but I've never actually met one of those mythical characters.

For me, the hours were very long, which affected even my extremely understanding wife and played at least a small part in creating the emotional distance that ultimately led to the breakup of our marriage. Off the top of my head, I can name half a dozen other consultants whose experience mirrors mine in that respect.

If you're happily married or you have children, think long and hard before entering the consulting business.

5. What specifically does a consultant need to have around besides a computer, a scope, some hand tools, a compiler, an Eprom burner and an ICE?
I didn't need much more than that. Don't buy equipment or tools until you actually have a paying job that requires them; setting up a lab and furnishing an office is fun, but it won't lead directly to making money.

6. Do you have a standard contract?
Yes. I drew it up, then spent a few hours editing it with an intellectual-property attorney. More important than a "legal" contract, though, is just ANY written description -- no matter how informal -- of what you and your client think you're doing.

7. Do you have a home office or a remote office? Does the remote office allow you to leave the job behind?
I ended up working from an office in my house. If you're the type of person who can leave the job behind at night, you can do that just as easily with a home office as with rented office     space. If you're not that type of person, a rented office just means that you'll have to spend time commuting back and forth at all hours of the day and night.

8. How many hours a week do you spend working - 50? 70?
Yeah, somewhere in there. More some weeks, less others, although I always spent a LOT of time in the office. If you look at the piclist archives from before June of 2000, you'll see by my post count how many hours I was in front of a computer.  Looking back, it seems like 24/7.

9. How do you advertise your business - word of mouth? Long term customers? Bingo cards? Ads in Circuit Cellar? Spam to alt.suckers.news? ;-)
I got referrals from my local Microchip rep, from other consultants and people in similar businesses with whom I'd dealt, from the piclist, and maybe one or two directly from my listing in Microchip's certified consultant program. Most of the work I got, though, was either repeat business from existing clients or referrals from those clients.

10. Without divulging salary per se, do you feel you make more or less money as a consultant or as an employee? Per year? Per Hour?
You make significantly more per hour as a consultant, and if you're fortunate enough to have lots of people who want your services, you can make a lot of money real fast by just working lots of hours. You can't work like that all the time, though, and there ARE expenses that you don't have when you're an employee... And I suppose there could be lean times with no work, and there's likely to be at least one client who just refuses to pay you.

Nevertheless, it isn't hard to make more money as a consultant than as an employee. You WILL give up some of your life for that money, though, so don't do it if you're the kind of person who works to live rather than the other way around.

BillW

Don't forget that a 'real job' offers no guarantee that you won't have equally long hours and/or travel issues. I don't know many "traditionally employed" engineers that work strict 40 hour weeks either.

5. YAPGI = Yet Another Penniless Garage Inventor.
How to sort real customers from dreamers

How about "Do you actually have funding for this project now?" I've gone the rounds before with the mad inventor crowd only to find later that the budget projections were based on "I'll go find vc/angel investors and formalize a business plan after you've developed a prototype."

Mauricio Jancic Janso Desarrollos Microchip Consultant (54) - 11 - 4542 - 3519

Ugh, tell me about it. How about the ones where you get offered a share in the multi-million dollar sales. Been there done that got a drawer full of T-shirts

You don't like to disappoint people but sometimes the economic reality just means you have to

And it does tend weed out who's really really serious

I think a questionnaire is a good idea because often the customer doesn't really appreciate or understand what they actually want and it's easy to slip into too informal an agreement that can come back to haunt either of you. Formalisation and careful consideration by both parties is a good way to start off I reckon

I find it VERY difficult to make a GOOD plan and overview of a project. I mean, I can outline the whole project, no problem with that, but I find it hard to make most customers (non technical-related-positions ones mostly) understand what is "EXACTLY what they need".

I mean, is not that I cannot treat the professionally, but most people I've encountered want "a device to do the task", you may ask:

Size? Functions? Operating voltages?

Ja! No way. For these people I usually make a, somehow, open spec, and a very quick prototype, so they can see how the product will look like.

So? Well, I guess it will depend on the customer. Some, will let you choose where in the whole building you may put your device, some other will tell you that they want you yo use *that* zenner.         you can tell pretty much which customer you are dealing with just by they vocabulary, and how they explain you what they need.

I have in my desk, right now, an spec for a given job. The equipment is just a multi-menu display to control an already developed system. This spec, for this simple task, has about 10 pages (written by the customer) and explains EXACTLY what will happened if you press each key on every possible (imaginable) situation. Unfortunately my (short) experience tells me this is hard to find, but it's really helpful....

"Jinx" <joecolquitt@CLEAR.NET.NZ>

Any suggestions for general questions to ask potential customers ? Some thoughts -

• When is this needed ?
• Is this a prototype or proof-of-concept only ?
• Or is quantity required ? How many ?
• What precision / accuracy ?
• Power supply ?
• Environment the product will be in ?
• Size ? Importance of size ?
• Cost ? (or cost vs quality)
• Longevity ?
• What is your budget ? (is that relevant or appropriate ? Could you apply for a development grant for example to help ?)
• Have you approached another developer, what result ?
• Is there a competing product ? (Details ? Reason for you making your own ?)

Dal Wheeler

How about "Do you actually have funding for this project now?" I've gone the rounds before with the mad inventor crowd only to find later that the budget projections were based on "I'll go find vc/angel investors and formalize a business plan after you've developed a prototype." I'd imagine you'd want to word it a bit more elegantly in practice. Not a problem I suppose for regular contract work; but a lot of guys propose a bit of "blue sky" in exchange for some discount/free development work. Many here on the piclist are probably more experienced at this than me, but it still kind of surprises me at the informal nature of a lot of these "business plans". Maybe it's just my neighborhood...

6. Did the Butler do it? What about hiring paid staff:

Do you use employees? Are they permanent, part-time, Student Interns? Do you periodically farm out work when the workload is large?

Andrew Warren -- aiw@cypress.com

I would farm out work to other consultants -- or just refer clients to them -- when I was too busy to take it on myself.

I never had employees. In fact, when I closed down my consulting business and decided to take a job as an employee at Cypress, it was partly because my consulting business was at the point where I'd soon have to hire employees if I wanted it to grow... And I just didn't want to be directly responsible for anyone else's livelihood at that time. -Andy

Edward Gisske, P.E. Gisske Engineering 608-523-1900 gisske@offex.com

I have not and never have had employees. I am good at engineering, but not so good at sales. If I had an employee, I would have to spend more time than I want selling and less designing. I am part of a very loose informal organization of consultants. We shed work to one another as the skills and time work out. Sometimes I am the boss, and sometimes the "boy". Student interns are pretty useless.

Eric Bohlman

I have also had technicians, maybe they could not code so well, but I could hand them an I/O list from my PIC source code and they could design and build a prototype circuit by noon and have it laid out in Eagle by the next noon.   Not from a circuit diagram, mind you, but an I/O list! I was 3X more productive when my technician was around. That level of skill was after I had trained them for two years.

The key to successfully expanding an operation that's become too big for one person to handle is to understand the concept of "essential job functions" and "marginal job functions."  Many people think that's a purely legalistic distinction that arose from the Americans with Disabilities Act, but it's actually a much broader concept that's closely related to the way startups either succeed or fail.

Basically, essential job functions are those that make up the "essence" of a position; if the holder of the position couldn't do them, it wouldn't really be the position that it is.  For example, circuit design or programming would be essential functions for an engineer. Marginal job functions are those that, while they *might* be performed by the holder of a position, aren't really part of the definition of the position and could be shifted to someone else. For an engineer, answering phone calls, dealing with the mail, and bookkeeping would be examples of marginal job functions.

The key here is that if you find yourself overwhelmed and need to add some staff, you want to add people who can take over some or all of your marginal job functions, not your essential ones. In most cases that means that the first hire should be a secretary/office manager/all-around gopher. You want someone who can relieve you of having to do the stuff that doesn't require your special expertise. Hiring a technician would be another example, because building up prototypes is really a marginal function of an engineer's job. The engineer might particularly enjoy it, but it represents a distraction from actual design work.

The next step would be to hire people with specialized expertise that's *outside* your field, like marketing, sales, or accounting people. However, it's probably better to first use outside contractors/consultants for such functions, adding employees in those areas only when you've grown quite big. Only when you've grown *really* big should you even think of hiring people in the same field in which you have expertise. And even then you should think first of contracting it out. One of the reasons is that managing people whose expertise is in your own field is one of the hardest forms of managing people.  The temptation to micromanage or to take away the most enjoyable elements of the task can be very hard to resist, and when you do that, you lose most of the advantage of adding someone else.

If you get to the point of adding another engineer, it's probably best to assign him/her to developing test fixtures/test code or other sorts of "scaffolding" and conducting testing rather than direct product design. That will help keep out the temptation to micromanage, and will probably result in better testing because it will be done by someone who hasn't internalized the design to the extent you have and who doesn't have a psychological incentive *not* to find problems.

One of the most common failure modes for startups is when the founders start hiring technical staff while continuing to do administrivia themselves. The usual result is that the cash burn rate goes way up, yet the founders are still overwhelmed to the point that they can't do what they're best at. Going from a one-man operation to an organization requires giving up control, and it's much easier to give up control of the things that *aren't* nearest and dearest to you.

Lawrence Lile

I have had good luck with student interns, and I know a consultant who uses them all the time. We have an electrical engineering school at the University in town, and can get a fairly high caliber of BS candidate or MS candidate. I have had projects where I would offload specific tasks on the intern. I usually expect a lot out of them, and get a lot, for $13 an hour. Although they do all the cooking tests (a boring and tedious task) they also do some specific bits of code, prototyping, PCB layout and so on. However, I am not a consultant and my employer takes on the hassle of hiring them. I know another small businessman (not an engineer, a builder) who uses employees from time to time. He goes to a temp agency and says "I want to hire Joe Blow.  I want you to take care of his taxes, withholding, workmans comp and all that stuff and just send me a bill. I want to pay him X amount and I want him to start Monday." They are used to this arrangement, basically they are his HR department.

Having said that, I would only use interns on a project-by-project basis. Make it clear at the beginning that they are hired to do a specific job for a specific length of time.

I have also had technicians, maybe they could not code so well, but I could hand them an I/O list from my PIC source code and they could design and build a prototype circuit by noon and have it laid out in Eagle by the next noon.   Not from a circuit diagram, mind you, but an I/O list! I was 3X more productive when my technician was around. That level of skill was after I had trained them for two years.

Trading work around an informal network is great. However, I know some guys who will expand any task given them and try to suck up the client. I hired a guy to design me an XYZ module for an appliance, and soon he had convinced the marketing department, without bothering me about it, to let him design the whole shebang. I got to test it a little bit after it was done, he got to patent it.

7. Borrowing Money, Using Bank Loans, Mortgaging you home, borrowing money from your uncle for startup capitol, loans to get through cash flow crunches, loans for new equipment.

How do you go about capitalizing the business? pay as you go, loans, a combo?

Bob Ammerman RAm Systems: "Pay as you go."

Edward Gisske, P.E. Gisske Engineering 608-523-1900 gisske@offex.com: "PAY AS YOU GO!"

Andrew Warren -- aiw@cypress.com

Pay as you go. Debt prevents you from being able to say no to a client.

Besides, you don't really NEED to buy much in that business, and if you DO need some special piece of equipment (or software package, or whatever) for a particular client's job, he'll often buy it, lease it, or lend it to you. -Andy

Mauricio: " PAY AS YOU GO Best regards"

After you find an appropriate page, you are invited to your question comment link preformated text to this massmind site! (posts will be visible only to you before review) Just type a nice message (short messages are blocked as spam) in the box and press the Post button. (HTML welcomed, but not the <A tag: Instead, use the link box to link to another page. A tutorial is available Members can login to post directly, become page editors, and be credited for their posts.


Link? Put it here: 
if you want a response, please enter your email address: 
Attn spammers: All posts are reviewed before being made visible to anyone other than the poster.