<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Michael Giagnocavo wrote:
<blockquote
cite="midE9708CBFCDD44A9FBD86BEBDAE53F6A8.MAI@mail.atrevido.net"
type="cite">
<blockquote type="cite">
<pre wrap="">I ask for 50% of labor and 100% of
hardware costs and with a few bad jobs think that this is a safe way
of weeding them out.
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
That is a very good idea. <br>
<blockquote
cite="midE9708CBFCDD44A9FBD86BEBDAE53F6A8.MAI@mail.atrevido.net"
type="cite">
<pre wrap="">Even better is leaving a "secret" backdoor, that they AGREE to. Sure, if
they hire good enough people they can disable it. But at least it gives you
some level of security.
</pre>
</blockquote>
I'd never thought of doing something like that (grin) I've always
thought of backdoors/etc as unethical, but I suppose if the client
agrees to the back door it's ok.<br>
I recently had to take a client for a programming project to court for
non payment. Time will tell how it turns out, but I do know that I'll
never work on a project again without a firm specification and firm
understanding with the client about how payment will work. <br>
<blockquote
cite="midE9708CBFCDD44A9FBD86BEBDAE53F6A8.MAI@mail.atrevido.net"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">What could cause stress to the consulting
relationship?
</pre>
</blockquote>
<pre wrap=""><!---->
Clear expectations, project planning, requirements. Not having these things
is a pretty good way to ensure failure. I dealt with a client that had some
great ideas, but no management powers. A really basic "requirements" doc was
passed off as a technical specification. I think that even a year after I
left the project, they are almost in the same spot, since there's no clear
expectations of what exactly has to be done.
</pre>
</blockquote>
I totally agree. The problem is getting the client/boss/whatever to
put enough time into their own project to figure out what they want.
Most of the time they want you to figure out what they want and write
the specification too, of course they don't want to PAY for the
specification (grin) <br>
<br>
<blockquote
cite="midE9708CBFCDD44A9FBD86BEBDAE53F6A8.MAI@mail.atrevido.net"
type="cite">
<pre wrap="">I know a lot of people have bashed requirements and specifications
documents, seeing them as just junk that slows you down. Yes, it takes time.
But without it, no one is quite sure what they're building. If you're
writing a 3 hour hack job, that's one thing. But anything more involved than
a day, and there has just GOT to be a clearcut expectation. Sometimes
clients don't want to pay for intangibles like a project manager.
</pre>
</blockquote>
I think documentation is essential for even a three hour hack. Later
if you're called to modify your code lack of documentation can make it
difficult to figure out exactly what you were doing and how.<br>
<blockquote
cite="midE9708CBFCDD44A9FBD86BEBDAE53F6A8.MAI@mail.atrevido.net"
type="cite">
<pre wrap="">Specifications will change, grow, evolve. Both the client and the consultant
have to have agreed on how this will happen. The client obviously won't pay
for something that doesn't fit their needs, and the consultant obviously
isn't going to program a whole new system because the client decided that a
GTK+ interface is better than a PHP-based one.
</pre>
</blockquote>
My biggest annoyance is that clients seem to think it's ok to expand
the specifications without paying for those changes. All of those
little changes they make can add up to a ton of time! <br>
<blockquote
cite="midE9708CBFCDD44A9FBD86BEBDAE53F6A8.MAI@mail.atrevido.net"
type="cite">
<pre wrap="">Through experience, I've learned to be highly cautious to take on any
project not well defined, or where the client isn't willing to get into
specs and design.
</pre>
</blockquote>
Wise move.<br>
<blockquote
cite="midE9708CBFCDD44A9FBD86BEBDAE53F6A8.MAI@mail.atrevido.net"
type="cite">
<pre wrap="">Yea, people will try to screw you out of money, and you gotta watch out for
that. </pre>
</blockquote>
Yep.. just happened (grin)<br>
Im hoping the court system will convince this guy to pay for the time
spent on his project.<br>
<br>
<blockquote
cite="midE9708CBFCDD44A9FBD86BEBDAE53F6A8.MAI@mail.atrevido.net"
type="cite">
<pre wrap="">But derailed nightmare projects can be much worse.
</pre>
</blockquote>
Been on those.. feature creep from hell! You end up throwing away
version1.0 and writing v2.0 from scratch.<br>
I've yet to get a client that had a real specification or more than 3/4
of an idea of what they wanted; makes it difficult to estimate.<br>
<br>
JD<br>
<br>
<pre class="moz-signature" cols="72">--
JD Austin
Twin Geckos Technology Services LLC
email: <a class="moz-txt-link-abbreviated" href="mailto:jd@twingeckos.com">jd@twingeckos.com</a>
<a class="moz-txt-link-freetext" href="http://www.twingeckos.com">http://www.twingeckos.com</a>
phone/fax: 480.288.8195 </pre>
</body>
</html>