comment on

If the spec changes, the project time goes UP.
While I think it's important clients realise that changing the specs might not always happen without a price, I think that you as a developer aren't doing it right if they get a fear of changing specs.
Over time, peoples expectations or wishes change, for various reasons. A change of demand from their customers (or users). A merge of companies or divisions. New features in third party software my software is going to interface with. Better understanding of the problem that needs to be solved.
I rather have customers that know their changes can be dealt with in a reasonable way.
If you have a fixed timescale you have a reduced feature list
This I do not understand. First we discuss the feature list, then we discuss the timescale. Then we make a deal. We don't reduce features just because the timescale is fixed.
If I were a customer, and you'd reduce the feature list because the timescale is fixed, I won't pay you.
Cutting documentation to save time means only one person understands the application so pray they don't leave or die
That's not the developers problem, is it?
If you don't say you what you really want then you cannot complain when it doesn't do what you wanted it to
Specs should always be written by both sides. If the spec isn't want the customer really wants, then the blame can't entirely lie at the customers side. He doesn't (fully) understand your language, but you should realize that you don't (fully) understand his.
Try this for an exercise: write a spec what the surgeon should do to remove your gall stones. Are you sure you want the surgeon to perform the operation according to specs?
Looking pretty and actually working are two different things
But not multiple exclusive.
Any time quoted is always wrong - more time is always needed
I rather not have customer say that about me!
Ringing the developer twice a day will not make them work faster. Nor will asking them to report via email, spreadsheet or other communication format.
Why does a customer even have the phone number or email address of a developer? That's why there are (account) managers.
But it is important to keep customers informed about progress. Any large project should have milestones, and customers should be informed when those milestones are reached. Or when they are not reached on their targetted date. You like to hear what's the status of perl6 is as well, don't you?
Never say how something should be implemented. You are not the expert.
Only partially true. They have more knowledge what their in-house expertise is than you. You may decide that Windows is a better platform to run your application on than Unix, but if they are a HP-UX only shop, you have to be very convincing that your application is worth hiring Windows expertise to keep the underlaying platform running.
You are an expert in your chosen field - your service provider (developer or whatever) most likely is not. Always remember this in answering any question or in providing any information of any sort
Now, if only developers would have the same curtesy towards customers...
If there is a business case for the project and the requirements of that are met in full then the project is a complete. It is also a success.
Dream on! Complete projects that meet the specification can be a success. But a lot of times, they aren't. It's only a success if both parties are satisfied. And for parties to be satisfied, one needs more than staying inside the specifications.

In reply to Re: OT: Project clients by Anonymous Monk
in thread OT: Project clients by simon.proctor

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		`&`
	<		`<`
	>		`>`
	[		`[`
	]		`]`

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.