By Peter Bell

Managing Risk in Website Development

I've found it very interesting that on an XP list recently there's been quite a lot of talk about fixed price for features which at first seemed to me the antithesis of the Agile approach. At the same time, we've been developing fixed price software for years, but I'm wondering if a blended model might be the ideal solution . . .

Clients want to pay for features not results. Providing the user stories are simple enough to spec and quote for free or the client is prepared to pay for a discovery phase to identify and spec the user stories, I don't think it is an unreasonable request. Why should they pay a programmer for their time and take all the risk rather than paying an agreed price for each feature? Of course you need to make sure the feature is fairly small, the spec is detailed, the client understands that dark matter isn't included, and there are no rocket science or lab experiments involved.

The problem we run into is that while we have pretty good control over the risks in initial development, we have no control over the amount of time taken to demo, explain, tweak and revise the software until the client is happy with it. Because we can develop software so quickly, client contact is a big part of our costs, and to fixed bid a feature, what we really need to know is how many questions the client will ask and how many changes (and of what type) they're going to need to be satisfied.

I'm considering starting to offer a blended approach. After specifying the user stories we provide a fixed price per feature (except for some more nebulous features that may have a discovery cost associated instead). We guarantee to provide software that meets all of the requirements explicitly documented in the story for the price provided. Then of course, the client will want changes. They may want to discuss the software, suggest revisions, see some graphical tweaks and perhaps add some business rules they forgot. Well, because we have no idea how many questions they have or how many changes they want, we'd do that work on an hourly basis.

In this way we can guarantee they'll get what they asked for at a fixed bid within a fixed timeframe with no risk. They in return guarantee that we'll be compensated for however much time they require to get the story to the point that they're happy to launch. We're incented to be efficient in developing the software, and they're incented to value and respect our time (or at least pay for it) in terms of discussions, revisions, training and support.

[UPDATE] related article on InfoQ

Thoughts?

Comments
I think the blended approach devolves into a non-fixed bid for projects.

By sticking precisely to the written-down version of the specs, in effect you are building what they were able to communicate they wanted, not what they really wanted or needed.

I have no problems with either way (in fact, I prefer the non-fixed), but I don't see how to get around it should you be enforcing that rule.

It wouldn't be bad if they can spec it out in sufficient detail to begin with, but of course that's the problem we have in the first place that led to the non-fixed idea.

What say you?
# Posted By Sammy Larbi | 12/14/07 1:27 PM
A blended approach IS a non-fixed bid, but there is a difference. In a typical time and materials scenario, the client pays for x hours. Even if they give you a detailed user story spec, you don't provide them with a fixed bid for developing that, so they are at risk of you taking much longer to build an agreed story which seems a little unfair. On the other hand, true fixed bid is unreasonable, because you have no idea how many iterations will be required before the client decided that your implementation is the implementation that they want. The nominal solution is just to say that anything you code that meets the documented elements of the user story is acceptable. The problem with that is the client is almost guaranteed not to like what you build which doesn't work.

To me the solution is to say that if the client and I can come up with a detailed user story, I'll fixed bid building someting that meets that story, but from my experience even when I do that they are going to want to make tweaks. I explain that I don't know if they will want a few tweaks or lots of tweaks, so I ca't provide a fixed bid for that and to recommend that they budget 20-40% of the original cost for such changes (but to be aware that if they want lots of changes, that cost will go up).

In that way I take the risk for what I know most about - what it takes to build a given feature to an agreed spec, and the client takes the risk for what they control - which is how picky they are, how much hand holding they need, etc.

It still isn't perfect as the client might say "but I don't know how well you will build the app within the fixed bid", but the answer is "what do you mean by how well?" If it isn't in the spec it won't be in the code, so let's go over the story one more time and make sure that any implementation of this would be acceptable. If not, let's get more detailed in terms of the button positioning or validation or whatever else you care about so we can reduce all of our risk.

It just seems to me the least bad solution as it apportions the risks - not perfectly, but at least in general they are directed at those most likely to be able to manage the risks.

Thoughts?
# Posted By Peter Bell | 12/16/07 6:27 PM
That's a better explanation and I certainly understand better where you're coming from. My misgiving is that I think the kind of client who this is designed to mitigate risk for (and against) is the type of client who will still remain unhappy at the end.

If it's a small tweak client, they are generally covered fine under the fixed bid scenario, and probably would do equally well under a non-fixed bid scenario.

On the other hand, if it's a large tweak client, they will likely still end up feeling cheated because "you didn't get anywhere near my expectations under the fixed bid part." If they knew from the beginning they were paying per hour, they wouldn't have those expectation.

Of course, this is just conjecture on my part. I've never had a non-fixed-bid big-change-request client that didn't mind paying for the changes. That may be because they realize it from the beginning or it might not mean that - there is no way to tell really. I have had plenty of the blended approach - some of which were successful, and some of which just kept (basically) saying it wasn't ever to spec.

You can take them to court or arbitration with the specs and win, but with such small projects, is it ever going to be worth it? You might think of it as a way to divert deadbeats (like big software companies always taking patent issues to court, just to get the reputation and ward off others), but of course you don't really want to sell the reputation of taking clients to court. =)

I can certainly see where it helps to sell yourself to reasonable clients - I'm just wondering if you're asking for the unreasonable ones, who are going to be unhappy with the blended approach if it works to protect you as well (which it should!)
# Posted By Sammy Larbi | 12/16/07 7:53 PM
Hi Sam,

I agree the problem is always the unreasonable clients. I also agree there is no magic structure that'll make unreasonable clients more reasonable. However, I think the blended approach is a step forward for the following reason. I'll tell the client that they need to understand that ANYTHING that meets the user story is acceptable, so if they care about it then need to include it in the spec. Because of that I recommend an hourly discovery phase upfront, but if they don't want to "waste" the money on discovery, I'll take their written spec and will build something that meets that. If they want any changes, the simple response is "exactly which sentence in the spec does this not meet". Obviously all specs would be pre-vetted for generalized language and subjective requirements (easy to use, quick response, small number of clicks, intuitive interface, professional looking) so they just contained a simple factual description of screens and actions required.

The problem I face is that many of the clients I deal with are completely uncomfortable with anything other than a fixed bid. I don't want to stop working with them, but I'm not willing to take on any more true fixed bid projects because if the client is unreasonable I lose money. On the one hand I'm moving towards hourly projects which helps, but then there is no potential upside. With a blended approach, if I can figure out how to build an e-commerce system to spec in 2 hours I'm not limited to charging for two hours, yet I'm not left open to the unlimited liability of the question who is endless picky. This is particularly important because I get many projects through resellers, so I often don't get to pre-qualify clients and it's hard for me to not accept a client from a reseller as it opens the door to them working with other devs for not only that project but also the better ones.

Let me turn this around. On a time and materials basis, how do you profit (if at all) from improved efficiencies? Lets say you could build a software product line in 500 hours that would allow you to generate lots of 200 hour projects in 10 hours. On a fixed bid or blended approach, it'd be a no brainer, allowing you to lower your bids AND make more profits. On a time and materials there is no reason for you to become more efficient as you'd only be working evenings on the SPL to cut down your hourly billables for your clients (plus you'd have to multiple sales to hit the same revenues).

How do you handle that?
# Posted By Peter Bell | 12/16/07 10:31 PM
You make a good point. I forgot the big picture, and was looking at the narrow version of "just a general shop."

My mistake. =)
# Posted By Sammy Larbi | 12/17/07 6:37 AM
> On a time and materials basis, how do you profit (if at all) from improved efficiencies? Lets say you could build a software product line in 500 hours that would allow you to generate lots of 200 hour projects in 10 hours.

I'd offer this as a separate "specialized" service. Perhaps with somewhat different branding, certainly different marketing and such.

Ideally it would be a completely automated service that would allow me just to sit and watch money flowing :)
# Posted By Andriy Khavryuchenko | 12/25/07 2:13 PM
The challenge with completely automating something is that it often devalues it. While yu might pay $3,000 for someone to custom code something, you might only be willng to pay $200 for a piece of software that does the same thing@
# Posted By Peter Bell | 12/25/07 4:24 PM
I'm not familiar with the marketing of completely automated services, so I may be asking something obvious.

Is there a pure psychology issue or this has objective roots? E.g. lack of customization or lack of communication between customer and service provider?
# Posted By Andriy Khavryuchenko | 12/25/07 4:49 PM
I think it is just about positioning and comparable solutions. I can buy a cms or shopping cart for $150. I can get Yahoo! stores for $99 a month. There ARE cms's that sell for $100,000 or for $10,000, but it is a much harder sale to differentiate them.

If I expect a piece of programming from custom programmers to take a while I get that it is going to cost a few thousand dollars, so a price point of say $1000-$5000 doesn't seem at all unreasonable to many more people.

Also, as soon as you mention pre-built software it seems like a big decision where the client has to compare with all possible other pieces of software resulting in a long sales cycle, whereas if someone comes to you and asks you to build smething, as long as they are comfortable with your competence and experience, it's often a quicker and easier sale.

I've just consistently found that selling pre-built software (at least in the early days) is harder and less profitable than just selling custom software and being capable of building it more efficiently via a software product line. Your mileage may vary!
# Posted By Peter Bell | 12/25/07 5:27 PM
BlogCFC was created by Raymond Camden. This blog is running version 5.005.