What is project based pricing?

Project-based pricing (or project-based billing or bill-by-project) is when a vendor (freelancer, agency, or consultant) and their client agree on a fixed price for a fixed scope of work. For example: logo, business card & letterhead for $1500 or website with 5 pages for $5250.

As part of the contract, the vendor and client typically agree on a payment schedule tied to milestones, such as:

• 30% up front to start the work
• 20% on meeting Milestone A
• 30% on meeting Milestone B
• 20% on final delivery

Advantages

Project-based pricing is easy to understand. Vendor and client agree on a price. The price is known up front by both parties. The terms under which the vendor will be paid are clear.

No hourly reporting needed. Surprise! It turns out that people don’t like tracking time (except if they’re using tools like Clockk, of course! 😆).

Clients know the project’s final cost. For the client to decide if they want to proceed with a project, they simply need to ask themselves if the value they will receive is worth the price they will have to pay.

Clients can easily compare vendors. The client can prepare an RFQ or RFP (Request for Quote or Request for Proposal), send it to a number of vendors, and get a variety of proposals. Assuming each proposal has the same deliverables (it normally would, given the RFQ/RFP process), the vendor is easily able to compare on price and other criteria (e.g. timeline, team, reputation, etc.).

Clients can easily budget for the project. Given a proposal for a $75,000 project, the client can seek approval for that spend. The alternative (Time & Materials) is to request for an indefinite budget based on a looser scope of work.

Vendors can make a lot of money. In project-based pricing, the vendor charges by the project, not by the time the project will take. Because the client is buying a completed project for a fixed price, the vendor can charge as much as the client is willing to pay. This is often called value-based pricing.

Disadvantages

Projects, particularly software projects, often change scope. As a non-trivial project gets underway, the client often recognizes they forgot a feature, asked for the wrong feature, or having seen some work-in-progress, want something different than they originally required. Now the vendor and client need to make a “change” to the project, essentially amending the contract with a new scope and a new price to reflect that scope.

Change management is hard. In The Mythical Man-Month, Fred Brooks rhetorically asks “How does a project get to be a year late? One day at a time.” One of the ways a project slips is by the vendor allowing changes without formally scoping them in a change document. Even if a change only takes a couple days, or even just an hour, it’s unscheduled new work that takes away time from scheduled work. Not only does the vendor cause their project to be delayed, but they also short change themselves on the money they could have earned. Why do vendors do this? Because it’s much easier to simply make a change than to go through the whole change management process: write down the change, assign a price to it, get the client to agree to the change (in writing), counter-sign, etc. Often, the client has previously said that they have no more money, so now the vendor feels an obligation to deliver a good product for no additional cost. The administrative burden can be so high that it’s often easier to simply do the work.

Clients feel they need to “ride the vendor” (aka “vendor management”). Project-based pricing can create a bit of an antagonistic relationship between vendor and client. The vendor wants to minimize their work because that maximizes their revenue. Knowing this, the client makes sure that every in-scope feature is delivered. The client may also look for ways to squeeze in extra requirements — especially requirements left vague or arguably implicit. The culture in some businesses is to expect managers to squeeze as much work out of a vendor as they can. By no means are all vendor/client relationships hostile, but project-based pricing creates an incentive for clients to behave antagonistically.

Vendors can lose a lot of money. Just as they stand to make a lot, vendors can lose a lot of money in project-based pricing. Projects that have a substantial research component — where how to do a particular task is unknown — are subject to significant cost overruns. Vendors that don’t have good change management controls can easily spend far more time on a project than the price justifies.

Risk

The vendor assumes the majority of the risk in project-based pricing. By choosing the right price, the vendor can make a lot of money, but they can just as easily lose a lot of money by choosing the wrong price. The responsibility for saying “no” rests solely with the vendor.

The client also bears some risk because they may have made a mistake in their requirements and may need to make a change. That means additional process, additional budget, and additional management reviews.

When to use project-based pricing

Project-based pricing is most appropriate for projects that have a clear scope (vendor and client agree on what the deliverable will be), a definable end point (what constitutes “done”), a timeline (project starts on May 1 and ends on July 15), and budget (project costs $5000 + tax).

As a vendor, the very best candidates for project-based pricing are projects of a scope that you have done before, especially where you have an established process. If, as you write your proposal, you find yourself saying:

• “This project is just like the one we did a year ago, but with a couple extra features”
• “We’ve written a dozen mobile apps like this”
• “We’re up to date on all the HIPAA regulations”
• “We have SOX controls in place for…”
• “We start a new client on an SEO review every couple months”
• “Building web apps with Ruby on Rails is what we do all day every day”
• “This is a perfect project for our new junior designer to get their feet wet”

then your project is probably suitable for project-based pricing.

When not to use project-based pricing

If you find yourself saying any of the following, the project may not be well-suited to project-based pricing:

• “I’m really excited to use that new server-side development tool”
• “I think this startup company has a lot of potential”
• “UX design for a new hardware project? Sounds cool!”
• “I haven’t worked with embedded systems before…”
• “For ongoing support…”

In each of the examples above, either the scope, the timeline, or both is unclear. You might want to use Time & Materials billing or set up a retainer agreement. You can still use project-based pricing, but be very careful to word the contract clearly in your favour!

Conclusion

Remember that in a services business, all projects have a time cost, no matter which pricing/billing method you choose. Don’t let yourself think that because you’re charging for the whole project that you don’t need to track your time. An automated time tracking tool like Clockk is ideal for agencies and freelancers that prefer to bill by the project, because it’s easy to identify just how long each project takes, while minimizing the overhead of tracking that time. Sign up for free.