[dclowd9901]

And here's one reason that overrules all 5: because the customer doesn't like surprise pricing.

Their business is knowing how much something is going to cost. This isn't exclusive to the project I'm working on with them. This extends to every aspect of running their business. Whenever I see a business owner angry about a new government policy being considered that would impact their business, they're rarely upset about the policy itself and more upset about the vagaries that come with being affected by the enigmatic legislation process. Small businesses and even medium sized businesses flourish under consistent understanding of their costs.

Even if I'm not as big a shop or even as talented a shop as the next guy, I know almost any company is going to go with me because I will give them a number and I won't deviate from it unless they, themselves, have deviated so far from the scope that I have to forewarn them that the project needs to be re-estimated. At which point they understand because they're a business owner too.

Moreover, it just feels sheisty. It feels like a bait-and-switch. If I severely underestimate my costs on a project, I shouldn't be passing that mistake along to the customer. It's not their fault. It's mine. I'm the expert here. I'm the professional in this field they hired me to be the professional in. How can I go back to them and ask for more money because I didn't prove myself to be professional? It's not their concern how I run my business, nor should it be.

[j45]

Great point. Giving or receiving surprises is kryptonite to consulting relationships.

Part of the value we must provide is be the guide to finding and doing the things a business needs to move forward, and help communicate the risks, unknowns and things that have to be figured out before ever starting them so the customer gets to participate in things as an experiment.

[dclowd9901]

To put it a more geeky way, pretend you're building an API. Would you want your two disparate systems (your services, and the client) to "know" about each other's internals? Of course not. It's no different for business interfacing. All the client wants to know when it inputs Money into You is

1) What are the deliverables?

2) What is the value?

So that's all you should be concerned with "exposing" to their side of the API.

[iktorn]

Our "response" to this is radical transparency. Client should be able to track the progress in almost realtime.

The problem is that usually the business is not sure what it wants then the project starts - the scope is not well defined. And it's ok. This is something that all stakeholders learn along the way.

[dclowd9901]

And my response to this is that if you don't have a scope clear enough to accurately figure out your project's pricing, that's your fault. The second part of this is a mutual understanding that scope is gospel. This means the client has a clear understanding of the end product and what problem it's going to solve, and you're going to have the same understanding. Changes to the gospel mean changes to everything else.

Obviously running a business is part philosophy. If you don't mind a customer looking over your shoulder throughout an entire project, second guessing your time usage, then sure, I can see how an hourly situation might work. I despise that, and so I've found fixed pricing to be my preferred approach (which has the apparent added benefit of being very appealing to most clients).

[j45]

"And my response to this is that if you don't have a scope clear enough to accurately figure out your project's pricing, that's your fault. "

Bingo. Hourly or fixed doesn't matter here. Both will mess up the relationship because there's no value delivered in the clients eyes.

As for the micromanaging; some customers like running a daycare for adults and babysitting everyone. I prefer to not be in these relationships and in exchange be proactive with our updates.

[porker]

> And my response to this is that if you don't have a scope clear enough to accurately figure out your project's pricing, that's your fault.

How do you get around companies wanting a fixed price without knowing entirely what they want? As a freelancer I can't spend 2-3 days of meetings and spec writing only to lose the project because they preferred an agency/another supplier.

If I had clients who would pay for a 'Consulting' phase of producing a spec (which they could then send to other agencies/freelancers) then I could see this working, but those are like unicorns.

[snowwrestler]

Adjust the way you think of the word "scope."

To people who build websites, scope means technical scope--the features, functionality, design, backend etc. A precise technical scope makes it easy to calculate a price.

But to people who buy websites, scope means financial scope--a "$100,000 project" vs. a "$20,000 project." They don't know precisely what they want...because they don't know what is possible. That's why they are hiring you!

So you learn as much as you can in the RFP process and propose your fixed price based on that. Unless the client or RFP is a terrible lie, you should be able to get it in the ballpark.

From there, closing the sale depends on your ability to convey that your expertise will help the client get the best possible product for this "scope" (i.e. price). If you want to cover a few more bases, you can provide some optional levels of effort for the riskiest items, or "nice to haves."

[snowwrestler]

It's possible to be just as transparent and flexible under a fixed price contract. And if changes need to be made, they can still be made on a change request or contract amendment.