| « Creating services you won’t hate | Why estimates never work » |
My recent post on the reasons estimates suck generated some interesting questions about the management of client work, specifically related to client expectations and the “need” to offer an estimate of completion or cost to the client. Some of us are lucky enough to have internal clients to whom we can refuse to estimate; others are working with external paying clients who really want an answer to the question, “when will this be done?”
There are some ways that you can avoid offering estimates and still make your clients happy. The solution lies in figuring out precisely what question your client is asking when they ask “how long will this take?” Clients are asking this question usually for one of two reasons: because they have a business need that is unmet and they need this ASAP, or because they are trying to control cost.
In many cases, these two points of view are exclusive of one another. Clients who care about having it done yesterday will usually be a little looser with their budgets; clients who are concerned about cost may be looser with their timing. As an aside, clients who care about both are usually undesirable clients who have little money, high expectations, and are a pain to work with. It’s best to avoid these clients altogether.
Let’s examine each of these positions in some greater depth.
Every business that hires an outside consultant has a business need. The key here is that the business need is urgent – the client is losing money, customers, time or sanity because of their problem. For these customers, solving the problem is the most important thing that they can do, and it needs to happen as quickly as possible.
In an ideal circumstance, these customers care less about their budget than about solving their problem. They are willing to throw money at the problem to make it go away. And they’re willing to pay whatever is reasonable to get it done.
Still, with these customers, they are more interested in hard deadlines than other customers. Managing their expectations is key. There are a few strategies you can employ. First, make sure that you discuss with the client the concerns and reservations you have about the project. Making it clear that you have things that you’re still investigating helps make clear to them that there’s uncertainty, at least in the beginning. Arrange to show weekly demonstrations of progress on the project. By incorporating the client as an active participant rather than someone who sees the finished product and decides whether they like it or not, your client will be less antsy and more willing to work with you. Finally, make sure they understand how many resources you have dedicated to the project in terms of blocked time and persons.
These kinds of projects are also the types of projects where very tiny bits of scope are essential. The faster you can start shipping, the better off you’ll be. Once the client feels the pain lessening, they’ll back off the time pressure, and you’ll have more time to work.
Almost every client is concerned with budget, though some are more concerned than others. There are some small businesses for whom a $100,000 invoice wouldn’t be the end of the world, and others for whom such an invoice would put them out of business. Knowing which type of client you have is important.
With budget-sensitive clients, I often take a fixed-price approach. They actually don’t care as much about delivery date as they do about final price; asking about the delivery date is a way of time-boxing the project so that their costs don’t overrun. This is the more common underlying question in the “when will this be done?” question.
Fixed-price projects can be good for everyone. The customer gets a fixed price regardless of how long the job takes, and the developer doesn’t have to worry about the client balking at an invoice. But if done poorly, fixed-price jobs can be disastrous for you so it’s important to do them right.
I’ve learned from painful experience that the best way to ensure your fixed-price job won’t go completely off the rails is to ensure that you’ve got a solid spec first. But developing a solid spec takes time – time that you shouldn’t be giving away for free. Most companies and developers make the mistake of assuming that the spec should be done gratis before the project commences (or worse, written entirely by the customer). Writing the spec is part of the project, and should be part of the fee paid for the project.
Once the client has decided they want to work with you, propose a $1,000 – $2,000 fee for the development of the spec. Explain that developing a spec beforehand saves money by ensuring that their concerns are addressed and that everyone is on the same page. Invite them to your office for a couple of days; bring in a member of the UX/UI team, and developers as needed, to offer advice, propose ideas, listen to the client, and derive what this thing is and how it will work.
At the end, put it together as a wire frame and notes about what each function will do and how it will behave. If you do this, you’ll have a spec – one that you can quote a price and get to work building. Make clear at the end of the process that any additions to the spec or significant changes will result in a higher fee, to be negotiated later. It’s also best to offer the client different options, so that they can choose to incorporate Option X but not Option Y or Z; this allows the client to have greater control over project cost in the long run.
As you price out the specification, avoid the temptation to charge based on the hours it will take you or your team to complete the work. Instead, it’s best to charge based on the value to the client. In other words, even if installing a plugin will take 30 minutes, if the value to the client is $50,000, charge appropriately. This will give you padding in areas that might not be so valuable or obvious to the client (like designing a database schema).
Sometimes projects don’t have scope, and all the collaboration in the world won’t produce a scope. The projects are just largely undefined, a mass of “well, we think we want X but we might want Y”. That makes estimating and costing these projects nearly impossible. What can you do here?
If these clients are willing to work on an hourly basis (e.g. are not budget-sensitive) and are patient (e.g. not time-sensitive), you have a winning combination. Work closely with these clients. Propose solutions, offer suggestions, make improvements and create value. As the project progresses and the scope becomes more defined, you can move towards a fixed-price model or stick with an hourly model – that’s between you and the client.
Under no circumstances should you agree to work with an undefined scope project where time or budget are sensitive, however. Doing so will only create stress and pain for you in the long run. “I don’t know what I want but I need it now” projects or “I don’t have any money and I don’t know what I want” projects will suck your soul dry. Until the client has an idea that you can turn into a scope, don’t go there.
Every project has a bit of scope creep from time to time. It’s almost inevitable. A group of people sitting in a room can think that they’ve covered every contingency, until one comes along they hadn’t planned for. What do you do in this case?
The answer is simple: you agree to perform the additional work for an additional fee. Period. Every additional feature or project costs extra. Stand firm on this, and never budge.
Why? Because the second you budge off this position, you’re finished with the client. You’re working for free, and they’ll take advantage of you (even if they don’t realize they’re doing it). You and the client are in a professional relationship. You wouldn’t ask your lawyer or your contractor to do free work, and you shouldn’t do it either.
Refusing to do free work isn’t going to cost you a client. Often we worry that if we say no we’ll piss off the client and they’ll pull their business. But a client that doesn’t respect your time or value isn’t the kind of client you want to have in the first place, so it’s actually best if they go elsewhere.
It’s tempting to answer the question of “how long will this take?” with an estimate. But the truth of the matter is, all an estimate does is create an expectation that we have little hope of keeping. That’s a terrible way to start off a relationship. It’s far better instead to offer up expectations that are realistic and reasonable. And at the end of the day, it will help you to be more profitable in the long run.
Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP
Posted on 4/30/2015 at 8:00 am
There are currently no comments.
| « Creating services you won’t hate | Why estimates never work » |