How Much Do You Want Your Clients to Care?
Clients that don't care at all about their web application are seldom fun to work with. Often they won't develop content, don't think through decisions and we've found that clients without much of a commitment to their web project are those that are least likely to do the work needed to complete the project and get it live.
However, on fixed bid project we're increasingly finding that clients who care TOO much are a huge problem. We had one client recently on a project where we could have charged five times as much and still lost money. Building the application was actually quite profitable, but they kept on changing their mind, obsessing about the smallest details and sending repeated "top priority urgent" emails to follow up. I remember one email that was sent out at 6.30pm and then followed up on at 7.30am the next morning because we hadn't responded yet - it wasn't even something urgent, near to the launch date or relating to a live site. I also remember a series of emails covering all of the details of how notification emails displayed in various email clients which took a great deal of time up for an issue that usually takes very little time to handle.
The best way I've been able to view this is that most small to mid sized businesses follow the Pareto principle and care about maybe 20% of their app. They care about the cross sells but not about authentication or they care about the admin screens but not the checkout form. The 20% that each client cares about is different, but in practice you can only afford to build fixed bid sub $25k web apps if the client doesn't want to discuss every possible detail of every possible element of the project and we bid our projects on that basis.
This completely falls apart when you come across the occasional client who wants to spend all the time in the world to go through every element of the project in excruciating detail. I remember one project a while back (through a reseller so we couldn't just can them) where we had to spend over 80 hours agreeing the contracts for a project we'd estimates at about 80 man hours of effort. Obviously not one of our more profitable projects :-<
So my question to anyone who works on fixed bid projects is have you had this experience and how do you deal with it? Do you have any thoughts on pre-qualifying such clients? What questions could you ask a client to figure out upfront if they might be a pain to work with? Maybe we should add some Myers-Briggs questions to our original client intake questionnaire?
Any thoughts wildly appreciated!
I think this is one spot where agile development really shines (at least the iterative and incremental part of it).
I haven't found a way to pre-qualify clients, but the first time you show them the application will almost certainly reveal the "type" of client you're dealing with. If they can't be bothered to do iterative and incremental development, they are probably the "I care too little" type of client. So you can weed those out fairly quickly.
You want to develop a little bit, then show it to them, and discuss. The client you don't want to work with will be discussing almost entirely irrelevant details ("can we change the color, can this pixel be moved there?" On the other hand, the "good" clients will likely be discussing relevant details (perhaps some irrelevant ones too, but not overwhelmingly so). They see a little of what can be done and some things might change, some requirements might be removed, and some might be added.
Everyone will likely add things, but that's not the problem. Explaining to the client that they paid for 80 hours of work and that you are happy to accommodate changes PRIORITIZED by the client within that time frame will usually work wonders. If they can't be rational enough to see that, you probably don't want to be working with them.
You don't even need to wait a week to show them the first bit. When I was first learning about agile development my teacher told a story of a successful application he built for a client. The first demo was a window that opened up and did nothing but draw a circle. From that, requirements such as "is it measured in metric or English units? We'll need both" popped up, which were never discussed.
Granted, it doesn't help all that much. Sometimes people live to be a pain to others.
RANT
The problem I have with Agile is selling it to small business owners. They don't care whether it takes you 50 or 500 hours - they want to know what it'll cost to build. If you say 80 hours, how do they know how good you are? How fast you are? What if you build a site that doesn't meet their needs - they're going to have to still pay for your time even though they didn't get value out of it?
We all know agile is "right", but if I had the choice between two designers - one of which would give me a fixed price for work and the other that would estimate, unless I had worked with the designers before, I'd be sorely tempted to take the fixed bid. There is a reason that even attorneys are moving towards fixed bids for some services - people want the service provider to take the risk.
Imagine I told you I'd build you a house for $250k. You pay me, then I start building and we'll see how much house you get depending on how many hours it takes us to build it. My best guess is you'll have 1-2 bathrooms. and the kitchen should be in but I'm not sure whether we'll have budget for white goods or not. And we MAY get to the in ground swimming pool, but I won't really know until we see how long it takes to pave the driveway.
All reasonable comments, but would you REALLY buy a house that way from someone you didn't know?!
END RANT
@Joshua, That is a good point. The consistency issue is a big one. We always try to make EVERYTHING appear to be a big thing - sets expectations properly!
The problem with fixed bids is that inevitably you have to plan for the unplanned and increase costs that way (or...) If you don't you are likely to be stuck with operating at a loss. However, I don't see why agile (more specifically iterative development) wouldn't allow that to work. You will complete the requested functionality in 80 hours (to keep our example numbers the same), but you refuse to abide by that obviously if the client wants to spend his 80 hours on something else (change his mind).
Not to mention that if they feel they have a good enough product after 40 hours, they're free to stop.
But even if you don't buy into that and how it might work for small projects (which, since they are small are easier to estimate in greater detail anyway), let me ask you about that house: what if after you agreed to build it I told you I wanted it built on top of a mountain, or in a swamp?
Would the price change, or would you just eat the loss?
I know too well the problems with fixed bid, low amount projects. I'm not saying the iterative nature of agile development is a panacea. But, it certainly helps me tell who the bad clients are going to be, and you can tell them one of three things when you find out:
1) you don't want to work with them because you will likely lose money
2) you'd love to work with them, but given your experience with clients who request similar changes, you are unlikely to complete it in 80 hours so they will have to pay for extra hours or they will have to change their ways
3) you'd love to work with them, even at a loss
I'd try number 2 first, and if they don't agree to be better clients or increase price (or decrease quality or scope), then go to number 1. I've been in situations where I've taken number 3 when times were slow, or for projects I personally cared about or had a stake in. But if I've don't absolutely NEED the work, I'd be loathe to pick up one of those projects again.
I don't know the source, but there's a triangle of quallity-scope-cost. The customer gets to control the two sides that are most important to them. You control the 3rd.
http://www.ambysoft.com/essays/brokenTriangle.html...
I've read Scotts input on this and I don't disagree with either Scott or yourself. My question doesn't relate to the best approach or the best value which I agree 100% is the agile approach. It relates to the sales process. In my experience, if you're dealing with small businesses and websites, I've traditionally had a hard time coming up with a way of communicating agile that would be competitive against a pitch for a fixed bid project. Obviously you can sell the story (which is true) that with fixed price, fixed scope, the only variable left is quality, so you're going to be unhappy with what you get. I'm still not convinced that most clients would buy that - even though it happens to be true.
In your first demo (which should be quite small), if they turn out to be the type of client that looks to be troublesome, then you can bring out the triangle and explain to them how it works. After that discussion you examine your options.
As a side thought, executable specs should would be nice here. =)