On Wed, 24 Nov 2004 20:14:03 +0100, Jaromir Subcik wrote:
>
>----- Paul Curtis wrote -----
>>Why should I offer such a thing?
>
>Paul, I understand you, but one case I try to point to you: imagine
>small firm needed only for one product line some programing control
>with a small alphanumeric display. This firm ask someone to make this
>SW and expect, that it can change texts in "printf" (language
>mutations) by oneself. If this SW is small enought, they appreciate
>limited version of IDE and in this specific case IAR is the winner.
>Certainly it is not valid for larger systems, but if this firm starts
>with IAR.....

I have faced this same type of scenario before with certain clients.
There is no way I want my clients recompiling code to update message
tables -- this is a massive train wreck waiting to happen! What happens
if they use a different version of the compiler you used? What happens
if they flip a few compile options differently than you did? What
happens if they inadvertantly (or not) change something else in the
source code? I wouldn't want to be respoinsible for supporting that
mess... 

Instead, I would design a system that has user downloadable message
tables as part of the application. That way the end user/client can
change messages to their heart's content and never mess with your
compiled application. You could even write a neat PC front-end that
makes their job easy and stores different sets of messages on the PC.
Much safer and a whole lot easier to support.

Matt Pobursky
Maximum Performance Systems

On Wed, 24 Nov 2004 16:41:42 -0600, Matt wrote:

>Instead, I would design a system that has user
downloadable message
>tables as part of the application. That way the end user/client can
>change messages to their heart's content and never mess with your
>compiled application. You could even write a neat PC front-end that
>makes their job easy and stores different sets of messages on the PC.
>Much safer and a whole lot easier to support.

Will they pay for the effort for all these extras?  Remember, the point was
about a "small firm needed only for one product line some programming
control
with a small alphanumeric display..."  To get a simple display project, are
they
going to want all the extra software, serial port interface, command protocols,
and all the extra testing to verify it, and the cost along many dimensions, just
to get a display up and running?

I can tell you what would happen in a meeting in my small business place if I
took a "display project" and started suggesting these kinds of
additions to it,
without a clearly demonstrable value to the immediate purpose at hand.

Jon

On Wed, 24 Nov 2004 15:52:01 -0800, Jonathan Kirwan wrote:
>
>On Wed, 24 Nov 2004 16:41:42 -0600, Matt wrote:
>
>>Instead, I would design a system that has user downloadable message
>>tables as part of the application. That way the end user/client can
>>change messages to their heart's content and never mess with your
>>compiled application. You could even write a neat PC front-end that
>>makes their job easy and stores different sets of messages on the PC.
>>Much safer and a whole lot easier to support.
>
>Will they pay for the effort for all these extras?

Will they pay you when they screw up the process and ask you to fix it? 
Will you have time to drop whatever you're doing in the future to fix 
their screwup (even if they DO pay you)? You know they'll want it done
pronto since it most certainly "will be holding us up from shipping
units!" I wonder how many consultants have heard this one before? :-)

I guess this goes to what your business philosophy is and how you look
at solving potential future problems before they happen. Cutting loose
a client with an IDE/Compiler and expecting them to be able to
successfully recompile with new messages is doomed to failure, in my
experience. If they can handle that task successfully, then they most
likely can handle writing the code themselves in the first place. I'd
prefer to make sure there's not much chance of them screwing up by
design. To me that's just good engineering and part of solving the
problem.

>Remember, the point was about a "small firm
needed only for one
>product line some programming control with a small alphanumeric
>display..." To get a simple display project, are they going to want
>all the extra software, serial port interface, command protocols, and
>all the extra testing to verify it, and the cost along many
>dimensions, just to get a display up and running?

Frankly, I don't see it as that huge an addition to the project as long
as it's planned for up-front. I'd actually rather spend the time up-
front engineering an elegant solution -- even if I have to contribute
some of the cost -- than fixing a problem that's almost sure to come up
later at a most inconvenient (for me) time. That's just been my
experience over the years. 

I also don't see it having to be all that complicated an addition to
the basic project. I have at least half the software in my "toolkit"
to
add these capabilities to the project already. It certainly wouldn't be
any harder or more time consuming than having to provide the client
with a complete FET/IDE setup, installing and testing it for them,
documenting the process and teaching them how to do it. And in the long
term it will still be riskier than having a dedicated method that was
designed to store custom messages. Maybe this is one of those things
you and I would disagree philosophically on, but I see something like
this as an essential part of the project that probably wasn't
considered up-front rather than an "add-on" frill. 

I believe most clients (especially non-technical ones) tend to 
underestimate project complexity. Show a salesman or manager the tiny 
little battery powered widget you spent the last several hundred hours 
designing and he'll yawn... "Is THAT all there is to it? What took you

so long!?" To quote a friend of mine... "The roadside is littered with

the bones of consultants who took on projects that were
'simple'". 

Another aspect of this situation is that if they really are a small 
firm and "can't afford to do the job right the first time" then
they 
are the kind of client that throws up a huge red flag for me. They're 
likely to be slow payers, question every part of every charge you bill 
them for, make several major changes to the project after it is well 
under way and expect you to accommodate them at no charge and in 
general try to get everything for free they can. At that point I
question whether I really want them as clients or not. Again, that's
been my experience over the years.

>I can tell you what would happen in a meeting in
my small business place if I
>took a "display project" and started suggesting these kinds of
additions to it,
>without a clearly demonstrable value to the immediate purpose at hand.

But you see -- it's MORE than a simple display project! It's really a 
simple display with a user programmable/customizable message base. The 
client defined it as a "simple" project, but it's really not as
simple
as they think or present it to be.

I dunno, maybe I'm just more of a salesman than you are but I'd
certainly try to sell them on the positive aspects of going this route.
In fact, I wouldn't even bring up the option of them diddling with the
compiler themselves mostly because I think it's a bad idea. I think
there's a largely demonstrable benefit to the client and that's self
reliance and reliability of the process. They don't want to have to
come back to me later and pay me more money because the process just
works.

If it came down to it and I really wanted their business, I'd recommend
the route I suggested earlier. If they refused, then I'd make perfectly
clear that if things got screwed up I'd have to charge them my normal 
rate for any additional work I'd do and that I might not be available 
right when they needed me. I wouldn't feel comfortable giving a 
warranty or supporting software I'm not in control of.

It's interesting that most of my clients in the past that went the 
"cheap and dirty" route have almost always have come back and asked me

to do it right after the fact. From that point on they usually trust me 
and don't question my motives on new projects. Most of my clients bring
repeat business to me and I get very good word-of-mouth 
recommendations, I think in part because I'm a straight shooter and
tell it like I see it. At least that's what many of them have told me.
I'd like to think I give them the best value for their money I can and 
that's my goal. Sometimes spending more up-front is a much better 
investment. Sometimes the clients don't like what I have to say but 
they generally trust me because I'm usually right. Hmmm... I didn't 
mean for that to sound arrogant, I meant I normally won't stake out a 
position unless I have a high confidence level in it. ;-)

OK then, enough from me. I do find this area of the consulting business
very interesting. Dealing with clients is kind of a mixture of art and
science. I'm always interested in how others see things and how they
handle all the little challenges that inevitably come up.

Matt Pobursky
Maximum Performance Systems

On Wed, 24 Nov 2004 21:31:15 -0000, Paul Curtis wrote:
>
>John,
>
>>My suggestion on a "limited" version of the compiler is
maybe
>>release a version with a code limit and no "official"
support
>>for a reduced price (in the $250 USD range??).
>>
>>I think there are a lot of hobbyists/students who would like
>>to use your tool, but probably can't pony up $600+ for
>>something they don't use for professional purposes.
>>
>>I realize there is msp430-gcc, but tools like yours really do
>>save time and frustration.
>>
>>I might add, support on this list is EXCELLENT, it's really
>>nice to see people actually answering questions and trying to
>>be helpful!
>
>We already offer students and educational establishments our software at
>just 99 ($150 or maybe a tad more now) which is, err, dirt cheap.
>We've sold a number of 10-seat licenses to unis on this basis, and
>they're happy.
>
>I reckon the "hobbyist" license is the death knell for a
company--it's
>what Introl did before their boar sank. But I'm always open to
>proposals for new licensing schemes...

Although I sort of took this thread off the beaten path...

I certainly understand where you're coming from Paul. As much of a
niche market as microcontroller development tool software is I am
always amazed that you guys can make a living at it. 

I've developed some products of my own and early on I came to the 
conclusion that the hobbyist market is no place to make a living 
-- unless of course the hobbyist market is huge -- and in the case of 
my products that wasn't the case. I decided that even though my 
products have some appeal to hobbyists, I'd live with the few sales I 
got from hobbyists that appreciated the value and bought regardless of 
price rather than try to sell a zillion of something (unlikely) at low 
margins. It also keeps the margins up for the commercial customers to
which the product actually has a good price/value ratio. 

I commend you guys for holding your line with price. It's a quality
toolset and it's priced where even the average small business can
afford it.

Matt Pobursky
Maximum Performance Systems

This is wisdom, Matt !!
You basicly have all the traps identified. 
There are in any kind of projects 4 serious threats, that you learn to
circumvent as 
you become old in the business. If ever. 

BUFFET PROJECTS
The goal is well defined in the clients mind. "We want something that
works".
The consultant thinks "This will work" and estimates the hours. 
Unfortunately there is no cork in the hole. "Natural additions" come
in for free. Clearly 
we can't use it if it does not have this and that. And oops do you need
more than 
300mAH battery ? We clearly don't have that. And "You should know the
industry 
standard is this and that. All our competition has this and that." 
And the budget cap prevails. After all, when are you really going outside the
box?

RESPONSIBILITY DEFERRAL
Now, you are making A and OtherCompany Inc. is making B. A and B has to work 
together. OtherCompany makes a quick B,  delivers and signs out. Unfortunately A

and B do not want to work together because of something OtherCompany did not 
anticipate. They feel they stuck to the specs, and they can verify the
functionality with 
a scope or whatever. (Maybe because the scope ground is optically isolated or 
something.) Othercompany is furthermore rather incompetent or chooses to be so. 
Since YOU are goal oriented, competent and more readily available - you adjust A
to 
compensate for the shortcomings of B. 
The technical details are of course beyond the client and all he sees is the
broken 
Gantt card. This annoys him, but luckily everybody were working for a fixed
price.

COMMUNICATION STALL
Basicly you have to pound all feedback out of the client. Three days before
chaos 
they will tell you about what does not work. Or not at all. They will try to
plug it in and 
basicly decide it does not work. Fortunately for the client, there are no time
limits for 
his testing of the system, so he stalls payment until he sees fit to test the
deliverable.

DO-IT-YOURSELF
Scraped budget. We have people IN-house who can take certain parts of the
project. 
We don't want to pay consultant fees. 
Net result: In-house speed, in-house quality and consultant frustration.
You make nice hardware and drivers for a board. The local "expert"
programs 40 
kByte source code with hard left adjusted margin and no comments. 
And now your crappy board is unreliable and has blown an xray tube. Fix it !
Now try proving it was their fault WITHOUT fixing it first. 


My best advice after having spent upwards of 20 years doing it wrong again and 
again. SELECT your clients. It's scary as hell, and every time one walks
away from 
the table and says no thanks, you will think YOU were being weighed and found
too 
light. If you are in doubt of them, scare them. Let them show you the money.
If they don't want to pay for doing it right, YOU will end up doing it.
After all, they 
purchased a solution, did they not ?? How many here has worked for free for 4 
months in a row and seen the bank account go to -50 grand ? 

Another good scare if you suspect disorganizedness: Ask them to compile a Final 
Assembly Test (FAT) which goes like 
...
14) Press the green button. Assert the system shows the go menu. 
15) Press go. Assert the system starts up. 
...
Let them have time to do it. If they are too disorganized for that, they go hire

somebody who is still learning and who still uses their own credit rating to
finish 
projects..  IF your system can do all the steps in the FAT, it works and you get
paid. If 
the FAT has to be changed, the budget changes too.
Meanwhile you sit down and make a list of ASSUMPTIONS - what information, 
ressources and tools that have to be present and how fast. Now you can talk
price. 
And you can go higher than you think. Because now you are a pro. And that costs.

If the project is "real research" there is always a possibility of
breaking the budget in 
a bad way for both parties. In this case, build in "Go Options" along
the way. At 
certain milestones, best at completion of Work Packages (defined by FATs) both 
parties have a Go-Option. To continue or document and leave it where it is. 
This prevents real back-breakers where one of the parties are forced to fulfill
a 
contract that is really not worth it. 

Finally: A great team takes a lot of luck to find. You have to kiss lots of
frogs first.
If you make a team with inhouse people, make sure they ARE a team at all. 
The client is most likely interested in getting the IP purchased secured in the 
company, so they are not held hostage later by the consultant. 
So build in teaching of the inhouse people. Sometimes you will find marvellous 
friends and learn yourself. If it does not work, speak up to the teamleader. If
it does 
work, praise. Select your tools, processors, platforms etc. WITH the company to
suit 
their needs. Teach while learning. Spend time with them. 
That's also what gets you your next project. 
Open Source Consultancy is very rewarding for all involved parties, when done
right.

And bordered by the two lines of the FAT and the ASSUMPTIONS everybody knows 
what the goal is. 

Kent
who dunnit wrong lots

> 
> On Wed, 24 Nov 2004 15:52:01 -0800, Jonathan Kirwan wrote:
> >
> >On Wed, 24 Nov 2004 16:41:42 -0600, Matt wrote:
> >
> >>Instead, I would design a system that has user downloadable
message
> >>tables as part of the application. That way the end user/client
can
> >>change messages to their heart's content and never mess with
your
> >>compiled application. You could even write a neat PC front-end
that
> >>makes their job easy and stores different sets of messages on the
PC.
> >>Much safer and a whole lot easier to support.
> >
> >Will they pay for the effort for all these extras?
> 
> Will they pay you when they screw up the process and ask you to fix it? 
> Will you have time to drop whatever you're doing in the future to fix 
> their screwup (even if they DO pay you)? You know they'll want it done
> pronto since it most certainly "will be holding us up from shipping
> units!" I wonder how many consultants have heard this one before? :-)
> 
> I guess this goes to what your business philosophy is and how you look
> at solving potential future problems before they happen. Cutting loose
> a client with an IDE/Compiler and expecting them to be able to
> successfully recompile with new messages is doomed to failure, in my
> experience. If they can handle that task successfully, then they most
> likely can handle writing the code themselves in the first place. I'd
> prefer to make sure there's not much chance of them screwing up by
> design. To me that's just good engineering and part of solving the
> problem.
> 
> >Remember, the point was about a "small firm needed only for one
> >product line some programming control with a small alphanumeric
> >display..." To get a simple display project, are they going to
want
> >all the extra software, serial port interface, command protocols, and
> >all the extra testing to verify it, and the cost along many
> >dimensions, just to get a display up and running?
> 
> Frankly, I don't see it as that huge an addition to the project as
long
> as it's planned for up-front. I'd actually rather spend the time
up-
> front engineering an elegant solution -- even if I have to contribute
> some of the cost -- than fixing a problem that's almost sure to come
up
> later at a most inconvenient (for me) time. That's just been my
> experience over the years. 
> 
> I also don't see it having to be all that complicated an addition to
> the basic project. I have at least half the software in my
"toolkit" to
> add these capabilities to the project already. It certainly wouldn't
be
> any harder or more time consuming than having to provide the client
> with a complete FET/IDE setup, installing and testing it for them,
> documenting the process and teaching them how to do it. And in the long
> term it will still be riskier than having a dedicated method that was
> designed to store custom messages. Maybe this is one of those things
> you and I would disagree philosophically on, but I see something like
> this as an essential part of the project that probably wasn't
> considered up-front rather than an "add-on" frill. 
> 
> I believe most clients (especially non-technical ones) tend to 
> underestimate project complexity. Show a salesman or manager the tiny 
> little battery powered widget you spent the last several hundred hours 
> designing and he'll yawn... "Is THAT all there is to it? What
took you 
> so long!?" To quote a friend of mine... "The roadside is littered
with 
> the bones of consultants who took on projects that were
'simple'". 
> 
> Another aspect of this situation is that if they really are a small 
> firm and "can't afford to do the job right the first time"
then they 
> are the kind of client that throws up a huge red flag for me. They're 
> likely to be slow payers, question every part of every charge you bill 
> them for, make several major changes to the project after it is well 
> under way and expect you to accommodate them at no charge and in 
> general try to get everything for free they can. At that point I
> question whether I really want them as clients or not. Again, that's
> been my experience over the years.
> 
> >I can tell you what would happen in a meeting in my small business
place if I
> >took a "display project" and started suggesting these kinds
of additions to it,
> >without a clearly demonstrable value to the immediate purpose at hand.
> 
> But you see -- it's MORE than a simple display project! It's
really a 
> simple display with a user programmable/customizable message base. The 
> client defined it as a "simple" project, but it's really not
as simple
> as they think or present it to be.
> 
> I dunno, maybe I'm just more of a salesman than you are but I'd
> certainly try to sell them on the positive aspects of going this route.
> In fact, I wouldn't even bring up the option of them diddling with the
> compiler themselves mostly because I think it's a bad idea. I think
> there's a largely demonstrable benefit to the client and that's
self
> reliance and reliability of the process. They don't want to have to
> come back to me later and pay me more money because the process just
> works.
> 
> If it came down to it and I really wanted their business, I'd
recommend
> the route I suggested earlier. If they refused, then I'd make
perfectly
> clear that if things got screwed up I'd have to charge them my normal 
> rate for any additional work I'd do and that I might not be available 
> right when they needed me. I wouldn't feel comfortable giving a 
> warranty or supporting software I'm not in control of.
> 
> It's interesting that most of my clients in the past that went the 
> "cheap and dirty" route have almost always have come back and
asked me 
> to do it right after the fact. From that point on they usually trust me 
> and don't question my motives on new projects. Most of my clients
bring
> repeat business to me and I get very good word-of-mouth 
> recommendations, I think in part because I'm a straight shooter and
> tell it like I see it. At least that's what many of them have told me.
> I'd like to think I give them the best value for their money I can and

> that's my goal. Sometimes spending more up-front is a much better 
> investment. Sometimes the clients don't like what I have to say but 
> they generally trust me because I'm usually right. Hmmm... I
didn't 
> mean for that to sound arrogant, I meant I normally won't stake out a 
> position unless I have a high confidence level in it. ;-)
> 
> OK then, enough from me. I do find this area of the consulting business
> very interesting. Dealing with clients is kind of a mixture of art and
> science. I'm always interested in how others see things and how they
> handle all the little challenges that inevitably come up.
> 
> Matt Pobursky
> Maximum Performance Systems
> 
> 
> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 

On Wed, 24 Nov 2004 21:23:04 -0600, Matt wrote:

>On Wed, 24 Nov 2004 15:52:01 -0800, Jonathan Kirwan
wrote:
>>
>>On Wed, 24 Nov 2004 16:41:42 -0600, Matt wrote:
>>
>>>Instead, I would design a system that has user downloadable message
>>>tables as part of the application. That way the end user/client can
>>>change messages to their heart's content and never mess with
your
>>>compiled application. You could even write a neat PC front-end that
>>>makes their job easy and stores different sets of messages on the
PC.
>>>Much safer and a whole lot easier to support.
>>
>>Will they pay for the effort for all these extras?
>
>Will they pay you when they screw up the process and ask you to fix it? 

I guess I'd try and get the design done appropriately.  If they need those
extras, then it's part of the design.  But if I'm just adding it at my
own
behest and, as I wrote, without "a clearly demonstrable value to the
immediate
purpose at hand," and produced a more expensive and more complex product --
then
I don't see why I'd be doing the client any favors.

>Will you have time to drop whatever you're
doing in the future to fix 
>their screwup (even if they DO pay you)? You know they'll want it done
>pronto since it most certainly "will be holding us up from shipping
>units!" I wonder how many consultants have heard this one before? :-)

You are simply bringing up a strawman, Matt.  If it is appropriate to the
design, a necessary ingredient based on appropriate specifications for what is
required, then do it.  I didn't say otherwise.  If downloadable messages is
an
essential part of the design to meet the requirements, do it.  I was just saying
that one shouldn't introduce these things without a clear value for the
purpose
at hand.  If it is clearly required, then do it.  No argument from me, in that
case.

I was addressing myself to the idea of simply coming up with imaginative ideas
to download messages that wasn't a necessary part of what the customer is
looking for.  I've seen many a project get feature laden by creative
programmers
without much sense for the extra costs from after-sale support, documentation,
manufacturing, testing, parts, board size, power consumption, etc. only to have
actually done the customer poorer, in the end.  If that doesn't fit the
case,
then it doesn't fit the case.  But the point remains.

>I guess this goes to what your business philosophy
is and how you look
>at solving potential future problems before they happen. Cutting loose
>a client with an IDE/Compiler and expecting them to be able to
>successfully recompile with new messages is doomed to failure, in my
>experience. If they can handle that task successfully, then they most
>likely can handle writing the code themselves in the first place. I'd
>prefer to make sure there's not much chance of them screwing up by
>design. To me that's just good engineering and part of solving the
>problem.

It's a tight line to walk, Matt.  You make it sound so simple, by talking
from
an extreme edge of the situation.  But the reality isn't easy to manage. 
If you
add a feature, there are costs.  You may not see them, up front, but they are
there.  They are always there.  On the other hand, if you don't take
advance
notice of potential problems and anticipate them, there are costs there, once
again.  Treading this well takes experience.  But it's never as simple as
your
words above seem to make it sound, in trying to make yourself sound obviously
plausible.

My advice is to be careful and not cavalier when considering new features -- and
especially ones that may add an unnecessary serial port, power requirements,
connectors, various software parts such as low and high level drivers, parsers,
flash programming features (which, on the MSP430 and on some other controllers,
limits the voltage range and adds peak current requirements to the existing
power system), etc., all for the idea of "Hey, let's add the ability
to download
customer messages!"

If it's needed, fine.  If that need is evidenced by the short and long term
requirements, fine.  But when considering something like this, it's good to
carefully examine various alternatives -- many of which may have nothing to do
with hardware or software, but with documentation or detailed dialog with the
customer to negotiate changes in their procedures, etc.

But I wasn't making any sweeping statements about the whole idea.  If
it's
essential, then do it.

>>Remember, the point was about a "small
firm needed only for one
>>product line some programming control with a small alphanumeric
>>display..." To get a simple display project, are they going to
want
>>all the extra software, serial port interface, command protocols, and
>>all the extra testing to verify it, and the cost along many
>>dimensions, just to get a display up and running?
>
>Frankly, I don't see it as that huge an addition to the project as long
>as it's planned for up-front. I'd actually rather spend the time
up-
>front engineering an elegant solution -- even if I have to contribute
>some of the cost -- than fixing a problem that's almost sure to come up
>later at a most inconvenient (for me) time. That's just been my
>experience over the years. 

I've been doing this stuff, as a sole proprietor for ... well, for 1099MISC
income, for 25 years now.  Programming as a profession for 34 years.

>I also don't see it having to be all that
complicated an addition to
>the basic project. I have at least half the software in my
"toolkit" to
>add these capabilities to the project already. It certainly wouldn't be
>any harder or more time consuming than having to provide the client
>with a complete FET/IDE setup, installing and testing it for them,
>documenting the process and teaching them how to do it. And in the long
>term it will still be riskier than having a dedicated method that was
>designed to store custom messages. Maybe this is one of those things
>you and I would disagree philosophically on, but I see something like
>this as an essential part of the project that probably wasn't
>considered up-front rather than an "add-on" frill. 

These comments just seem to make my point, all the more, Matt.  But I won't
belabor it.  If you see why, fine.  If not, some others will see why.  I'm
happy
to leave it at that, since I now suspect from the above that it would take far
more time than I want to right now to explain sufficiently for you to follow.
For now... either you see why I'm concerned with the above paragraph, or
you
don't.

>I believe most clients (especially non-technical
ones) tend to 
>underestimate project complexity.

Some even think they understand what's better for them when they really
don't.
I've had cases where I had to tell them I was doing exactly what they said
they
wanted (after I tried to convince them why it was likely to fail) and then turn
around and do exactly what they told me NOT to do, make them pay for it, and
then smile as they believed they got what they asked for when they see it work.
In one case, I made one department of a large corporation (Tektronix) pay for
work I did for another department who would be responsible for feeding the
necessary data, despite a refusal to help out the other organization when I
first brought up the need.  In the end, they were extremely happy because the
system worked, as the other group supporting them were able to function in their
necessary role.  Did I admit to them that they were billed for work they had
told me not to do?  No.  And everyone was happy.

Yes, I agree with the thrust of your comment.  I'd add that I also tend to
be
more positive, as well, than I sometimes should be.  But I live with it and
compensate where I can.

>Show a salesman or manager the tiny 
>little battery powered widget you spent the last several hundred hours 
>designing and he'll yawn... "Is THAT all there is to it? What took
you 
>so long!?" To quote a friend of mine... "The roadside is littered
with 
>the bones of consultants who took on projects that were
'simple'". 

Hehe.  Yes.

That applies to anything to do with projects that have new elements.  I am
working on a kitchen for my daughter.  Almost at every turn, I find something
else to delay me and make me learn something new.  The corner angle where
I'm
placing a counter isn't 90-degrees, but instead moves out fully 7/8"
from the
counter corner to the front edge.  So I have to cut the counter along a gradual
slant.  Unanticipated time is spent.  Then, the floor isn't as level as it
should be.  More time.  Then, the sink that I bought (standard size) will
correctly fit into the countertop, but... it just misses things for the standard
cabinet I also bought and already mounted.  So I have to use a router to avoid
cutting into the cabinet and set the rail of the sink into a routed trough on
that side.  And, since the countertop has a back splash, it turns out that the
back side cut is too close for my jig saw to fit (too wide of a body) so now I
need to go buy another tool that can cut close, like that.  Etc.  You get the
idea.

Reality impinges.

>Another aspect of this situation is that if they
really are a small 
>firm and "can't afford to do the job right the first time"
then they 
>are the kind of client that throws up a huge red flag for me. They're 
>likely to be slow payers, question every part of every charge you bill 
>them for, make several major changes to the project after it is well 
>under way and expect you to accommodate them at no charge and in 
>general try to get everything for free they can. At that point I
>question whether I really want them as clients or not. Again, that's
>been my experience over the years.

Well, this is a different issue, Matt.  Really, if you are just inflating the
project so as to be sure that the client isn't stingy and difficult to deal
with, that's the wrong reason to be doing it.  It should be exactly because
it
is what they need.

In other words, doing a small, appropriately low-cost project isn't
inherently,
in and of itself, a bad thing.

Of course, if the customer is trying to force you to do what you KNOW will come
back to bite you and your other dealings with them contribute also to the idea
that they are going to shift all the burdens onto you and try and take from you
without giving back, then yes.

I've long ago learned how to spot these.  What I look for is long term
relationships -- everything in business, really, boils down to
"relationship."
If they aren't people I'd like to be married to, I gracefully bow out
as soon as
I can.  But I can usually spot that pretty fast.

>>I can tell you what would happen in a meeting
in my small business place if I
>>took a "display project" and started suggesting these kinds
of additions to it,
>>without a clearly demonstrable value to the immediate purpose at hand.
>
>But you see -- it's MORE than a simple display project! It's
really a 
>simple display with a user programmable/customizable message base. The 
>client defined it as a "simple" project, but it's really not
as simple
>as they think or present it to be.

Maybe.  You haven't convinced me.

>I dunno, maybe I'm just more of a salesman
than you are but I'd
>certainly try to sell them on the positive aspects of going this route.
><snip>

And fail to mention where it may hurt them?

>OK then, enough from me. I do find this area of the
consulting business
>very interesting. Dealing with clients is kind of a mixture of art and
>science. I'm always interested in how others see things and how they
>handle all the little challenges that inevitably come up.

I love the work, too, Matt.  I really do.  It consumes my every waking hour and
it does so, pleasantly and without any self-abnegation.

Jon

Hi Kent, interesting! Very jaded outlook for one so young ;@}, and you 
missed what, to me anyway, has been my greatest source of income.

The BUDGETS BLOWN PROJECT. This usually occurs where one of the below 
scenarios has unfolded to its obvious conclusion. A mess. The potential 
client hired company A because they wanted a 'reputable firm' or
because 
so and so who works in the typing pool has a brother who knows the uncle 
of the company owners wife. Anyway, they've been charged big bucks, the 
project is way over time, and way over budget. The original contractor 
has been fired, or has disappeared from view. The client wants it fixed, 
  it's 'almost working', so shouldn't take too much. He
doesn't trust 
anybody in our crooked industry anymore, and they have littel or no 
budget available.

Fortunately I'm cheap. I only have me to employ. I examine the job. 90% 
of the time the hardware is absolute crap, and the software looks like 
the chimps tea party was given type writers to play with.However they've 
heard 'it just needs a new PCB design' too many times, or you're
the 
fifth attempt at fixing it, and "everybody else claimed the software 
needed re-writing, and they stuffed it too'.

I make them one offer only, take it or leave it. I will patch the 
existing system for $n. It will have absolutely the least level of 
functionality that makes it useful. Here is the list of tests it will 
pass. If it passes these tests for a lump sum of $m payable 25% with 
order, 25% on PCB delivery, 25% on completion of programming and 25% on 
passing final tsting, or for $p each week, for a maximum number of x 
weeks I will deliver the product they oredered plus a list of 
improvements, and here is the testign schedule it will pass.

Normally these situations arise because the client has no idea what is 
possible, and the 'designer' has not taken the time to adequately
study 
the target industry, filter out what is desirable, and what isn't, then 
educate the client on what they really want.

Kent Johansen wrote:

> This is wisdom, Matt !!
> You basicly have all the traps identified. 
> There are in any kind of projects 4 serious threats, that you learn to
circumvent as 
> you become old in the business. If ever. 
> 
> BUFFET PROJECTS
> The goal is well defined in the clients mind. "We want something that
works".
> The consultant thinks "This will work" and estimates the hours. 
> Unfortunately there is no cork in the hole. "Natural additions"
come in for free. Clearly 
> we can't use it if it does not have this and that. And oops do you
need more than 
> 300mAH battery ? We clearly don't have that. And "You should know
the industry 
> standard is this and that. All our competition has this and that." 
> And the budget cap prevails. After all, when are you really going outside
the box?
> 
> RESPONSIBILITY DEFERRAL
> Now, you are making A and OtherCompany Inc. is making B. A and B has to
work 
> together. OtherCompany makes a quick B,  delivers and signs out.
Unfortunately A 
> and B do not want to work together because of something OtherCompany did
not 
> anticipate. They feel they stuck to the specs, and they can verify the
functionality with 
> a scope or whatever. (Maybe because the scope ground is optically isolated
or 
> something.) Othercompany is furthermore rather incompetent or chooses to be
so. 
> Since YOU are goal oriented, competent and more readily available - you
adjust A to 
> compensate for the shortcomings of B. 
> The technical details are of course beyond the client and all he sees is
the broken 
> Gantt card. This annoys him, but luckily everybody were working for a fixed
price.
> 
> COMMUNICATION STALL
> Basicly you have to pound all feedback out of the client. Three days before
chaos 
> they will tell you about what does not work. Or not at all. They will try
to plug it in and 
> basicly decide it does not work. Fortunately for the client, there are no
time limits for 
> his testing of the system, so he stalls payment until he sees fit to test
the deliverable.
> 
> DO-IT-YOURSELF
> Scraped budget. We have people IN-house who can take certain parts of the
project. 
> We don't want to pay consultant fees. 
> Net result: In-house speed, in-house quality and consultant frustration.
> You make nice hardware and drivers for a board. The local
"expert" programs 40 
> kByte source code with hard left adjusted margin and no comments. 
> And now your crappy board is unreliable and has blown an xray tube. Fix it
!
> Now try proving it was their fault WITHOUT fixing it first. 
> 
> 
> My best advice after having spent upwards of 20 years doing it wrong again
and 
> again. SELECT your clients. It's scary as hell, and every time one
walks away from 
> the table and says no thanks, you will think YOU were being weighed and
found too 
> light. If you are in doubt of them, scare them. Let them show you the
money.
> If they don't want to pay for doing it right, YOU will end up doing
it. After all, they 
> purchased a solution, did they not ?? How many here has worked for free for
4 
> months in a row and seen the bank account go to -50 grand ? 
> 
> Another good scare if you suspect disorganizedness: Ask them to compile a
Final 
> Assembly Test (FAT) which goes like 
> ...
> 14) Press the green button. Assert the system shows the go menu. 
> 15) Press go. Assert the system starts up. 
> ...
> Let them have time to do it. If they are too disorganized for that, they go
hire 
> somebody who is still learning and who still uses their own credit rating
to finish 
> projects..  IF your system can do all the steps in the FAT, it works and
you get paid. If 
> the FAT has to be changed, the budget changes too.
> Meanwhile you sit down and make a list of ASSUMPTIONS - what information, 
> ressources and tools that have to be present and how fast. Now you can talk
price. 
> And you can go higher than you think. Because now you are a pro. And that
costs.
> 
> If the project is "real research" there is always a possibility
of breaking the budget in 
> a bad way for both parties. In this case, build in "Go Options"
along the way. At 
> certain milestones, best at completion of Work Packages (defined by FATs)
both 
> parties have a Go-Option. To continue or document and leave it where it is.

> This prevents real back-breakers where one of the parties are forced to
fulfill a 
> contract that is really not worth it. 
> 
> Finally: A great team takes a lot of luck to find. You have to kiss lots of
frogs first.
> If you make a team with inhouse people, make sure they ARE a team at all. 
> The client is most likely interested in getting the IP purchased secured in
the 
> company, so they are not held hostage later by the consultant. 
> So build in teaching of the inhouse people. Sometimes you will find
marvellous 
> friends and learn yourself. If it does not work, speak up to the
teamleader. If it does 
> work, praise. Select your tools, processors, platforms etc. WITH the
company to suit 
> their needs. Teach while learning. Spend time with them. 
> That's also what gets you your next project. 
> Open Source Consultancy is very rewarding for all involved parties, when
done right.
> 
> And bordered by the two lines of the FAT and the ASSUMPTIONS everybody
knows 
> what the goal is. 
> 
> Kent
> who dunnit wrong lots
> 
> 
>>On Wed, 24 Nov 2004 15:52:01 -0800, Jonathan Kirwan wrote:
>>
>>> 
>>> On Wed, 24 Nov 2004 16:41:42 -0600, Matt wrote:
>>> 
>>> >Instead, I would design a system that has user downloadable
message
>>> >tables as part of the application. That way the end user/client
can
>>> >change messages to their heart's content and never mess
with your
>>> >compiled application. You could even write a neat PC front-end
that
>>> >makes their job easy and stores different sets of messages on
the PC.
>>> >Much safer and a whole lot easier to support.
>>> 
>>> Will they pay for the effort for all these extras?
>>
>>Will they pay you when they screw up the process and ask you to fix it? 
>>Will you have time to drop whatever you're doing in the future to
fix 
>>their screwup (even if they DO pay you)? You know they'll want it
done
>>pronto since it most certainly "will be holding us up from shipping
>>units!" I wonder how many consultants have heard this one before?
:-)
>>
>>I guess this goes to what your business philosophy is and how you look
>>at solving potential future problems before they happen. Cutting loose
>>a client with an IDE/Compiler and expecting them to be able to
>>successfully recompile with new messages is doomed to failure, in my
>>experience. If they can handle that task successfully, then they most
>>likely can handle writing the code themselves in the first place.
I'd
>>prefer to make sure there's not much chance of them screwing up by
>>design. To me that's just good engineering and part of solving the
>>problem.
>>
>>
>>> Remember, the point was about a "small firm needed only for
one
>>> product line some programming control with a small alphanumeric
>>> display..."  To get a simple display project, are they going
to want
>>> all the extra software, serial port interface, command protocols,
and
>>> all the extra testing to verify it, and the cost along many
>>> dimensions, just to get a display up and running?
>>
>>Frankly, I don't see it as that huge an addition to the project as
long
>>as it's planned for up-front. I'd actually rather spend the
time up-
>>front engineering an elegant solution -- even if I have to contribute
>>some of the cost -- than fixing a problem that's almost sure to
come up
>>later at a most inconvenient (for me) time. That's just been my
>>experience over the years. 
>>
>>I also don't see it having to be all that complicated an addition
to
>>the basic project. I have at least half the software in my
"toolkit" to
>>add these capabilities to the project already. It certainly
wouldn't be
>>any harder or more time consuming than having to provide the client
>>with a complete FET/IDE setup, installing and testing it for them,
>>documenting the process and teaching them how to do it. And in the long
>>term it will still be riskier than having a dedicated method that was
>>designed to store custom messages. Maybe this is one of those things
>>you and I would disagree philosophically on, but I see something like
>>this as an essential part of the project that probably wasn't
>>considered up-front rather than an "add-on" frill. 
>>
>>I believe most clients (especially non-technical ones) tend to 
>>underestimate project complexity. Show a salesman or manager the tiny 
>>little battery powered widget you spent the last several hundred hours 
>>designing and he'll yawn... "Is THAT all there is to it? What
took you 
>>so long!?" To quote a friend of mine... "The roadside is
littered with 
>>the bones of consultants who took on projects that were
'simple'". 
>>
>>Another aspect of this situation is that if they really are a small 
>>firm and "can't afford to do the job right the first
time" then they 
>>are the kind of client that throws up a huge red flag for me.
They're 
>>likely to be slow payers, question every part of every charge you bill 
>>them for, make several major changes to the project after it is well 
>>under way and expect you to accommodate them at no charge and in 
>>general try to get everything for free they can. At that point I
>>question whether I really want them as clients or not. Again,
that's
>>been my experience over the years.
>>
>>
>>> I can tell you what would happen in a meeting in my small business
place if I
>>> took a "display project" and started suggesting these
kinds of additions to it,
>>> without a clearly demonstrable value to the immediate purpose at
hand.
>>
>>But you see -- it's MORE than a simple display project! It's
really a 
>>simple display with a user programmable/customizable message base. The 
>>client defined it as a "simple" project, but it's really
not as simple
>>as they think or present it to be.
>>
>>I dunno, maybe I'm just more of a salesman than you are but
I'd
>>certainly try to sell them on the positive aspects of going this route.
>>In fact, I wouldn't even bring up the option of them diddling with
the
>>compiler themselves mostly because I think it's a bad idea. I think
>>there's a largely demonstrable benefit to the client and
that's self
>>reliance and reliability of the process. They don't want to have to
>>come back to me later and pay me more money because the process just
>>works.
>>
>>If it came down to it and I really wanted their business, I'd
recommend
>>the route I suggested earlier. If they refused, then I'd make
perfectly
>>clear that if things got screwed up I'd have to charge them my
normal 
>>rate for any additional work I'd do and that I might not be
available 
>>right when they needed me. I wouldn't feel comfortable giving a 
>>warranty or supporting software I'm not in control of.
>>
>>It's interesting that most of my clients in the past that went the 
>>"cheap and dirty" route have almost always have come back and
asked me 
>>to do it right after the fact. From that point on they usually trust me 
>>and don't question my motives on new projects. Most of my clients
bring
>>repeat business to me and I get very good word-of-mouth 
>>recommendations, I think in part because I'm a straight shooter and
>>tell it like I see it. At least that's what many of them have told
me.
>>I'd like to think I give them the best value for their money I can
and 
>>that's my goal. Sometimes spending more up-front is a much better 
>>investment. Sometimes the clients don't like what I have to say but

>>they generally trust me because I'm usually right. Hmmm... I
didn't 
>>mean for that to sound arrogant, I meant I normally won't stake out
a 
>>position unless I have a high confidence level in it. ;-)
>>
>>OK then, enough from me. I do find this area of the consulting business
>>very interesting. Dealing with clients is kind of a mixture of art and
>>science. I'm always interested in how others see things and how
they
>>handle all the little challenges that inevitably come up.
>>
>>Matt Pobursky
>>Maximum Performance Systems
>>
>>
>>
>>
>>.
>>
>> 
>>Yahoo! Groups Links
>>
>>
>>
>> 
>>
>>
>>
> 
> 
> 
> 
> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
> 

Al, 

> Hi Kent, interesting! Very jaded outlook for one
so young 
> ;@}, and you missed what, to me anyway, has been my greatest 
> source of income.
> 
> The BUDGETS BLOWN PROJECT. This usually occurs where one of 
> the below scenarios has unfolded to its obvious conclusion. A 
> mess. The potential client hired company A because they 
> wanted a 'reputable firm' or because so and so who works in 
> the typing pool has a brother who knows the uncle of the 
> company owners wife. Anyway, they've been charged big bucks, 
> the project is way over time, and way over budget. 

This is the "THE GRANDIOSE TAX-SAVING GOVERNMENT PROJECT" scenario,
also
known as the "EDS BOTTOM LINE SUPPORT PROJECT" as it typically fails,
costs the taxpayer a shedload, EDS or Siemens don't need to deliver
anything working, and they get of scot free, get paid, and are anxious
for the gravytrain to continue!  We've had our fair share of them:

Child Support Agency (EDS):
http://news.independent.co.uk/low_res/story.jsp?storyX4793&host=3&dir=
62

Passports & "anybody can have a UK passport if you can write your name
and promise you're not a terrorist" fiasco (Siemens):
http://www.findarticles.com/p/articles/mi_m0CGN/is_1999_July_6/ai_550716
79

NATS New En-route Centre (IBM/Loral):
http://www.computerweekly.com/Article109436.htm

It even happens that we don't even know what it costs to build a place
where Members of the Scottish Parliament can all gather and
chat--incredible!
http://www.gallowaygazette.com/servlet/ContentServer?pagename=Newspaper/
Article&pid45579536650&cid67414664684

Nose to the grindstone everyone--we need to support EDS and Siemens with
our taxes!

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, and (soon) Atmel AVR processors  

To be fair to everybody ... I remember a mutual agreement to mark OT posts 
of this kind.
I do indulge myself in OT posts, no problem about that, but I just happen 
to have opened this one in the belief to find a non-OT post.
Regards
A_M

"
At 16.06 25/11/2004, PAUL CURTIS wrote:
This is the "THE GRANDIOSE TAX-SAVING GOVERNMENT PROJECT" scenario,
also
known as the "EDS BOTTOM LINE SUPPORT PROJECT" as it typically fails,
costs the taxpayer a shedload, EDS or Siemens don't need to deliver
anything working, and they get of scot free, get paid, and are anxious
for the gravytrain to continue!  We've had our fair share of them:

omissis...
"

Hah!!

You are describing exactly a project that I have intimate knowledge 
of. Except - I find that you have to walk a mile in the old 
consultants shoes before you criticize him. At least you will be a 
mile away and have his shoes - which is in 90% of the cases the best 
you will ever be able to get out of the project. 

That's when you need to ask 3 serious questions: 

1) Did the project fail because of consultant incompetence in 
technology or in the clients management, communication and business 
skills. Sometimes the failure is still employed.

2) Are they willing to spend the money it takes to regroup and 
redesign? Again. Scare them initially. I once met for 2 days with a 
potential Budget Break Client, whose favorite subjects were "How DO 
they price those hamburgers? Clearly that one is more worth than the 
cheaper one here.". "How CAN they sell gas on that corner 4 cents 
over the price of the ones just over there??" While negotiating 
projects with him, he hired 3 students to identify RS485 drivers for 
him. For a week. On the last day I told him on the phone what result 
they would arrive at, if they were good. I was right. Then he spent 
3 weeks, incommunicado, poking around in a set of freeware DVDs 
worth of sourcecode he purchased, hoping to find his application 
there. Then he told me I was a wannabe and not a pro because I had 
unrealistic salary demands. Man, did that hurt my feelings!!

3) The third is the one I always forget and which comes to bite me.

Kent



--- In msp430@msp4..., onestone <onestone@b...> wrote:
> Hi Kent, interesting! Very jaded outlook for one
so young ;@}, and 
you 
> missed what, to me anyway, has been my greatest
source of income.
> 
> The BUDGETS BLOWN PROJECT. This usually occurs where one of the 
below 
> scenarios has unfolded to its obvious conclusion.
A mess. The 
potential 
> client hired company A because they wanted a
'reputable firm' or 
because 
> so and so who works in the typing pool has a
brother who knows the 
uncle 
> of the company owners wife. Anyway, they've
been charged big 
bucks, the 
> project is way over time, and way over budget. The
original 
contractor 
> has been fired, or has disappeared from view. The
client wants it 
fixed, 
>   it's 'almost working', so
shouldn't take too much. He doesn't 
trust 
> anybody in our crooked industry anymore, and they
have littel or 
no 
> budget available.
> 
> Fortunately I'm cheap. I only have me to employ. I examine the 
job. 90% 
> of the time the hardware is absolute crap, and the
software looks 
like 
> the chimps tea party was given type writers to
play with.However 
they've 
> heard 'it just needs a new PCB design'
too many times, or you're 
the 
> fifth attempt at fixing it, and "everybody
else claimed the 
software 
> needed re-writing, and they stuffed it too'.
> 
> I make them one offer only, take it or leave it. I will patch the 
> existing system for $n. It will have absolutely the least level of 
> functionality that makes it useful. Here is the list of tests it 
will 
> pass. If it passes these tests for a lump sum of
$m payable 25% 
with 
> order, 25% on PCB delivery, 25% on completion of
programming and 
25% on 
> passing final tsting, or for $p each week, for a
maximum number of 
x 
> weeks I will deliver the product they oredered
plus a list of 
> improvements, and here is the testign schedule it will pass.
> 
> Normally these situations arise because the client has no idea 
what is 
> possible, and the 'designer' has not
taken the time to adequately 
study 
> the target industry, filter out what is desirable,
and what isn't, 
then 
> educate the client on what they really want.
> 
> Kent Johansen wrote:
> 
> > This is wisdom, Matt !!
> > You basicly have all the traps identified. 
> > There are in any kind of projects 4 serious threats, that you 
learn to circumvent as 
> > you become old in the business. If ever. 
> > 
> > BUFFET PROJECTS
> > The goal is well defined in the clients mind. "We want something 
that works".
> > The consultant thinks "This will
work" and estimates the hours. 
> > Unfortunately there is no cork in the hole. "Natural
additions" 
come in for free. Clearly 
> > we can't use it if it does not have this
and that. And oops do 
you need more than 
> > 300mAH battery ? We clearly don't have
that. And "You should 
know the industry 
> > standard is this and that. All our
competition has this and 
that." 
> > And the budget cap prevails. After all, when
are you really 
going outside the box?
> > 
> > RESPONSIBILITY DEFERRAL
> > Now, you are making A and OtherCompany Inc. is making B. A and B 
has to work 
> > together. OtherCompany makes a quick B, 
delivers and signs out. 
Unfortunately A 
> > and B do not want to work together because of
something 
OtherCompany did not 
> > anticipate. They feel they stuck to the
specs, and they can 
verify the functionality with 
> > a scope or whatever. (Maybe because the scope
ground is 
optically isolated or 
> > something.) Othercompany is furthermore
rather incompetent or 
chooses to be so. 
> > Since YOU are goal oriented, competent and
more readily 
available - you adjust A to 
> > compensate for the shortcomings of B. 
> > The technical details are of course beyond the client and all he 
sees is the broken 
> > Gantt card. This annoys him, but luckily
everybody were working 
for a fixed price.
> > 
> > COMMUNICATION STALL
> > Basicly you have to pound all feedback out of the client. Three 
days before chaos 
> > they will tell you about what does not work.
Or not at all. They 
will try to plug it in and 
> > basicly decide it does not work. Fortunately
for the client, 
there are no time limits for 
> > his testing of the system, so he stalls
payment until he sees 
fit to test the deliverable.
> > 
> > DO-IT-YOURSELF
> > Scraped budget. We have people IN-house who can take certain 
parts of the project. 
> > We don't want to pay consultant fees. 
> > Net result: In-house speed, in-house quality and consultant 
frustration.
> > You make nice hardware and drivers for a
board. The 
local "expert" programs 40 
> > kByte source code with hard left adjusted
margin and no 
comments. 
> > And now your crappy board is unreliable and
has blown an xray 
tube. Fix it !
> > Now try proving it was their fault WITHOUT
fixing it first. 
> > 
> > 
> > My best advice after having spent upwards of 20 years doing it 
wrong again and 
> > again. SELECT your clients. It's scary
as hell, and every time 
one walks away from 
> > the table and says no thanks, you will think
YOU were being 
weighed and found too 
> > light. If you are in doubt of them, scare
them. Let them show 
you the money.
> > If they don't want to pay for doing it
right, YOU will end up 
doing it. After all, they 
> > purchased a solution, did they not ?? How
many here has worked 
for free for 4 
> > months in a row and seen the bank account go
to -50 grand ? 
> > 
> > Another good scare if you suspect disorganizedness: Ask them to 
compile a Final 
> > Assembly Test (FAT) which goes like 
> > ...
> > 14) Press the green button. Assert the system shows the go menu. 
> > 15) Press go. Assert the system starts up. 
> > ...
> > Let them have time to do it. If they are too disorganized for 
that, they go hire 
> > somebody who is still learning and who still
uses their own 
credit rating to finish 
> > projects..  IF your system can do all the
steps in the FAT, it 
works and you get paid. If 
> > the FAT has to be changed, the budget changes
too.
> > Meanwhile you sit down and make a list of ASSUMPTIONS - what 
information, 
> > ressources and tools that have to be present
and how fast. Now 
you can talk price. 
> > And you can go higher than you think. Because
now you are a pro. 
And that costs.
> > 
> > If the project is "real research" there is always a
possibility 
of breaking the budget in 
> > a bad way for both parties. In this case,
build in "Go Options" 
along the way. At 
> > certain milestones, best at completion of
Work Packages (defined 
by FATs) both 
> > parties have a Go-Option. To continue or
document and leave it 
where it is. 
> > This prevents real back-breakers where one of
the parties are 
forced to fulfill a 
> > contract that is really not worth it. 
> > 
> > Finally: A great team takes a lot of luck to find. You have to 
kiss lots of frogs first.
> > If you make a team with inhouse people, make
sure they ARE a 
team at all. 
> > The client is most likely interested in
getting the IP purchased 
secured in the 
> > company, so they are not held hostage later
by the consultant. 
> > So build in teaching of the inhouse people. Sometimes you will 
find marvellous 
> > friends and learn yourself. If it does not
work, speak up to the 
teamleader. If it does 
> > work, praise. Select your tools, processors,
platforms etc. WITH 
the company to suit 
> > their needs. Teach while learning. Spend time
with them. 
> > That's also what gets you your next project. 
> > Open Source Consultancy is very rewarding for all involved 
parties, when done right.
> > 
> > And bordered by the two lines of the FAT and the ASSUMPTIONS 
everybody knows 
> > what the goal is. 
> > 
> > Kent
> > who dunnit wrong lots
> > 
> > 
> >>On Wed, 24 Nov 2004 15:52:01 -0800, Jonathan Kirwan wrote:
> >>
> >>> 
> >>> On Wed, 24 Nov 2004 16:41:42 -0600, Matt wrote:
> >>> 
> >>> >Instead, I would design a system that has user
downloadable 
message
> >>> >tables as part of the
application. That way the end 
user/client can
> >>> >change messages to their
heart's content and never mess with 
your
> >>> >compiled application. You could
even write a neat PC front-
end that
> >>> >makes their job easy and stores
different sets of messages on 
the PC.
> >>> >Much safer and a whole lot easier
to support.
> >>> 
> >>> Will they pay for the effort for all these extras?
> >>
> >>Will they pay you when they screw up the process and ask you to 
fix it? 
> >>Will you have time to drop whatever
you're doing in the future 
to fix 
> >>their screwup (even if they DO pay you)?
You know they'll want 
it done
> >>pronto since it most certainly "will
be holding us up from 
shipping
> >>units!" I wonder how many consultants
have heard this one 
before? :-)
> >>
> >>I guess this goes to what your business philosophy is and how 
you look
> >>at solving potential future problems
before they happen. Cutting 
loose
> >>a client with an IDE/Compiler and
expecting them to be able to
> >>successfully recompile with new messages is doomed to failure, 
in my
> >>experience. If they can handle that task
successfully, then they 
most
> >>likely can handle writing the code
themselves in the first 
place. I'd
> >>prefer to make sure there's not much
chance of them screwing up 
by
> >>design. To me that's just good
engineering and part of solving 
the
> >>problem.
> >>
> >>
> >>> Remember, the point was about a "small firm needed only
for one
> >>> product line some programming control with a small
alphanumeric
> >>> display..."  To get a simple display project, are they
going 
to want
> >>> all the extra software, serial port
interface, command 
protocols, and
> >>> all the extra testing to verify it,
and the cost along many
> >>> dimensions, just to get a display up and running?
> >>
> >>Frankly, I don't see it as that huge an addition to the
project 
as long
> >>as it's planned for up-front.
I'd actually rather spend the time 
up-
> >>front engineering an elegant solution --
even if I have to 
contribute
> >>some of the cost -- than fixing a problem
that's almost sure to 
come up
> >>later at a most inconvenient (for me)
time. That's just been my
> >>experience over the years. 
> >>
> >>I also don't see it having to be all that complicated an 
addition to
> >>the basic project. I have at least half
the software in 
my "toolkit" to
> >>add these capabilities to the project
already. It certainly 
wouldn't be
> >>any harder or more time consuming than
having to provide the 
client
> >>with a complete FET/IDE setup, installing
and testing it for 
them,
> >>documenting the process and teaching them
how to do it. And in 
the long
> >>term it will still be riskier than having
a dedicated method 
that was
> >>designed to store custom messages. Maybe
this is one of those 
things
> >>you and I would disagree philosophically
on, but I see something 
like
> >>this as an essential part of the project
that probably wasn't
> >>considered up-front rather than an "add-on" frill. 
> >>
> >>I believe most clients (especially non-technical ones) tend to 
> >>underestimate project complexity. Show a salesman or manager the 
tiny 
> >>little battery powered widget you spent
the last several hundred 
hours 
> >>designing and he'll yawn... "Is
THAT all there is to it? What 
took you 
> >>so long!?" To quote a friend of
mine... "The roadside is 
littered with 
> >>the bones of consultants who took on
projects that 
were 'simple'". 
> >>
> >>Another aspect of this situation is that if they really are a 
small 
> >>firm and "can't afford to do the
job right the first time" then 
they 
> >>are the kind of client that throws up a
huge red flag for me. 
They're 
> >>likely to be slow payers, question every
part of every charge 
you bill 
> >>them for, make several major changes to
the project after it is 
well 
> >>under way and expect you to accommodate
them at no charge and in 
> >>general try to get everything for free they can. At that point I
> >>question whether I really want them as clients or not. Again, 
that's
> >>been my experience over the years.
> >>
> >>
> >>> I can tell you what would happen in a meeting in my small 
business place if I
> >>> took a "display project"
and started suggesting these kinds of 
additions to it,
> >>> without a clearly demonstrable value
to the immediate purpose 
at hand.
> >>
> >>But you see -- it's MORE than a simple display project!
It's 
really a 
> >>simple display with a user
programmable/customizable message 
base. The 
> >>client defined it as a "simple"
project, but it's really not as 
simple
> >>as they think or present it to be.
> >>
> >>I dunno, maybe I'm just more of a salesman than you are but
I'd
> >>certainly try to sell them on the positive aspects of going this 
route.
> >>In fact, I wouldn't even bring up the
option of them diddling 
with the
> >>compiler themselves mostly because I think
it's a bad idea. I 
think
> >>there's a largely demonstrable
benefit to the client and that's 
self
> >>reliance and reliability of the process.
They don't want to have 
to
> >>come back to me later and pay me more
money because the process 
just
> >>works.
> >>
> >>If it came down to it and I really wanted their business, I'd 
recommend
> >>the route I suggested earlier. If they
refused, then I'd make 
perfectly
> >>clear that if things got screwed up
I'd have to charge them my 
normal 
> >>rate for any additional work I'd do
and that I might not be 
available 
> >>right when they needed me. I wouldn't
feel comfortable giving a 
> >>warranty or supporting software I'm not in control of.
> >>
> >>It's interesting that most of my clients in the past that went

the 
> >>"cheap and dirty" route have
almost always have come back and 
asked me 
> >>to do it right after the fact. From that
point on they usually 
trust me 
> >>and don't question my motives on new
projects. Most of my 
clients bring
> >>repeat business to me and I get very good
word-of-mouth 
> >>recommendations, I think in part because I'm a straight
shooter 
and
> >>tell it like I see it. At least
that's what many of them have 
told me.
> >>I'd like to think I give them the
best value for their money I 
can and 
> >>that's my goal. Sometimes spending
more up-front is a much 
better 
> >>investment. Sometimes the clients
don't like what I have to say 
but 
> >>they generally trust me because I'm
usually right. Hmmm... I 
didn't 
> >>mean for that to sound arrogant, I meant I
normally won't stake 
out a 
> >>position unless I have a high confidence
level in it. ;-)
> >>
> >>OK then, enough from me. I do find this area of the consulting 
business
> >>very interesting. Dealing with clients is
kind of a mixture of 
art and
> >>science. I'm always interested in how
others see things and how 
they
> >>handle all the little challenges that
inevitably come up.
> >>
> >>Matt Pobursky
> >>Maximum Performance Systems
> >>
> >>
> >>
> >>
> >>.
> >>
> >> 
> >>Yahoo! Groups Links
> >>
> >>
> >>
> >> 
> >>
> >>
> >>
> > 
> > 
> > 
> > 
> > 
> > 
> > .
> > 
> >  
> > Yahoo! Groups Links
> > 
> > 
> > 
> >  
> > 
> > 
> > 
> >