Hacker News Reader

Comment by iktorn | Hacker News Reader

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.

View on HN

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).

"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.

> 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.

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."

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.

Reply on news.ycombinator.com