Alex Harford <harford <at> gmail.com> writes:
> At my previous job, we brought in some outside contractors to do some
> well defined tasks.  We had a hardware product that had Windows
...
> increase your chances of success if you can package up a task with
> clearly defined goals.

I strongly believe that contractors working full time on the premises in the
domain of the company (i.e. not nannies, nurses, cooks and window-washers) are
actually 'temporary workers' and that calling them otherwise is a form of tax or
insurance fraud. I have good reasons to believe that the tax laws in at least 3
developed countries strongly agree with me here. Maybe in the USA it is
possible, but elsewhere it is not a good idea. I heard of 'contractors' being
downgraded retroactively (during tax review) to temps, with $$$$ consequences
for the company and for the 'contractors'. I also believe that such contractors
are necessary and *contractors* when they do a specific job for a specific
limited amount of time (and the tax man agrees with me here too).

It also seems that for some reason clients employing a contractor on a 'testing
basis' can offer half or less the pay normally assigned to that kind of work.
They claim that it's for 'testing' and later it will be re-negotiated. Hello?!
Some things will be done for free or at material cost, to see how things work
out later, even if lengthy and prestige-related, but half *pay* for real *work*
is an insult.

In general, when something is outsourced an interface is built that consists in
a specification, cost and time-frame, with or without (uhh) checkpoints. It does
not matter whether it's a patio, a new roof or a controller project. There is a
spec, a time-frame, a cost frame, and a final inspection in any case, as well as
risk that may have to be hedged with insurance. How the contractor does it, is
not relevant. He is hired because he can do the work. A prefabricated or
assembled off site roof or patio or controller cannot be 'inspected' while it is
being built elsewhere, at best, one can have progress reports from a designated
contact person, and, no, factory or lab site visits that allow the client to
glean important manufacturing and design technology details and later implement
them on his premises foregoing the contractor later, are NOT ok in the vast
majority of cases. The contractor's work place has NOT just become an
inspectable and accountable part of the client's business. Some people on this
list post pictures of their private labs, looking more or less pristine (or
not). That's an advertisement, not an invitation to drop in at any time, day or
night, or 'invite' yourself over, to 'see how it's really done'.

'Testing' the contractor (otherwise than by accepting his portfolio or other
bona fide) sounds like testing a temp employee. Does one test an IBM
salesman/integrator before buying from him or before letting him and his workers
install a computer room and start up the servers ? No. How about your favorite
Microchip FAE ? Maybe not. Then why the contractor ? How is he different from
the roofer or from the IBM man ? The only person one would 'test' would be a
temp *employee*.

Control freaks pay for the adrenalin and ego rush they get from 'full' control
with endless amounts of wasted time and implicitly money, and eventually manage
to p*** off the most patient person, turn away clients, and even cause their
best workers to just walk. Eventually you have to trust someone, and no-one is
perfect.

The 'interface' with a worker or a contractor is in general a type of
requirement sheet or a contract. If it is too long or complex, then the problem
to be solved has not been defined sufficiently. There is no substitute for a
concise, short contract or work sheet that everyone understands. 'Expanding'
this into a 100 page document by endless discussions is not a good idea.
Hand-waving and weekly 'architecting' meetings are not going to get you there.

I have had success writing the spec sheet and drawing the block diagram of the
device before, as a basis for the 'interface', using successive discussions and
obvious technical data acquisition, and standards and safety reviews. All of it
2 pages. Add to this 10 pages of menus and button descriptions (mostly user
manual style graphical with comments) and there is a product spec. This I made
into the user *manual*, which was accepted by the client. The product was
designed and built after *that* manual. Voila, three minor software revisions
later (all compile time flags selecting options), one supply related CPU change
later, and one minor board revision later, it was accepted, on time and in
budget. Just as an example (I guess this is top down hardware design <vbg>). 

Of course with a sufficiently complex multi-node device it can take 6 months of
building and several days of integration sessions to make things work, but the
basic principle is the same. Clean 'client' interface design, specs, sign it
off, get work done to (identically and functionally) resemble specification.

Peter


-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist