View Single Post
02-15-2008, 12:50 AM
#10
Morgan is offline Morgan
Status: Junior Member
Join date: Jan 2008
Location: Summit, New Jersey.
Expertise:
Software:
 
Posts: 86
iTrader: 0 / 0%
 

Morgan is on a distinguished road

Send a message via AIM to Morgan Send a message via MSN to Morgan Send a message via Yahoo to Morgan

  Old

Village Idiot,

Excellent article in regards to proper communication etiquette when working with clients.

I'd just like to comment on certain points you've brought up, since I go through this daily as a Consultant.

1. Grammar / 5. Large Words and Complicated Sentences:

Grammar, word choice, and overall presentation of information you're trying to convey to your client, is the stepping stone into an established client to programmer relationship. Without taking thought of what you're saying, how the client would view what's been said, or not having the professional sense of grammatically correct structure, any potential clients wouldn't see the value of having you work on their project.

2. Engagement in personal talk:

In reality, there's nothing wrong with engaging in personal talk. Keeping client interest, showing that you actually care to possibly get to know the client for future endeavors, and general personality, helps keep the above stated client to programmer relationship.

3. Payment mentions:

Agreed. The more you talk about "I need my money soon," "Where's my payment," and so on, the more your relationship with the client will spread apart. Knowing that you're only in it for the money, they'll have second thoughts on whether or not you're focused on the actual project requirements. As he stated, other ways to convey that you haven't been paid yet, are much more understanable and professional.

4. Blame game:

The "blame game" is easy to slip into. One mistake, one flaw, or one comment, could cause you a whole works load to fall out of place. If not handled correctly, future contract work will be difficult to recieve, as the client would most likely spread poor reviews, that you don't admit certain problems that were your fault.

6. Speaking in a less technical manner:

Depending on the client, and what you know about the client, you wouldn't have the faintest idea of whether they were technically knowledgeable or not. It's perfectly fine to discuss some key parts of what you've done in a technical manner, but if you do so, indicate to the client that if they have any questions you'd be willing to answer them if you have time, or you would point them in the correct direction for a suitable understanding of the certain term used.

Again, your article was one of a kind, and if all today's programmers would actually tune into what you've discussed, there would be less drama.