Fire Your Clients - How to train clients in to playing nice, or get rid of them

Facilitated by Evan Henshaw-Plath, protest.net

Session Description

Consulting horror story group therapy session. When are you better off without a client? When is it to much? How to tell early on if a client is best left to other consultants? Is it possible to turn a client from bad to good?

Session Notes

• Go around and introduce ourselves
• Clients ranges from nonprofits to corporate clients, to being a tech partner
• Some support clients for a long time and some have more desecrate end points
• Poor communication and disorganization is a red flag
• Changing mind and scope creep is a red flag
• The feeling out period is difficult to assess whether they are a good partner
• Deposits are really good things
• Not moving on to another phase until you got paid for the last one.
• Statement of work and master service agreement
• Some bill every 2 weeks, some bill monthly, some bill at end of project
• Long term clients are clients that trust you
• Retainers are good and promote good behavior
• Getting retainers is a privilege for good clients
• Client selection criteria = how long does their staff last?
• Having the confidence to draw your line in the sand and stick to it
• The higher the rate, the easier the client is
• Setting expectations about budget, cutting scope, timelines slipping, etc. is really important
• Sometimes fire clients over bad politics, and sometimes over PM issues
• The more funding a project has, often the more useless the project is
• One red flag is when you can tell that your client doesn't value your work.
• Nitpicking about the bill is often about not valuing work
• Not valuing time is also bad news
• Switching project managers can be a really good tactic to change the dynamic with a client that has gone sour
• New client document - describes how the shop does work - expectations, procedures, our responsibilities, your responsibilities, etc. It is kind of a contract, but people don't think it is.
• A contract is only as powerful as your enforcement
• Copyright, IP stuff is probably most important
• Write down methods and process if scope isn't fixed.
• Not noticing scope change leads to problems
• First deposit covers last invoice. Bill on two week pay period
• When it is over, it is over
• Don't do any work after you break the news that it isn't going to work.
• Lots of relationship metaphors flying
• 2 week trial period at the beginning to test our process and design is really helpful
• Agile is really good for big projects with a lot of money
• Estimating build when you don't have fully fleshed out design is tough.
• Outside needs analysis is often problematic
• Communication, documentation and setting ground rules with client
• Sadness is a bad sign