[EGF]

My starting conversation for someone looking for outside help on a project is always; Price, Quality, Time - pick two. This helps guide the conversation as there is usually some limiting factor to the "job" whether its budget, when they need it, or how good the quality has to be.

[mkramlich]

Also I've seen a pretty high correlation (not 100%, but high) with clients that push down on pay... but ALSO have very high expectations on quality and time-to-market. It seems paradoxical, but life doesn't prevent paradoxical idiocy from existing.

Speaking in general terms, the clients that offer/agree to higher pay tend to be less demanding, more flexible, more realistic, more appreciative and with more repeating/recurring business (rather than one-off speculative "I have this great idea, just need a duh-veloper!" situations)

I'm getting very close to a point where I might start "shit testing" or filtering potential clients by asking for, say, $1000 upfront, just to have an exploratory talk with me on the phone. Figuring that if they cannot even do that, physically, or are not willing to do that, then they are probably not the kind of client I want to take on anyway, either because they don't have the budget, or, are not sophisticated enough. (They don't understand market conditions, the risks involved to developers, the money cost of time, the time cost of money, the nature of reciprocity, or what their alternative cost would be if they had to hire a software engineer as a FT/direct employee, pay full benefits, paid time off, insurance, etc.)

[rpwilcox]

> Price, Quality, Time

Please don't use those terms. There are better ones: Price, Scope (size) and Time.

The problem with the phrasing "Price, Quality, Time" is that nobody wants to sacrifice on quality. Everyone wants a app that doesn't crash -- the client, the end users, and the developer. Yes, yes, technical debt is a quality concern, but as long as the app runs the client doesn't care in the moment that there's copy/pasted code everywhere and future changes will be "interesting". It's hard to sell "but if I take an extra half day to make this change future improvements will be easier", at least not in tight projects.

But Scope, scope can start negotiation with clients. "Ok, you do know this new control you want will probably take something like 10 hours to write, do you really want it or can you make do with a default one?"

If a client drops a fixed bid project on me with a dictated time deadline, sure as anything I'm going to take control of the scope side of the project triangle.

[ScottWhigham]

Good post. The only quibble I could have is that almost everyone understands what "Quality" is yet it requires education and experience to understand "Scope". Maybe that's a conversation/education you have with prospective clients though.

[rpwilcox]

> The only quibble I could have is that almost everyone understands what "Quality" is yet it requires education and experience to understand "Scope"

I would say that's a feature, not a bug ;)

Everyone "knows" what quality is so nobody wants to cut it. The client expects a deliverable with a (mostly) bug free deliverable, and the developer expects to be able to try to create a codebase with as little technical debt as possible.

There are certainly situations where quality is cut (technical debt that you might avoid if you had more time, the customer deciding to skip beta testing), but as a developer I can't say, "You want this cheap and tomorrow, so we as a team are going to ship a buggy app". Because the first thing the client does when they give the app like that a spin? Come back to the developer with a bug list a mile long and say the current quality is unacceptable.

So then it's not the project management triangle of, "You take two sides, I'll take one". ;)

But if, as a developer, I say, "You want this cheap, and tomorrow, which means this thing needs to have two of these things you want, not all 10. Help me choose the most important things here." Which is a hard conversation (nobody wants to kill their darlings) but you can quantify scope (estimate and prioritize the work).

We certainly know a lot about quality from Deming, Juran, and Pirsig, but the margin is too small, and the night too short, to put this conversation in that scope.

[grobertson]

I've always dumbed this down to "Fast, right, or cheap."

[nsxwolf]

I really don't get this. Can I really pick cheap and right, and just expect it to take longer?