Keep clients happy with documented assumptions, clear expectations, and solid contracts.
By Wesley E. Warren and Jessica Warren
Good communication is essential when you provide design services.
If you follow the guidelines within this article, you should be able to greatly reduce billing and invoicing headaches that can come with the design business. All of these methods were developed over the course of working with clients for the last twenty years.
Hopefully you can apply some of these ideas to your future projects and it will help them run smooth, on time and on budget. Most of these lessons were learned the hard way, this guide should help you avoid some of the pain we dealt with while freelancing, then running a design shop, and then managing a development firm and running an engineering team.
The lessons I have learned can apply to almost any service based business, from a logo designer to a remodeling company. Anyone who provides a custom service (like web design) to a client can use these principles and techniques to make their project run smoothly. If you are on the client end of the transaction, use this as a guide as what to expect from a professional experienced project manager.
Most problems arise from miscommunication or unrealistic expectations. This is true for both sides of the equation. The most critical aspect of a successful project is that both parties are treated fairly and understand what to expect when the project is complete.
No one wants to be taken advantage of. This is true for a client who, especially with technology, often has little idea what is involved in delivering a solid product. The same goes for designers and developers who often end up quoting a job at a certain price, then end up having to do twice as much work as expected.
These problems stem from miscommunication, false assumptions and misaligned expectations. This can be devastating for a small business, so it’s critical to have a good plan.
I am going to outline some basic ideas and principals that should eliminate the majority of these problems before they begin. This will save you endless pain and suffering when dealing with the financial aspect of the design and development service industry.
The difference Between Initial Concept and What’s Delivered
Create a well defined proposal.
Without a clearly written project scope, a project can be delivered that the designer feels is complete, but the client had assumed it would meet some other criteria. This is common for freelancers who are starting out.
This can happen for many reasons:
- Expectations were not clearly communicated and/or understood.
- There was no RFP that detailed the requirements.
- Expectations changed after work began.
- Multiple stakeholders have conflicting goals.
- Assumptions were not documented.
When one of these situations occur, what usually happens is the service provider loses money due to the extra hours required to deliver the project. Or the client feels that the designer didn’t fulfill their obligations. Either way someone loses and usually both parties are unhappy.
Sometimes the problem is as simple as the client doesn’t really know what they want or doesn’t know how to accurately express it.
A simple logo or brochure can go from being a straight forward 10 hour project to a 30 hour project due to endless revisions. A handful of “tiny changes” that trickle in can add up to several hours (days!?) , while the client expects to pay what was originally agreed upon. This can be very frustrating for even the most experienced designer.
There are some proven ways to avoid these issues all together, keeping both parties happy and ensuring each party receives exactly what is expected. Below are some essential components to keep your business interactions running smoothly, whether you are a client or a service provider.
- Allow time for research.
- Avoid unrealistic deadlines by thoroughly reviewing the project.
- Create a clear understanding of the project, possibly breaking it up into phases.
- Keep ongoing communication through-out the development.
- Create a log of change requests and new challenges that arise.
- When a project is at risk, stop and communicate as soon as possible.
Accurate Project Schedules and Realistic Deadlines
Before I get into the specific contract strategies I want to touch on another issue that can cause headaches. Deadlines and time frames are a critical aspect to any project. And the more complex a project the more likely there is to be unforeseen issues that arise which cause the project to be delayed.
Anyone who has worked on complex projects has most likely come across this scenario. The project is planned and scoped out, then work begins. After completing a portion of the project, the client (or the developer) realizes that there is an issue which was not anticipated and will take more hours to complete.
This is commonly referred to as scope creep. It’s hard to visualize and anticipate a completed project in every detail. Even a well thought out project that looks complete on paper can result in something that doesn’t work perfectly in the real world.
Sometimes these problems are small and easily solved, but not always. When a complex issue arises, it can easily add significant time and cost to the project. This can cause a project to run late, over budget or end up costing the provider to eat the cost and lose money on the job.
One thing I have learned is that designers, developers, almost any person who will actually be performing the work has a tendency to underestimate the time it takes to complete a project. This is a normal part of human nature, especially for someone with experience and who is confident in their abilities. The problem is, there are almost always unexpected issues that arise.
If you are estimating time for work to be completed, it is good practice to give yourself some breathing room. Another fact to consider is that there are all kinds of activities that are required to complete work that are almost never considered.
A good example of this is, phone calls, emails, trips to the supplier, interaction with third party vendors, etc. Additionally there are a host of issues that can arise that have nothing to do with the project but can delay the project. People get sick, cars break down, hard drives crash, work gets lost, kids need to go to the doctor, etc. etc.
When writing our project schedule we always allotted one week per 25 hours of work estimated. While on paper a person may spend forty hours a week at work, there is no way that 40 hours of work can actually be done in that time. There are too many things going on in the world and people need to eat lunch and answer the phone and attend meetings and all the other miscellaneous tasks of work and normal daily life. Even if a full time developer can get 30 hours of work done a day, there will be unforeseen issues that arise. Plan to have time set aside for these unwelcome surprises.
If you have a project and you estimate it will take 80 hours of work, and you tell the client it will be done in two weeks, you are going to end up either working 60 hour weeks, or delivering a late project. This applies to adding a new bathroom, designing a marketing package or building an e-commerce website.
For many projects time is critical. This is one of the biggest causes of stress in project management. Rushing a project often means sacrificing quality and best practices. Your clients may want all three points of the pyramid of fast, cheap and good, but in practice you can really only have two. Something has to be sacrificed, but proper planning can help minimize the compromise.
Fast Cheap Good
Rushing a project often means sacrificing quality and best practices. Clients may want fast, cheap and good, but in practice you can really only have two. Trying to get all three will only end in frustration!
Unrealistic Client Expectations
Many times a client will have a demand that is essentially physically impossible. They may want a 120 hour project delivered in a week. They have a big media campaign launching and the project has to be complete and ready when the ads hit. The client waited too long to get the project started and now you the designer are expected to make it happen.
A colleague of mine once explained this to a client once with an excellent analogy. Nine women can’t make a baby in a month. Many companies think that any deadline can be reached if you just throw enough money at the problem. 120 hours in a week? Simple, get 4 people working on it. However, complex projects are almost never that simple, and adding more people increase the communication overhead producing diminishing returns.
Four designers can not design a brochure in ¼ the time it takes a single designer. Software development and construction projects are the same. When constructing a building, certain things need to happen in order. The foundation is poured, then the walls framed in. Electrical and plumbing is run, etc.
You can’t have the painters and drywall installers show up the same day as you pour the concrete foundation and expect the project to get done faster!
There may be portions of a project that can be worked on in parallel in a team, but some things simply can not be done that way. If you are facing a client with an impossible deadline, this needs to be clearly addressed and dealt with. Often there is a compromise that can meet the short-term needs of the project, while the rest of the work continues and is delivered at a later date. Break out the project in staggered phases so high priority items are delivered first.
Complex projects should always be broken down into sections. If there is a critical deadline perhaps a few sections of the project will meet the immediate needs of that deadline, then the remaining parts of the project can be developed in a realistic time frame.
Making unrealistic promises will always end poorly. There is a saying that goes “A client will not remember a late project, but they will remember a project that didn’t work”. Best not to deliver late or broken by giving realistic time frames. If it happens to be one of those rare occasions when everything actually does go perfectly, you deliver the project early and the client is impressed.
You can learn more about this in depth in the excellent book by Fred Brooks a former IBM software engineer called “The Mythical Man Month” which describes how adding developers to a project actually makes it take longer!
Safeguards and Solutions
Avoid problems before they start.
Project Scope Document
It is essential that you have a complete understanding of what you are expected deliver to the client. The best way to keep your project under control is to have a thorough project scope that describes all the critical aspects of the work.
Your project scope should contain the following:
- Summary of the project. A few paragraphs that give a high-level description of the project, including the goal of the project.
- A breakdown of each section of the project, what it will entail, how long it will take, and how much it will cost.
- A clear list of deliverable items. What exactly will the client receive and how will they receive it.
- A Contingency Policy that describes how unforeseen issues will be dealt with.
- Payment Schedule – How the job will be billed and paid for.
- Revision Schedule
Your project scope should be part of your contract, with the client and the provider each having a signed copy before any work begins. It is a sign of a professional to have a well thought out project plan so the stakeholder knows what to expect.
In design work there is usually a back and forth where the client will give revisions, for example with logo design. The designer will usually put together a few ideas and review them with the client. The client will then make suggestions and the designer will make adjustments and repeat the process until the client is happy.
However, sometimes this process can seem to go on forever. And if you have charged a set fee and the client is not expecting to be billed for changes, the project can go on for ever.
To circumvent this, put together a revision schedule. Create a document that outlines the standard procedure including the number of revisions allotted within the contract price. Explain in your document that if additional changes are needed beyond the standard 3 revision (or whatever number you decide on) that you will bill X amount for additional revisions.
When you are working with the client, ask for the revisions in the form of a numbered list. Clearly state which revision set you are working on. The first revision list is usually the longest. When you finish that revision list, return it to the client and see if they need another set of revisions. Once they get to the last allowed set, let them know this is the final set of revisions within the contract.
This process should be explained completely before any work begins so the client knows what to expect.
The contingency policy is central to avoiding projects spiraling out of control, and to avoid clients and providers from feeling they are being taken advantage of. We had all of our clients read and sign our contingency policy before any work began.
Your contingency policy should spell out how work beyond the scope of the project is handled. One contingency policy read something like this:
This is taken from one of my previous companies project scope / contracts:
For each section in our proposal we give an estimate as to how many hours it will take to complete the item. Often there are events that can cause these number to increase.
Most often what causes a section to take more time than is estimated here are changes requested by the client. Also, but not limited to: GUI changes, process changes, additional features, graphic and functionality tweaking, third party vendor requirements, and extensive meetings.
These events can cause a section to go over budget and create additional billable hours. You will be notified ahead of time if a section appears to be heading for an overage, then you will be given options on how to proceed. Overages that stem from these issues are billable.”
If you are dealing with a new client, it is often best to request a deposit for you to begin work. You should certainly never turn any work over to a client that has not paid for the work. Asking for the entire fee upfront is just as unreasonable as doing a week worth of work without being paid.
If you are dealing with a very small job, just a few hours work, then working without a deposit may be safe as long as you have agreed on what is being delivered and what it will cost. Even when only dealing with a one hundred dollar contract you should always have a project scope, even if it’s just a half page long describing the work. Designers you can always deliver a watermarked or low res version of the final work for approval and payment before the work is released.
If there are expenses being incurred for materials or license it’s best to have the client pay for those directly. Otherwise, make sure you add on the material cost to the deposit. The deposit should be for all materials as well as 50% or 25% of the labor.
Short term projects that will last only a few days or a week can usually be broken into two payments. Common practice is 50% down and 50% upon delivery, we have also dealt with 25% and 30% down with the remainder payable on delivery for short jobs.
Payment Schedule for Large Projects.
For larger projects that will take several weeks or months you should establish a payment method and billing schedule. Most corporate and business clients prefer to be billed no more than once a month. Break up the project into sections and deliverables.
Create individual deadlines for each section. If the total project is estimated to cost $10,000 and take 5 months, a reasonable billing schedule would be $2000 per month.
The provider should be able to show which sections will be delivered each month so the client can monitor progress on the project. Any additional billing should be noted in your contingency policy and billed appropriately either on top of the standard monthly retainer or at the end of the project.
If you follow the guidelines within this article, you should be able to greatly reduce billing and invoicing headaches that come with doing business. All of these methods were developed over the course of doing business and managing design and development teams over the last twenty years.
Hopefully you can apply some of these ideas to your future projects and it will help them run smooth, on time and on budget. If you found this article helpful, please share it on your blog or social media.