Contract Killers

In: Articles

By Andy Budd

Published on September 17, 2007

No, I’m not talking about hiring a hit man to take care of a difficult client, although I’m sure we’ve all been there at some stage. In this article I’m going to be discussing the tricky situation of quoting for web design and development projects, and the various types of contracts you can agree upon. Enthralling stuff, I know, but I hope that I can show you a way to make the arrangements between you and your clients fairer, and less risky, for both sides.

You are not a beautiful, unique snowflake—but your project is.

As designers and developers, we sell a service rather than a product. Selling a product has it’s own problems, but you generally know how long the product will take to build, how much it’s going to cost, and what profit you plan to make. With a service, even if you have created something very similar before, there are many factors that come into play.

All clients are different, and have different needs and expectations. One client may give you little or no feedback, while another may want to be involved at every step of the way. Some clients will have a single decision maker, while others will need to take into account a boardroom full of opinions. Some clients will be quick to approve milestones, while others may take longer or require multiple iterations. None of these styles is right or wrong, but they all have implications on the time and cost of a project.

Just as every client is unique, so is every project. Goals will differ, priorities will vary, and no two implementations will ever be the same. Take social software—it’s easy to look at a function such as friendship and assume that if it takes X days to implement a friendship mechanism on one site, it will take the same on another—after all, the concept is similar. But when you start looking at the details, friendship is a complicated thing. Should friendship be unidirectional or bidirectional? What permissions do friends get? What happens when you un-friend somebody? All these questions need to be asked, and their answers will all have a significant effect on time and budget.

The dreaded functional specification

One way companies try to combat this is to write extremely detailed project specifications, which spell out every function and interaction possible. Once all the interactions are known, the logic goes, it’s much easier to cost a project. This is the classic IT project structure and is often known as the waterfall process. On the surface this makes a lot of sense, but look deeper and you’ll see that the problems are numerous.

Fixed-cost, fixed-scope contracts tend to favor the client, while putting the majority of risk onto the supplier. The supplier is forced to scope the project thoroughly, and the chance of under-quoting is high, so to offset this, suppliers will add a large contingency to the project in order to cover these unknowns. While most savvy developers will also charge for the scoping process, some write this off as part of the sales process. This can be expensive and is a risk unto itself.

Unfortunately, these contracts aren’t great for the client either. As well as being charged more for the associated risk, the client can lose out on functionality by having to commit to the scope up-front. If new features are thought of, or if the business landscape shifts, change can be difficult and expensive; like trying to turn a tanker at full speed, it’s possible, but it’s not easy. It’s good to gain a competitive advantage, but not if it means the project never gets finished—around seventy percent of traditional IT projects fail.

Ultimately, these type of contracts are very adversarial. Opportunistic clients will try to stretch the meaning of various functions, or look for loopholes in the specification that can be exploited. Conversely, designers and developers are forced to manage scope creep with an iron fist, in order to stay on track and maintain some level of profitability.

To get around these problems, many of the larger IT companies work on a time and materials basis. A rough estimate will be calculated, but final cost will be based on actual time spent. This is very attractive to suppliers, because if the scope changes or if clients are indecisive, they can charge accordingly. Unfortunately, this puts all the risk on the shoulders of the client. If the supplier under-quotes, or is opportunistic, project costs can skyrocket. Ever wonder why you see so many government IT projects double or triple in cost?

These contracts represent each end of the spectrum; one favors the client while the other favors the supplier. Both of these contracts aim to gain a commercial advantage over one party, while neither represents the best interests of the project—it’s all so very last century. But what can be done?

The Third Way

Using our best user-centered methodology, let’s look at the concerns of each party and see how they might be aligned.

Client concerns:

• I need a functioning site that meets my business objectives.
• I need to know how much this project is going to cost, so I can set a budget.
• I need to make sure that the budget doesn’t overrun by too much.
• I don’t want to be over-charged by some unscrupulous suppliers.
• I need to know when the project is going to be finished.

Supplier Concerns:

• I want to create the best site possible so it looks good in my portfolio.
• I need to know exactly what it is my client wants
• I need to be able to alter the scope based on new or clarified information.
• I want to avoid scope-creep eating into my profitability.
• I need to know when the project will finish so I can schedule in new work.

You’ll notice that our client and supplier concerns are remarkably similar. Both parties want to do the best job possible, on time and on budget—so how do we align these goals?

Target scope

At Clearleft, most of our work is of the fixed-budget variety. A start-up will come to us with an interesting concept, a modest amount of seed funding, and the desire to create something special. While not an agile company per se, we try to work in as agile a way as possible. We realize that it’s impossible to specify a large social software project with any degree of certainty at the outset, without doing the required research, prototyping, and testing. During this process, the project will always change—concepts will be refined, user-flows will morph, and features will be added or dropped. So instead of using a fixed-price, fixed-scope process, or a time-and-materials process, we favor a target-scope process.

We begin a project by sitting down with the client and working out a rough scope, usually based on our personas and user journeys. We then extract all the key features and functions and start to prioritize. Anything that we feel is central to the application is marked as core—these are the items that form the core of the application and are vital to the success of the project. Any features we think are going to be too costly or difficult to implement at this stage are marked as deferred and considered for a future iteration. Everything else can now be marked as desired. These are the nice-to-have items—the stuff that would add value to the site, but could be dropped without it adversely affecting the success of the project.

Next, we estimate roughly how long each item will take to complete. The result is a spreadsheet that shows both the importance of each item and the associated cost (or effort). We pass this to our client and allow them to adjust the priority until they feel it matches their business needs. This gives our clients a real sense of accountability, as they know roughly how much each feature will cost, and how it’s going to affect their overall budget.

At the end of this process, you’re left with a list of core features you commit to creating, along with a series of desired features from which you can cherry-pick if you have the time. For this process to work, you need to be pretty good at keeping track of time, so a good idea is to share your estimated and actual times with your clients once a week.

This process helps balance the needs of the client with the needs of the supplier. The client knows that whatever happens, they will get a functioning site that meets their business objectives. They also know exactly how much each element costs, and the value it means to them. On the other side of the equation, the supplier knows that if a feature is taking longer than expected to implement, or a new feature is required, the extra time required will come from amending the scope rather than eating into their profitability.

Target cost

Similar to the target-scope model is the target-cost model. With a target-cost contract, the scope is be fixed, and the budget becomes flexible—but this isn’t a license to print money. Any overrun that is the responsibility of the client (e.g. new features or slow feedback) gets charged at the usual day rate. However, any overrun that is the responsibility of the supplier (e.g. fixing bugs or misunderstanding the complexity of a feature) is charged at cost. This way, the client has the flexibility to pay a little more to get the extra services or functionality they need, while the supplier makes sure they neither profiteer or are penalized for bugs or issues out of their control.

Summary

Both of these contracts reflect a middle ground, where the needs of all parties are taken into account. Nobody gets the upper hand—but equally importantly, nobody loses out. This leads to a level of equality and respect that helps foster a good working relationship and ensures the success of the project. If you haven’t tried a target-scope or target-cost contract before, I highly recommend that you give it a go.

Related Topics: Planning, Client Management, Business, Basics