If I had to tell you the complaint I hear most frequently from clients, it’s normally something about their last developer and it tends to be somewhere along the lines of “I paid thousands of dollars and never saw a completed product” or “The finished product wasn’t what I wanted it to be” and I attribute that, largely, to the large block approach to both development and pay.
I’m sure you know what I’m talking about if you’ve ever commissioned a piece of software. You pay 50% of the total project price up front and fork over a long list of requirements. At the end of the project, you’re handed a product that probably does about ¾ of what you thought it would and you’re expected to pay the final half of the bill. You may not have had much input along the way or you don’t feel like the final product is what you wanted it to be, even if that’s what it was on paper.
These situations aren’t necessarily anyone’s fault and don’t have to come from bad contractors or bad clients. Often, the way these projects are structured leads them to failure before they get off the ground.
You see, when structuring a contract you have to look at what behavior that contract is really rewarding. When you choose a “Half now, Half later” payment approach, the incentive is to sell as many contracts as possible(the first 50%) and close as many contracts as possible with the minimal effort necessary to receive payment. Speaking purely from a numbers situation, a consultant “wins” in the short term when they can complete less than 50% of the contract while keeping payment or close a contract at 100% payment with as few features as possible.
Now, I’m not saying that everyone in the industry going to think in those terms or is out to do the minimum. What I am saying is that it can lead to asking good people to work against their own self interests in order to uphold their integrity. Whenever possible, aligning other’s best interests with your goals tends to lead to superior results.
So how do we do that? Well, my personal favorite is to push work from a project based approach to an hourly one but to do so with clear controls and milestones in place. To expound a bit there; Let’s say we’re talking about an E-Commerce site. Now we might normally spec out all the features and set a price at $10,000 for the full design but what if we quantified the expected hours for each feature. We’ll start with a data import, assuming you’re coming from another platform. Let’s say that data import should take about 10 hours but could take up to 20 or 25 with complications.
Now, if I were doing that import for you and you insisted on fixed price, I would set the price at a point where I could comfortably spend 25 hours because I don’t want to lose money on your website. If we’re working on an hourly basis, it’s a bit different. Let’s say we decide to work hourly with pay on a regular time line(say, weekly or every two weeks) and quote out that import at “10-25 hours”. I’m no longer betting on a time to completion because you’re paying hourly, and you’re no longer paying enough to offset my gamble. When the project actually does only take 10 or 15 hours, you haven’t paid for 25 and if it does take 25, I haven’t lost by under-bidding.
Taking a step back, there’s another clear advantage to this approach and that’s modularity in both compensation and work. If someone quotes a certain number of hours for a portion of a project, you have a clear yardstick to measure their progress. If you’ve paid for 10 hours of work on a 10 hour piece of the project, you should have a tangible piece of completed work in your hands for what you’ve paid. You can very easily asses how well the project’s going by looking at the completed milestones alongside hours to completion of various milestones.
Furthermore, if you’re on a “pay as you go” schedule, completed work is yours. Should you choose to take what’s been built half way through and walk away with it, there should be no argument from your developer about doing so. You’ve paid for their time, not the work done, and they’ve been compensated fully. There’s never a situation where they feel like they own your project because there’s only been a partial payment and you’ll know about problems sooner because you’re paying for time as its accrued.
As I propose hourly billing, I can hear some people saying it can’t work because there’s no incentive not to let costs balloon. I won’t lie, there is some truth to that. There are two things I can say to counter it though. The first, is that, with frequent billing, you’ll understand very quickly if your team is becoming wasteful. The moment that 10 hour project hits 12 hours, you can step in and ask why.
The second is that project overruns will happen regardless, the question is where you see the cost. Most companies can only lose so much money. If a piece of software is going to take 40 hours to complete instead of the expected 20, the developer can:
a) Eat the costs
b) Charge for 40 hours
c) Cut costs and make it take 20 hours.
Very few people can afford to take option A. If you’re paying someone a set lump sum, they’re much more likely to take option C because option B isn’t really possible. If you’re paying hourly, you should have the opportunity to choose whether the company chooses to cut costs(i.e quality) or if you just pay more for the product. At that point, you’re given a decision instead of a bad product.
When to go fixed price
Alright, now that I’ve bashed fixed price contracts a bit, there are a few cases where they can be quite useful.
The first is with very small low-risk projects. Cases where you’re paying someone $50.00 for a very simple logo design or to install a pre-built theme for you. These types of projects are very unlikely to extend far in any direction and often have very sharp criteria for success. If you wanted a theme installed and it’s now installed, you’ve achieved success. Setting a predefined value for that success is an easy way to control costs and it tends to be a quick win for the professional who knows what they’re doing.
The second time fixed-cost can be appropriate is with a team you’ve worked with over a long period of time on past projects. In short, when you’re working with people you trust explicitly and you have a strong understanding of the value they bring to the table. If you understand well from past experience what a certain dollar amount can be expected to accomplish, all parties can step to the table in full understanding.
So, what if you really want to do all of your projects fixed price? If fixed price is a requirement for you, I would suggest capturing as much of the value of an hourly contract as possible by insisting on a few things.
1 – Build multiple milestones into the project at a fairly granular level. Let’s go back to our data port example. The data import, in this case, is a well defined piece of the overall website build and can be looked at in isolation and priced as such. If you set a price for that particular piece, payable when it’s complete, you retain the ability to break the project down and avoid situations where you’ve spent half your budget without commensurate results.
2 – Write your contract in a way that gives you full rights after each milestone. If you’ve paid for a theme design, that design is yours regardless of whether the rest of the contract is completed or paid for. Ensure that this is understood. If in doubt, frequently ask for a copy of the project. Most honest professionals who have already been paid will have no problem zipping up the work they’ve done and sending it to you as an archive.
The Mini-Project – Let’s see what you’ve got
One of my favorite propositions is the mini-project. Often, if a client is pursuing a large project($10,000+) I’ll suggest a mini-project to get started. This could be an initial site setup/theme install or something as big as a software prototype, if the product is entirely custom. Either way, the goal is to show the client what they can expect while working within a limited budget on a tangible product. A mini-project is usually between $300-$1,000 and should result in something that adds solid value for the client even if they don’t choose to proceed with the larger project.
At any scale, the mini-project is a good way to test someone’s skill without getting in too deep and should help avoid pitfalls of working with someone who isn’t up to the quality they claim to be.
At the end of the day, the two most important components of any professional relationship are trust and communication. If you establish trust with small projects, communicate, and insist on a front row seat to the work that’s being done, you’ll likely have better relationships with your best vendors and will quickly learn to prune those not working in your best interests. Work with someone who will see you as a partner, instead of a sale, and build long term relationships with reliable people. I think you’ll be pleased with the results.