some classic red flags to be aware upfront

Dealing with Difficult Clients
There is an ancient Chinese proverb:
"If you pay me as much as I ask, I will work like you want; on the other hand if you pay me like you want, I work as I will."
And I will add, this ancient Chinese proverb is the main principle which should be guiding line when you negotiate the contract.

Remember -- You are a "hired gun" not a gun which they own. You are hired and not employed, as one with special knowledge or expertise, as in business, with some particular skills, who is hired to resolve particularly difficult or complex problems, often under your terms.

If you run into difficult situations with your clients, learn how to properly respond to help get the project back on track.

It is often the case that developers are looking for projects, and the potential client is selecting who to work with. On the other hand, at the same time, developers should be deciding if the potential client is a good fit for them, too.
Have you ever recognized when it was too late that this new client is a disaster to work with, and then regret for not listening to your intuition?
I’ve been there plenty of times. So much so that I finally made myself a ‘RED FLAG LIST’ of how to sort out those potentially frustrating projects before signing a contract.
A Few Easy-to-Spot Red Flags for new clients
Here are enlisted some red flags to pay attention during initial discussions with a client that can help you recognize their potential contractual risk:
- Your potential client claims, they don’t have much money now, but the potential for BIG profit will come down the road and they promise revenue share, but not in writing and not in the contract
- They don’t want to negotiate mutually acceptable a contract or pay your required up-front fee
- The client questions or try to rewrite terms in his favour of your contract.
- They want to reach you on weekends or in case of an emergency, with no additional emergency-fee
- They talk about how their last developer just didn’t seem to be able to meet their standards
- The client wants you to start the project and need it completed "tomorrow", but they do not have precise requirements.
- They take days to reply to an email, and never answer the phone

Now that we’ve enlisted some red flags that you should pay attention to evaluate new clients, let’s look at your current clients.
Here are some classic red flags to pay attention, if/when they occur in negotiation process.
Here are enlisted things a client might say that are a sign of difficult client. If you hear any of these red flags, it certainly doesn't mean you should automatically end the relationship. Use your judgement and before making final decision, give clear working conditions in writing. Make upfront clear what activities are not part of your job.

-----------------------------------
1. Promise of Future Work
-----------------------------------
Potential clients will often try to obtain your work at a lower rate by promising to hire you for projects in the future. While it is up to your judgement to determine whether it is just a bluff, remember the only guarantee (sort of) is the initial assignment.
Even if a client is sincere about his intentions of working with you on an ongoing basis, it will ultimately be the work you do for them and how your relationship progresses that decides if you will continue to work together. If you feel the client has good entrepreneurial sense and that there really is potential in his business venture, you could gain a long-term client, giving them a discount on the first assignment may be worth the risk.
Just remember there is always a good chance you never hear from them once your code is up and running in production. C'est la vie..

-----------------------------------
2. Everything is "Easy" or "Quick"
-----------------------------------
Have you ever heard before.. "We just need a simple feature to add in this software" or "Can you make a quick port of existing software to new architecture?" In some cases, the client actually thinks something is easy because they don't have experience with development, coding, software maintenance, etc.

On the other hand, the client may be trying to downplay what they need in order to keep your costs low. Either way, it is a red flag that can first be handled with an explanation of why the project or task is time consuming.

The client does not need to completely understand every technical aspect of the software development process, or that we may work on the solution until 5 AM, obsessed with the solution for their problem. Explain your view and see how the client reacts to your explanation to determine how to proceed.


-----------------------------------
3. Vague requirements
-----------------------------------
Do you need pliers to pull information from your client during the discovery stage of the project. You've successfully delivered many projects in the past. You're great at listening to your client's requests, proposing solutions and coming up with a plan.
Then how come you have no idea what this new client wants after several hours of discussions? A client who can't clearly convey the goals and wishes, or even feature list of the project, will probably be difficult to communicate with throughout the project.
Is this client at least paying your requirements discovery services, or there are some other formal arrangements?



-----------------------------------
4. Questioning Your Rates
-----------------------------------
Look out for clients who question your rates, as that is an early sign of distrust. There is a nothing wrong with a client telling you they can't afford your professional service, but that is different from them telling you it shouldn't cost so much. Clients should understand you are quoting your contractual rates fairly. Do not accept to sign the contract, where the client wants to transfer his operational risk on you.
While they will most likely get a wide variety of quotes from other developers, your costs coming at your rates and conditions, doesn't mean you are cheating them.
Finalizing a rate for a project is one of the trickiest aspects of accomplishing a deal, but it is also a good test of how effectively you and your client can communicate. Often fix weekly or monthly rate is reasonable approach, where you deliver your work and services on weekly or on current demand basis, with your usual pace. Within several weeks your client get the feeling of your working pace and efforts. If he likes it, he may continue the contract. So make clear to your client that he has very limited or no risk, since he can always interrupt the contract, with no explanation.


-----------------------------------------------------------------
5. their last developer left them, but they claim they Fired him
-----------------------------------------------------------------
This is a tricky one, because you will probably only hear one side of the story, and it will be about how bad their last developer was. This may be 100% true and you might be just the developer to step in and save the day.
Remember to also question what happened with the last developer... was the client too difficult to satisfy? Working conditions were not acceptable? For every bug perhaps he was sent to gulag, or Alcatraz, perhaps?
You probably shouldn't just walk away from a job opportunity if you hear this, but take a look at the full story. Does the client also have unrealistic expectations or confusing requests and incompetent project manager?
Is it difficult to agree on the terms of the contract?
Find out what went wrong so you're not next to be liquidated on similar terms.

-----------------------------------
6. Unrealistic Deadlines
-----------------------------------
Be wary of clients that want everything yesterday in production, but because they want to sound reasonable they say just "AsSoonAsPossible". Sometimes turning down such assignment is easy, because what they want, simply can't be done.
Other times, it is possible to do the MIRACLE, but only if you sacrifice your private life, current work (and existing clients) to get it accomplished.
Keep in mind that a client that wants their first project done right, with NO bugs and glitches. If in the future bugs or some other unrelated glitches do appear in production - most probably he will put the BLAME on you. If you really want or need such a project, consider CHARGING rush fees and explain that you have to put other work at risk. You may also want to find out why the work needs to be completed so quickly to determine if this is a trend and bad habit, or a just one-time rush job.
Often when your production code is making handsome profit for your client, he will try to minimize it and forget your merits and maximize your eventual failures and dramatize the impact of bugs.

------------------------------------
7. Shopping for the best price, or..?
------------------------------------
Many developers have experienced projects that drag on and on, with little or no communication for weeks or even months at a time. Often, an early warning sign of this is the same behavior during the early stages. Does the client respond promptly when you call or email with questions and remarks, or do you wait too long and have to follow up before getting answers? Sometimes this is a sign that they are speaking with several other developers and shopping for the best price, or perhaps they are too busy to be committed to the job at this time. If you see this problem developing but want the work, consider putting a project schedule in your contract that includes deadlines for the client, with cancellation clauses.


----------------------------------------
8. Specification and Requirements Work
----------------------------------------
One of the easiest red flags to spot is the request for "specification" This means a client asks to see designs and proposals for their project before having to make the decision to hire you. Since they don't intend to pay a fee for such work, you may invest time and resources without getting anything in return. You should be selected based on your portfolio and experience, and come to an agreement regarding payment before starting on design. It is also likely that a client has asked several other developers around to come up with concepts, while spending little time with each of them to explain what they are looking for. In the end, both parties benefit by choosing to work together from the start, instead of jumping form one developer to another.


-----------------------------------
9. Disorganized from the Start
-----------------------------------
Watch out for clients who appear disorganized from day one. In order to finish a project on time and on budget, both developer and client need to be organized and able to communicate. If a project outline from a client is unclear, or if they cannot provide all requirements and specification on time, it may be a sign that the entire project will be extremely frustrating.


--------------------------------------
10. Gross and net price ambiguity
--------------------------------------
Watch out for clients who offer gross amount and pay substantially less net amount, which does not sound as persuasive during the negotiation process. Be aware on the all ambiguity issues.

-----------------------------------
11. Trust Your Intuition
-----------------------------------
One other important red flag is your "impression" that a client is trouble. Or perhaps he is a fine gentleman, but the problem is his incompetent project manager, or his arrogant marketing & sales personnel? Trust your instinct, especially if you have already worked with a variety of clients. This may be more difficult when starting out, but as you take on more projects, especially those you wish you had walked away from, you will learn when to turn down a job based on any of the factors above and your own experience. Look at this not as missing business opportunity, but as gained health and opened new even better one. Turn the page, and move on.

----------------------------------------------
12. Contracts and positive attitude
----------------------------------------------
Contracts serve to attribute blame when something goes wrong.
Do not accept to sign the contract, where the client wants to transfer his operational risk on you.
Customers put the blame on project mangers. While project managers are identifying testers or authors as an appropriate target for finger-pointing when some bugs are identified.
Authors should protect them selves with precisely written contracts indemnifying them from the bugs found in the software written by them. On the other hand they should assure their customers that each reported defect should be corrected with no compensation whatsoever.
An indemnity clause is a contractual transfer of risk between two contractual parties generally to prevent loss or compensate for a loss which may occur as a result of a specified event or bug.
Customers may be obligated to indemnify their programmers and authors for liabilities incurred while carrying out responsibilities under the relationship.
Contractor will indemnify and hold harmless the Indemnitees from any costs, damages, and fees reasonably incurred by any of them that are attributable to any such claim.

----------------------------------------------------------
Checklist to See Whether You Should Keep a Client
---------------------------------------------------------

Sometimes even a difficult client has some benefits for you. Before rejecting completely the client solely based on a not-so-great relationship, be sure to consider the other aspects of the business relationship:
✤ Are they paying your full rate and in your terms?
✤ Will this project add value to your portfolio either thru a new technology or big client name?
✤ Is the project interesting, creative or has something you have wanted to learn?

-----------------------------------------------------
How to Keep a Difficult Client Under Control
-----------------------------------------------------
If you’ve gone through the checklists of red-flags and decide to keep the relationship with a difficult client anyway, there are a few simple things you can do to minimize potential risk and problems during the project:
★ Get a signed contract that spells out exactly what you are going to provide and what you require of the client
★ Let the client know how you handle new items they want to add to the project that weren’t included in the initial scope
★ negotiate upfront all IP rights, copyright and co-copyright, licences, GPL
★ Spell out your payment terms clearly. Include up front all periodical payment, and how you accept payment.
★ Create a road-map with time-line outlining deliverables and payment dates to keep the project on track.
★ Agree up front that you are available only by previously agreed and scheduled appointment, or define your business hours precisely
★ If you only take work requests in writing or via email or ticketing system, denote that precisely in the contract.
★ Get a partial payment before beginning work so the client has some small risk in the game.

Taking a little time up front to evaluate the client and make a list of contractual pros and cons can save you hours of work and headaches down the road.
Your time can be used to find better clients that enhance rather than hinder your business potential.

------------------------------------
Preventing contractual dispute
------------------------------------
In order not to arrive to the situation where the client can claim that we did not deliver what he has asked, the deliverables after each milestone should be re-controlled and inspected by the client or his representative and consequently payed. Do not make grand-finale payment contracts, it is too risky. Revolving contracts are most reasonable approach.

The client after each milestone should review the functionalities promised in the contract and cross-examine it against and sign a formal approval and provide a list of remarks or reclamations, which should be addressed in the next development cycle.

Failure reduction is an essential step towards excellence. And each defect, glitch or bug will be addressed in Test driven development.

This first, discovery & inception iteration, some developers often do not charge, but never deliver it into hands of the prospect before they sign the contract and agrees to the terms.

Features, road-map schedule, even costs can come later.

The project velocity, the acceptable rate of change is the key issue. How much change the client and its team can absorb in a unit of time, assuming that the developer can follow, or even better lead his customer. This delicate balance depends on corporate culture, organisation complexity, project manager on client's side, etc.

..................................................
There is an ancient Chinese proverb:
..................................................
"If you pay me as much as I ask, I will work like you want; on the other hand if you pay me like you want, I work as I will."
And I will add, this ancient Chinese proverb is the main principle which should be guiding line when you negotiate the contract.
Remember -- You are a "hired gun" not a gun which they own. You are hired and not employed, as one with special knowledge or expertise, as in business, with some particular skills, who is hired to resolve particularly difficult or complex problems, often under your terms.
http://1stmuse.com/sw/autorski_honorar/
http://1stmuse.com/sw/dealing_with_difficult_clients/

http://1stmuse.com/1stmuse/copyright_practice_under_the_berne_convention/
http://1stmuse.com/sw/software_development_is_a_service/