TechTips: Consulting, and making a living at it 
Author Message
 TechTips: Consulting, and making a living at it

Many programmers leave their respective companies (either on their own
or, ahem..., not) and try to hang out their shingles as a contractor or
as a consultant.  One by one they seem to follow the same courses, and
crash into the same rocks.  If they survive, they're likely to make it
their permanent career.  But those rocks, those rocks ...

Let me point out some of the rocks -I've- hit, or avoided, over the
years ...  :-)

[1] CONTRACTS AND SPECIFICATIONS:
Herman Holtz's "Complete Guide to Consulting Contracts" (ISBN
0-7931-0670-2) should be required reading.  You should also be obliged
to watch a few dozen episodes of the old "People's Court" series just so
that you'll know how to avoid winding up in there.  The biggest "rock"
that you can run into is actually a submerged high-explosive mine:  the
[former] customer has become so disillusioned and angry that he sues.
This rock hits you because the two of you failed to establish a written
foundation for the project (the contract), and clear written
documentation of the project specifications and actions to be taken
(what Mr. Holtz calls "task orders").

[2] SUSTAINABLE REVENUE:
Lawyers and accountants want you to put them "on retainer."  This is
where you pay them a certain amount of money each month, whether you use
it or not.  They do this to create a revenue _stream.  It's an income
they can count on, and when you truly "sing for your supper" that's
extremely important.

[3] IX-NAY BABBLE-TECHNOAY:
It doesn't take "pig latin" to figure out that you as a programmer speak
a completely different language than your clients.  They don't care one
whit about Delphi or Visual Basic or Paradox or which one is better than
the other .. they don't care, don't know, don't want to know, don't ...
"don't you GET it awreddy?"  ;-)  You will probably find that your
consulting practice needs to have someone to insulate -you- (the person
who speaks fluent technobabble) from the -clients- (the people who pay
the bills, and don't speak tech).

[4] QUALIFYING YOUR PROSPECTS, AND YOUR CLIENTS:
You'll find out that quite a few of the people who approach you with an
idea for a project .. leading you to say promising things to your
landlord .. do not have the capacity to spend money or do not have the
money to spend.  You must develop the skill of tactfully "qualifying
your prospects" and weeding out the ones that don't make the cut, so
that you spend your time pursuing only profitable business.  You'll also
discover that not every project that you >could< take is >worth<
taking.  

[5] YOU SHOULD GET PAID TO WRITE SPECS, TOO:
Architects don't work for free, do they?  The process of designing a
house and of preparing a construction plan for it is worth money even
if, for some reason, the house itself does not get built.  Likewise, the
process of preparing a detailed plan, schedule, and cost-estimate for a
computer software project >is< something that's worth money.  You don't
have to do it for free; and you shouldn't.  "Task order #1 is to prepare
task order #2."

[6] HONEYMOON MONEY:
Ask for a portion of the money up-front, balance on completion, for each
and every significant task.  If the task is cancelled, your contract
should expressly specify that you can retain the deposit as liquidated
damages.  It should also provide for progress-payments if the task is
long, and a proviso to stop or suspend work if the payment is not
received timely.  Hey, it happens.

[7] VISIBLE MEANS OF SUPPORT:
Software is forever ... applications you wrote eight years ago can still
be in-service, and someone out there might still expect you to fix any
problems with it at the drop of the hat.  A few might even add, "or
else!"  {What would Judge Wopner say about that?  You don't wanna have
to find out.}  You should have an explicit support/warranty period
spelled out in your contract, and then =charge= for support thereafter,
with an also-included provision of exactly how and when you may escape
from that obligation.  All software has a long life-span and can become
mission-critical.  It also bears your name, or your company's name,
forever.  Along with that goes your reputation.  Protect that investment
by =explicitly= providing for the =entire= software life-cycle, not just
the development-period and the 30 days thereafter.

[8] INTEGRITY:
Don't do anything your mamma would not be proud to talk about in Sunday
School.

[9] THE DUCK PRINCIPLE:
Always look calm and cool on the surface.  Underneath, paddle like hell.
;-)

[10] OF COURSE I'M NOT A LAWYER:
Find your own.  Do it.  

----------------------------------------------------------------
? Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259

Quote:
> Fast(!), automatic table-repair with two clicks of the mouse!
> ChimneySweep(R):  Release 4.0 is here!!
> http://www.***.com/



Tue, 15 Jun 2004 08:47:57 GMT
 TechTips: Consulting, and making a living at it

I like the term 'duck principle'
:-)
peter walker


Quote:
> Many programmers leave their respective companies (either on their own
> or, ahem..., not) and try to hang out their shingles as a contractor or
> as a consultant.  One by one they seem to follow the same courses, and
> crash into the same rocks.  If they survive, they're likely to make it
> their permanent career.  But those rocks, those rocks ...

> Let me point out some of the rocks -I've- hit, or avoided, over the
> years ...  :-)

<snip>
Quote:
> ----------------------------------------------------------------
> ? Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259

> > Fast(!), automatic table-repair with two clicks of the mouse!
> > ChimneySweep(R):  Release 4.0 is here!!
> > http://www.sundialservices.com/products/chimneysweep



Tue, 15 Jun 2004 12:13:10 GMT
 TechTips: Consulting, and making a living at it
I suspect it was my recent question about retainers that inspired
this.  I'm probably the{*filter*}one here who will benefit from this post,
but I'm sure there will be others.

Thanks for taking the time to share :)



Tue, 15 Jun 2004 12:25:24 GMT
 TechTips: Consulting, and making a living at it
Very interesting, thanks for sharing with us.
I always find it difficult to put a price on a project, if I count all the
hours I work at it at the rates mentioned here in the newsgroup (for people
that make a living out of it) no one will let me do the job. Besides I can't
even estimate the time I'll be working on it.
I also find it very difficult to setup the outlines of the project. I mean
the customer doesn't always know what he want's and what the possibilities
are. Of course the developer also has a consulting function and we try to
open the eyes off the customer. But sometimes it's hard or impossible to see
the needs of the whole business you're developing for.

How is the rest of you making up contracts? A nice example I think are
reports, there always some reports missing that they didn't think of. Do you
include them all in the contract or do you make them dynamic?
What search options do you want in a customer database, just by name and ID,
or also by adres, phone number or any part of a name or adres. Do you ask
the customer upfront or do you include al these features by default?
How much time do you spent with the customer to talk about the project.

I'm still a 'young' Access developer (about 6 years of which 3
semi-professional, still got a day job) and I have learned a lot about the
technical side of developing, but the commercial side is damn difficult for
me. Probably the reason why I can't make a full time living out of it rather
than the quality of the application.

Anyone who wants to share thoughts about this with me or can give me some
good hints on how to approach the commercial side of developping, is most
welcome.

Regards,

Jef

Jef



Quote:
> Many programmers leave their respective companies (either on their own
> or, ahem..., not) and try to hang out their shingles as a contractor or
> as a consultant.  One by one they seem to follow the same courses, and
> crash into the same rocks.  If they survive, they're likely to make it
> their permanent career.  But those rocks, those rocks ...

> Let me point out some of the rocks -I've- hit, or avoided, over the
> years ...  :-)

> [1] CONTRACTS AND SPECIFICATIONS:
> Herman Holtz's "Complete Guide to Consulting Contracts" (ISBN
> 0-7931-0670-2) should be required reading.  You should also be obliged
> to watch a few dozen episodes of the old "People's Court" series just so
> that you'll know how to avoid winding up in there.  The biggest "rock"
> that you can run into is actually a submerged high-explosive mine:  the
> [former] customer has become so disillusioned and angry that he sues.
> This rock hits you because the two of you failed to establish a written
> foundation for the project (the contract), and clear written
> documentation of the project specifications and actions to be taken
> (what Mr. Holtz calls "task orders").

> [2] SUSTAINABLE REVENUE:
> Lawyers and accountants want you to put them "on retainer."  This is
> where you pay them a certain amount of money each month, whether you use
> it or not.  They do this to create a revenue _stream.  It's an income
> they can count on, and when you truly "sing for your supper" that's
> extremely important.

> [3] IX-NAY BABBLE-TECHNOAY:
> It doesn't take "pig latin" to figure out that you as a programmer speak
> a completely different language than your clients.  They don't care one
> whit about Delphi or Visual Basic or Paradox or which one is better than
> the other .. they don't care, don't know, don't want to know, don't ...
> "don't you GET it awreddy?"  ;-)  You will probably find that your
> consulting practice needs to have someone to insulate -you- (the person
> who speaks fluent technobabble) from the -clients- (the people who pay
> the bills, and don't speak tech).

> [4] QUALIFYING YOUR PROSPECTS, AND YOUR CLIENTS:
> You'll find out that quite a few of the people who approach you with an
> idea for a project .. leading you to say promising things to your
> landlord .. do not have the capacity to spend money or do not have the
> money to spend.  You must develop the skill of tactfully "qualifying
> your prospects" and weeding out the ones that don't make the cut, so
> that you spend your time pursuing only profitable business.  You'll also
> discover that not every project that you >could< take is >worth<
> taking.

> [5] YOU SHOULD GET PAID TO WRITE SPECS, TOO:
> Architects don't work for free, do they?  The process of designing a
> house and of preparing a construction plan for it is worth money even
> if, for some reason, the house itself does not get built.  Likewise, the
> process of preparing a detailed plan, schedule, and cost-estimate for a
> computer software project >is< something that's worth money.  You don't
> have to do it for free; and you shouldn't.  "Task order #1 is to prepare
> task order #2."

> [6] HONEYMOON MONEY:
> Ask for a portion of the money up-front, balance on completion, for each
> and every significant task.  If the task is cancelled, your contract
> should expressly specify that you can retain the deposit as liquidated
> damages.  It should also provide for progress-payments if the task is
> long, and a proviso to stop or suspend work if the payment is not
> received timely.  Hey, it happens.

> [7] VISIBLE MEANS OF SUPPORT:
> Software is forever ... applications you wrote eight years ago can still
> be in-service, and someone out there might still expect you to fix any
> problems with it at the drop of the hat.  A few might even add, "or
> else!"  {What would Judge Wopner say about that?  You don't wanna have
> to find out.}  You should have an explicit support/warranty period
> spelled out in your contract, and then =charge= for support thereafter,
> with an also-included provision of exactly how and when you may escape
> from that obligation.  All software has a long life-span and can become
> mission-critical.  It also bears your name, or your company's name,
> forever.  Along with that goes your reputation.  Protect that investment
> by =explicitly= providing for the =entire= software life-cycle, not just
> the development-period and the 30 days thereafter.

> [8] INTEGRITY:
> Don't do anything your mamma would not be proud to talk about in Sunday
> School.

> [9] THE DUCK PRINCIPLE:
> Always look calm and cool on the surface.  Underneath, paddle like hell.
> ;-)

> [10] OF COURSE I'M NOT A LAWYER:
> Find your own.  Do it.

> ----------------------------------------------------------------
> ? Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259

> > Fast(!), automatic table-repair with two clicks of the mouse!
> > ChimneySweep(R):  Release 4.0 is here!!
> > http://www.sundialservices.com/products/chimneysweep



Tue, 15 Jun 2004 18:39:34 GMT
 TechTips: Consulting, and making a living at it
I read this thread and thought about my experiences over the past 27
years in the business world.  There were 21 years as a manager in
Corrugated Box plants.  I have been an Accountant, Controller,
Salesperson, Sales Manager, and General Manager.  5 years ago I began
teaching myself database programming.  The goal was to create an
application that would be marketable to box plants.  I now have 11 box
plants, and 1 foam plant running the application every day.
I am currently embarking on a venture with a re-seller to market one
version of my mfg. software married to an accounting package that they
re-sell.

Having established the background, here are some thoughts about
software consulting.

1.  Most technical people I have met (programmer types and hardware
types) are very smart, very arrogant, talk too fast, don't listen, and
use words that don't fit the audience.  I recently hooked up with an
established software firm and did some sales presentations.  They were
constantly saying things like OBDC, VPN, blah blah,etc. etc. After the
first presentation, I explained how ridiculous this was.  They got
mad. They tried to change, but their arrogance got the better of them.
 We are no longer affiliated.  When techical types try to be
salespeople, they often fail.

I actually sold my program to a plant that had purchased another
package for $15,000, and paid the vendor.  During the installation the
vendor made the buyer so mad, that they threw him out.  Arrogance
again.

So be humble, ask questions, and listen to the answers.

2.  I can only speak from my experience, but it seems to me that my
customers would be unwilling to pay me to create a totally unique
solution just for them.  The total cost would be more than they would
be willing to pay.  I have used each customer to pay for the on-going
development of a product.

3.  A programmer, who doesn't understand day to day business
activities, is going to create a product that will cause frustration
on the part of users.  Listen to the users, and tell them to tell you
when you the program is really irritating them.  Ask them how it could
be better.

4.  Return phone calls promptly, not two days later.  This is a big
issue.

5.  I charge for custom modifications, or reports.  I will waive this
charge if the idea is one that I can add to the program and re-sell in
future releases.

6.  Every sale is made with a set amount for the license and a set
amount for the installation, training, travel, and meals and lodging.
If the time goes beyond the agreement, they know upfront what it will
cost per day.

7.  Every agreement has a monthly support fee that is in place for as
long as they use the program.  I could probably make more by charging
for every phone call and every minute.  The reality is that the owners
would rather quickly see those expenses and tell the users not to call
me. Then the users would get frustrated and tell the owner that the
program is full of bugs.  I simply tell the potential customer, that
this is what it costs for me to remain in business and their worst
nightmare would be for me not to remain in business.  They put it in
the budget and forget about it.  I would not choose to be in the
software business, without this monthly retainer.

8.  It also seems to that if the object is to make money doing
something you enjoy, then you can't afford to mess around learning
things that are cool, but not useful.  Learning programming because it
is challenging and fun, is a recipe for having a day job.

In summary, if you are going to wear different hats (Sales,
Programming, etc.) then you have to become more rounded.  Success in
business, particularly your own, is all about people skills.

Off the soap-box.

Steve White
Steve White Consulting



Tue, 15 Jun 2004 23:01:32 GMT
 TechTips: Consulting, and making a living at it

Quote:

> Very interesting, thanks for sharing with us.
> I always find it difficult to put a price on a project, if I count all the
> hours I work at it at the rates mentioned here in the newsgroup (for people
> that make a living out of it) no one will let me do the job. Besides I can't
> even estimate the time I'll be working on it.

Perhaps what you mean, Jef, is that "I'm afraid that if I told you the
truth about how much time it will take, and charged you for that time,
you'd balk at the price and not give me the work and I'll starve."  So
you underprice the job, and you starve while doing it .. or you
underprice the job, starve a while, realize you're starving, and run off
leaving the job half-finished.  (Not "you," of course ... I'm speaking
generically.)

The only way to really estimate how much a job will cost and how much
time it will take and so forth is to SPECIFY it.  I mean, using
Microsoft Project ("what do you want to call the product today?") and
building Gantt charts and working out alternatives and presenting those
to the customer along with an honest price.  [With enough data to allow
the customer to subsequently and intelligently revise the project scope
to get the price affordable.]  

The only way to do _that, properly, is to charge for the work of
specification.  And to treat the work-product of that process as a
separate deliverable from the actual program, if and when you actually
get to build it.  "The blueprints, once I've finished drawing them, are
yours."

Quote:
> I also find it very difficult to setup the outlines of the project. I mean
> the customer doesn't always know what he want's and what the possibilities
> are. Of course the developer also has a consulting function and we try to
> open the eyes off the customer. But sometimes it's hard or impossible to see
> the needs of the whole business you're developing for.

See above.  :-)

I mean, how do you suppose the customer feels?  You're saying it will
cost him this much and in the back of his mind he's saying, "how does
s/he KNOW?  Is s/he just spouting numbers at me?  [Yes...]"  

How would you feel if you wanted to have a house built and a fellow
walked up to you and said, "your house will cost you $100,000."  And you
haven't even sat down and discussed with him what kind of house you
want?  It's impossible of course... but consultants do it every day, and
_that is a big reason _why they starve.

[ooh, I should be giving a seminar right now and charging $2,000 a seat
for tickets.]  ;-)

Quote:

> How is the rest of you making up contracts? A nice example I think are
> reports, there always some reports missing that they didn't think of. Do you
> include them all in the contract or do you make them dynamic?
> What search options do you want in a customer database, just by name and ID,
> or also by adres, phone number or any part of a name or adres. Do you ask
> the customer upfront or do you include al these features by default?
> How much time do you spent with the customer to talk about the project.

Every single thing is covered by a task-order.  If Susie Secretary talks
about a report she'd really like to have ... it don't mean squat unless
and until Sally Boss puts her Jane Hancock on another task-order.  "Any
contemporaneous or verbal understandings between the parties are
superseded by or fully stated within this written document."  Even if
someone said to Susie that yes, it sounds like a really good idea, or
even, yes, we _can do that, does NOT mean that we are thereby obligated
TO do it.

I once had a client, subsequently dropped for this reason, who kept
trying to push our company's buttons on this point.  I finally said,
very calmly, "Mr. Jones, read paragraph six."  And hung up.  Invoking
the other paragraph which stated that the client was not obligated to
issue task-orders -and- that we were not obligated to accep them, we
never again accepted a task order from this client.

Quote:

> I'm still a 'young' Access developer (about 6 years of which 3
> semi-professional, still got a day job) and I have learned a lot about the
> technical side of developing, but the commercial side is damn difficult for
> me. Probably the reason why I can't make a full time living out of it rather
> than the quality of the application.

> Anyone who wants to share thoughts about this with me or can give me some
> good hints on how to approach the commercial side of developping, is most
> welcome.

If you want to do consulting/contracting as a profession ... and I doubt
you do, if you are comfortable in your day-job ... then Mr. Holtz's book
is required reading.  The programming is not what will get you -- anyone
can do the programming.  What will save you or kill you is how you
handle the BUSINESS of services work.

Be warned:  it's a very, very low-margin business that involves a lot of
hours.

----------------------------------------------------------------
Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259

Quote:
> Fast(!), automatic table-repair with two clicks of the mouse!
> ChimneySweep(R):  Release 4.0 is here!!
> http://www.sundialservices.com/products/chimneysweep



Tue, 15 Jun 2004 23:42:16 GMT
 TechTips: Consulting, and making a living at it
Great writing, Steve... GREAT writing!

Quote:

> I read this thread and thought about my experiences over the past 27
> years in the business world.  There were 21 years as a manager in
> Corrugated Box plants.  I have been an Accountant, Controller,
> Salesperson, Sales Manager, and General Manager.  5 years ago I began
> teaching myself database programming.  The goal was to create an
> application that would be marketable to box plants.  I now have 11 box
> plants, and 1 foam plant running the application every day.
> I am currently embarking on a venture with a re-seller to market one
> version of my mfg. software married to an accounting package that they
> re-sell.

> Having established the background, here are some thoughts about
> software consulting.

> 1.  Most technical people I have met (programmer types and hardware
> types) are very smart, very arrogant, talk too fast, don't listen, and
> use words that don't fit the audience.  I recently hooked up with an
> established software firm and did some sales presentations.  They were
> constantly saying things like OBDC, VPN, blah blah,etc. etc. After the
> first presentation, I explained how ridiculous this was.  They got
> mad. They tried to change, but their arrogance got the better of them.
>  We are no longer affiliated.  When techical types try to be
> salespeople, they often fail.

> I actually sold my program to a plant that had purchased another
> package for $15,000, and paid the vendor.  During the installation the
> vendor made the buyer so mad, that they threw him out.  Arrogance
> again.

> So be humble, ask questions, and listen to the answers.

> 2.  I can only speak from my experience, but it seems to me that my
> customers would be unwilling to pay me to create a totally unique
> solution just for them.  The total cost would be more than they would
> be willing to pay.  I have used each customer to pay for the on-going
> development of a product.

> 3.  A programmer, who doesn't understand day to day business
> activities, is going to create a product that will cause frustration
> on the part of users.  Listen to the users, and tell them to tell you
> when you the program is really irritating them.  Ask them how it could
> be better.

> 4.  Return phone calls promptly, not two days later.  This is a big
> issue.

> 5.  I charge for custom modifications, or reports.  I will waive this
> charge if the idea is one that I can add to the program and re-sell in
> future releases.

> 6.  Every sale is made with a set amount for the license and a set
> amount for the installation, training, travel, and meals and lodging.
> If the time goes beyond the agreement, they know upfront what it will
> cost per day.

> 7.  Every agreement has a monthly support fee that is in place for as
> long as they use the program.  I could probably make more by charging
> for every phone call and every minute.  The reality is that the owners
> would rather quickly see those expenses and tell the users not to call
> me. Then the users would get frustrated and tell the owner that the
> program is full of bugs.  I simply tell the potential customer, that
> this is what it costs for me to remain in business and their worst
> nightmare would be for me not to remain in business.  They put it in
> the budget and forget about it.  I would not choose to be in the
> software business, without this monthly retainer.

> 8.  It also seems to that if the object is to make money doing
> something you enjoy, then you can't afford to mess around learning
> things that are cool, but not useful.  Learning programming because it
> is challenging and fun, is a recipe for having a day job.

> In summary, if you are going to wear different hats (Sales,
> Programming, etc.) then you have to become more rounded.  Success in
> business, particularly your own, is all about people skills.

> Off the soap-box.

> Steve White
> Steve White Consulting

--
----------------------------------------------------------------
Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259

- Show quoted text -

Quote:
> Fast(!), automatic table-repair with two clicks of the mouse!
> ChimneySweep(R):  Release 4.0 is here!!
> http://www.sundialservices.com/products/chimneysweep



Tue, 15 Jun 2004 23:43:45 GMT
 TechTips: Consulting, and making a living at it
Howdy, all.
This is a great thread...in fact, some comments, especially those regarding
reports can also be applied to prevent "mission creep" for internal office
projects...Boss is now on bandwagon to prioritize/approve changes brought up
by users with the opening statement "wouldn't it be nice..."

Thanks for sharing.

Rey


Quote:

> > Very interesting, thanks for sharing with us.
> > I always find it difficult to put a price on a project, if I count all
the
> > hours I work at it at the rates mentioned here in the newsgroup (for
people
> > that make a living out of it) no one will let me do the job. Besides I
can't
> > even estimate the time I'll be working on it.

> Perhaps what you mean, Jef, is that "I'm afraid that if I told you the
> truth about how much time it will take, and charged you for that time,
> you'd balk at the price and not give me the work and I'll starve."  So
> you underprice the job, and you starve while doing it .. or you
> underprice the job, starve a while, realize you're starving, and run off
> leaving the job half-finished.  (Not "you," of course ... I'm speaking
> generically.)

> The only way to really estimate how much a job will cost and how much
> time it will take and so forth is to SPECIFY it.  I mean, using
> Microsoft Project ("what do you want to call the product today?") and
> building Gantt charts and working out alternatives and presenting those
> to the customer along with an honest price.  [With enough data to allow
> the customer to subsequently and intelligently revise the project scope
> to get the price affordable.]

> The only way to do _that, properly, is to charge for the work of
> specification.  And to treat the work-product of that process as a
> separate deliverable from the actual program, if and when you actually
> get to build it.  "The blueprints, once I've finished drawing them, are
> yours."

> > I also find it very difficult to setup the outlines of the project. I
mean
> > the customer doesn't always know what he want's and what the
possibilities
> > are. Of course the developer also has a consulting function and we try
to
> > open the eyes off the customer. But sometimes it's hard or impossible to
see
> > the needs of the whole business you're developing for.

> See above.  :-)

> I mean, how do you suppose the customer feels?  You're saying it will
> cost him this much and in the back of his mind he's saying, "how does
> s/he KNOW?  Is s/he just spouting numbers at me?  [Yes...]"

> How would you feel if you wanted to have a house built and a fellow
> walked up to you and said, "your house will cost you $100,000."  And you
> haven't even sat down and discussed with him what kind of house you
> want?  It's impossible of course... but consultants do it every day, and
> _that is a big reason _why they starve.

> [ooh, I should be giving a seminar right now and charging $2,000 a seat
> for tickets.]  ;-)

> > How is the rest of you making up contracts? A nice example I think are
> > reports, there always some reports missing that they didn't think of. Do
you
> > include them all in the contract or do you make them dynamic?
> > What search options do you want in a customer database, just by name and
ID,
> > or also by adres, phone number or any part of a name or adres. Do you
ask
> > the customer upfront or do you include al these features by default?
> > How much time do you spent with the customer to talk about the project.

> Every single thing is covered by a task-order.  If Susie Secretary talks
> about a report she'd really like to have ... it don't mean squat unless
> and until Sally Boss puts her Jane Hancock on another task-order.  "Any
> contemporaneous or verbal understandings between the parties are
> superseded by or fully stated within this written document."  Even if
> someone said to Susie that yes, it sounds like a really good idea, or
> even, yes, we _can do that, does NOT mean that we are thereby obligated
> TO do it.

> I once had a client, subsequently dropped for this reason, who kept
> trying to push our company's buttons on this point.  I finally said,
> very calmly, "Mr. Jones, read paragraph six."  And hung up.  Invoking
> the other paragraph which stated that the client was not obligated to
> issue task-orders -and- that we were not obligated to accep them, we
> never again accepted a task order from this client.

> > I'm still a 'young' Access developer (about 6 years of which 3
> > semi-professional, still got a day job) and I have learned a lot about
the
> > technical side of developing, but the commercial side is damn difficult
for
> > me. Probably the reason why I can't make a full time living out of it
rather
> > than the quality of the application.

> > Anyone who wants to share thoughts about this with me or can give me
some
> > good hints on how to approach the commercial side of developping, is
most
> > welcome.

> If you want to do consulting/contracting as a profession ... and I doubt
> you do, if you are comfortable in your day-job ... then Mr. Holtz's book
> is required reading.  The programming is not what will get you -- anyone
> can do the programming.  What will save you or kill you is how you
> handle the BUSINESS of services work.

> Be warned:  it's a very, very low-margin business that involves a lot of
> hours.

> ----------------------------------------------------------------
> Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259

> > Fast(!), automatic table-repair with two clicks of the mouse!
> > ChimneySweep(R):  Release 4.0 is here!!
> > http://www.sundialservices.com/products/chimneysweep



Wed, 16 Jun 2004 00:17:11 GMT
 TechTips: Consulting, and making a living at it
Steve,

    I think your points are excellent and can be summed up with one comment.

    Computer software is a tool to solve a business problem. Implementing
technology for the sake of technology does not impress the business.
Implementing technology that solves a business problem ensures impressing
the business and creates new opportunities for those that participated

--
******************************
Fred Parker
I hail from Hotmail
My Handle is eticket2000



Wed, 16 Jun 2004 01:11:01 GMT
 TechTips: Consulting, and making a living at it
Thank you for starting this thread. I greatly appreciate your sharing
your experiences, as do many other readers, I am sure.
And (of course I realise this is asking for a "blueprint" that costs
money, too) - do you happen to have a rough draft of a contract like you
are using somewhere on your web site? Or something looking remotely like
it? You shared a wealth of information already, and this would be
tremendously helpful.

Sincerely,
Pavel

Quote:

> snip-snip...

> I once had a client, subsequently dropped for this reason, who kept
> trying to push our company's buttons on this point.  I finally said,
> very calmly, "Mr. Jones, read paragraph six."  And hung up.  Invoking
> the other paragraph which stated that the client was not obligated to
> issue task-orders -and- that we were not obligated to accep them, we
> never again accepted a task order from this client.

> snip...



Wed, 16 Jun 2004 01:40:26 GMT
 TechTips: Consulting, and making a living at it
Pavel
Whilst this crowd may not have template contracts, they do have a lot of
stuff about project management. (and nearly everything else).
Fairly lively descussion groups.

http://www.techrepublic.com/

peter walker



Quote:
> Thank you for starting this thread. I greatly appreciate your sharing
> your experiences, as do many other readers, I am sure.
> And (of course I realise this is asking for a "blueprint" that costs
> money, too) - do you happen to have a rough draft of a contract like you
> are using somewhere on your web site? Or something looking remotely like
> it? You shared a wealth of information already, and this would be
> tremendously helpful.

> Sincerely,
> Pavel


> > snip-snip...

> > I once had a client, subsequently dropped for this reason, who kept
> > trying to push our company's buttons on this point.  I finally said,
> > very calmly, "Mr. Jones, read paragraph six."  And hung up.  Invoking
> > the other paragraph which stated that the client was not obligated to
> > issue task-orders -and- that we were not obligated to accep them, we
> > never again accepted a task order from this client.

> > snip...



Wed, 16 Jun 2004 02:23:12 GMT
 TechTips: Consulting, and making a living at it


Again, a fine piece of advice ;-)

My experience is (sadly, I must say) that being a consultant is much more
about being a businessman than it is being a craftsman. This took me years to
understand, and I still have problems taking the appropriate concequences of
this fact. Less "techno-babble", more "money-babble".

Another experience: You have more time than you believe (Not for developing
applications, though), a seemingly fast changing world also moves sloooowly.
This also implies you may not get things to happen as fast as you want.
Projects may easily be delayed for a year.

Just my 2 cents.

--
Bjoerge Saether
Asker, Norway



Wed, 16 Jun 2004 03:45:04 GMT
 TechTips: Consulting, and making a living at it


Quote:
> 8.  It also seems to that if the object is to make money doing
> something you enjoy, then you can't afford to mess around learning
> things that are cool, but not useful.  Learning programming because it
> is challenging and fun, is a recipe for having a day job.

This hit me right in the forehead..;-)
A problem, this, balancing curiosity and creativity with business "aims". I
believe this is one of the most difficult parts when working alone - noone
there to enforce dicpline...

Thanks for sharing your experience with us !

--
Bjoerge Saether
Asker, Norway



Wed, 16 Jun 2004 03:53:13 GMT
 
 [ 22 post ]  Go to page: [1] [2]

 Relevant Pages 

1. TechTips: What makes a Paradox table go corrupt

2. TechTips: What makes a Paradox table go corrupt

3. Call 1-800-856-2469, LIVE LIVE LIVE 809-474-7588 code4389

4. Nationwide-155022--ERP-Consulting Applications-ERP Consulting Managers

5. ! New York Region - Consulting Director - HR and Financial BPR Consulting

6. ! New York Region - Consulting Director - HR and Financial BPR Consulting

7. ! New York Region - Consulting Director - HR and Financial BPR Consulting

8. Advice please for making making a database

9. Free Oracle SQL Tutorial w/ Live Practice Database - fixes & mods made.

10. TechTips: Speeding up Paradox queries


 
Powered by phpBB® Forum Software