开发者

How to do fixed price quote for design sessions? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 3 years ago.

Improve this question

Normally when I do a system for a customer, I do design sessions on an hourly rate and then come out with a fixed price quotation for the full system development.

Now this customer has thrown me a curveball: he doesn't want an hourly rate for design, either - he wants me to quote a fixed price to do all the design, too! Not that he's trying to cheap out, but he doesn't want to be in a situation where the longer design stretches out, the more he 开发者_如何学Gohas to pay - and I can understand that.

For the business layer it was actually not too difficult to work with this, because from his original functional spec I got a good idea of what the core business objects were, and in our design agreement I defined several objects which would be covered by a fixed design price; if any new non-trivial objects were discovered, they would be considered variances, and those would be billed on an hourly rate. So far so good.

But when it comes to the UI, things start getting a lot more woolly. How many screens will there be? Don't know yet. What's going to be on each screen? Don't know yet. All we know is that it's a "dashboard" type of system, and there will be a lot of visual reporting involved e.g. gauges, graphs, etc. So maybe make it fixed price per screen design? Not a great definition; he might say that everything is going to be on one screen. Maybe a price per "visual report" design, including ability to slice & dice? Again not so easy - it might be that the entire system is just one report, and all the intelligence is going to go into how to present that segmentation.

Anyone have any ideas how to do a fixed price quotation for a UI design like this?


The problem with estimating is it involves predicting the unknown so you need to clearly define the process that you're quoting for to reduce the unknown elements.

For instance, your process might be:

  • Initial review of existing materials and documentation (0.5 days)
  • 1 day workshop to discuss options and proposals (1 day)
  • Workshop write up and production of outline specification and approach (1.5 days)
  • Review of outline specification with client and approach followed by minor revisions and sign-off (0.5 days)
  • Detailed analysis and design with workshops as needed (5 days)
  • Write up of final design (2 days)
  • Workshop to review final design (1 day)
  • Feedback and revisions to final design, no more than three iterations (3 x 0.5 days)
  • Final sign off (0.5 days)

In each case you need to state what is needed from them in terms of reviews and you need to state where you're iterating the maximum number of iterations you're going to do. Explain that the reason for this is to allow you to give him the fixed price he wants and that he needs to understand that you're working the way he wants, so he needs to keep his side of the bargain and focus his team on it when they're needed.

Once you've agreed a process you can estimate it fairly accurately. For me there are two key tricks:

1) If you're not sure about how long something will take, break it down into smaller tasks. These are smaller (and easier to estimate) but you'll often also pick up on little things you'd forgotten you'd have to do.

2) If the number seems instinctively wrong (normally too high) review the figures but don't change them unless you honestly think you've incorrectly estimated one of the individual tasks. Our instinct tends to assume everything will go well and skip dull stuff (writing up the workshops? yawn... but it has to happen). Unfortunately in the real world the little stuff has to happen and it never quite goes how you want it so don't pretend it will be otherwise - any estimate or process where you find yourself yourself going "so if all goes well" is a bad one and needs changing.

On top of this you need to add contingency - three sorts, two you must add, one you could:

The first covers time to deal with specific risks which might arise. Go through and list all the things you're not sure about but think might come about and add time to the process.

For instance you think that there is a chance you'll need to do some prototyping. Estimate the likelihood it'll happen, how long it will take if it does then multiply the two together. Perhaps you think it's 50% likely to happen and will take 2 days if it does - add 0.5 x 2 days (1 day) to the estimate to cover that.) Add all these up and add that.

The second is "shit happens" contingency. IT projects are unpredictable and things happen you didn't expect. You can try and figure it all out in advance but you won't manage so try and figure in the major stuff and for the rest add a percentage to cover it. I'd normally go for 15% but that can drop to 10% if you think the process is solid and the customer is good and focused, as much as 30% if you think they're flaky.

The third sort is for the client rather than you. If he says that he can't promise they'll stick to the process as much as you need him to, you say "fine, the process is what I've quoted for but let's have a change allowance". This is his budget to spend on deviations from the process. Say you've added five days for this and half way through he asks for an extra workshop which wasn't in the process. It'll take you a day to have and a day to write up - you say "If you want that it's two days from the five day change budget" - he can either agree or not.

This means that you get your process and he gets the ability to deviate from it without going back to his project board and asking for more money.

Oh, and record all the time you do spend. This allows you to compare what you thought it would take with what you did take so you can improve the estimate but also means that if you overrun you know by how much and you might be able to sneakily add it to the build phase and recoup the money.

One last thing: at some point he's going to say "If it takes less time will charge me less?". The answer is no. A fixed price removes the risk of overspend for him but means that you pick up that risk. Your reward for accepting this risk is the possibility that you make more money if it comes in early but he doesn't get it both ways. Charging him less if it comes in under means you get no benefit if it comes in early but get all the pain if it's late - not fair really?


I'd suggest time-boxing the design work. This allows you to give a fixed price, but also focuses your customer's mind on making the most of the interactions with you during the design phase.

If you fix the price without time or scope-boxing, you are creating an open-ended commitment which is actually not good for either party - you'll have to charge a higher price to cover the risk, and you may even find yourself arguing with the customer about what is included in the price. A smart customer will realise that this is not in their long term interest....

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜