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

From DevSummit
Jump to: navigation, search

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