Oct 15, 2012
An Ounce of Prevention
I recently asked designers on Twitter: What's an occasional problem/issue in projects that you wish would never happen? The responses I received were varied, but they all had one thing in common: the issues or their negative consequences are almost entirely preventable. By Andy RutledgeDiscuss
No matter how many project problems you encounter, none of them are caused by your clients. They're caused by what you did or did not do before you bid the project.
Since design pros are human beings, when we work with other human beings things are probably going to happen that we'd prefer did not. We're flawed that way. Alas, disagreeable situations cannot be entirely prevented in every case. However, by adopting a few professional habits or practices, you can prevent almost all of the common design project problems or prevent their consequences from negatively impacting your projects.
What follows are a few of the issues that my Twitter friends cited as things they wish wouldn't happen and they're all quite common in design projects. If you're a designer you've almost surely experienced them, so my Twitter respondents are all in good company. For each I'll offer advice for preventing or mitigating the issue. And for each, it requires that we do something important before the issue arises. After all, there are no sure cures for these problems; only prevention. Simple, professional prevention.
Problem: Clients dictating the design direction
Clients don't dictate design direction. Customers do. Perhaps you understand your role as the design professional, but your clients need to understand their role as client AND your role as the design professional. These roles must therefore be specifically expressed and addressed in pre-bid discussions and then later supported by your contracts so that everyone knows what they'd be getting into with a project. This helps to prevent potential clients from mistaking your impending relationship for a merchant-customer arrangement.
There are two things you must unfailingly accomplish in each project in order to prevent your client from trying to dictate design decisions: 1) Establish in pre-bid discussions that their role is as client, not customer, and that your role is to be the design expert, and 2) never ask your client design-related questions.
For the first item, your potential client must be made to understand that if they work with you or your studio, they're not working with hired technicians, but skilled professionals. As such, you're going to craft a design strategy according to your expertise, and not according to opinions (yours or theirs) or explicit direction from non experts. Their job is to be the expert on their business, their customers, their needs and other constraints and to communicate, expose, and make available that relevant information to you. That's how they can help you craft the best design strategy. These things should also be expressed in your contracts, so that if clients demand to direct design decisions it constitutes a breach of contract, whereupon you may then act on that eventuality as specified in your contract.
You can help support your standard by explaining to them that opinion has no place in a design project; not theirs and not yours, and certainly not anyone else's. Since opinions won't hold sway, you'll need something concrete and objective against which to evaluate your design strategy. This is why it's a good idea to employ a strategy brief, which should be a short, concise encapsulation of all of the vital constraints and objectives for the project. It should details things like the target audiences, perception/tone guidelines or standards, communication strategy, specific objectives, and maybe a primary message/goal (adjust to suit your context or that of the project). Use the standards and objectives in this brief to evaluate the suitability of the design strategy, ensuring it meets or fulfills every point.
For the next item, if you've defined roles appropriately and even contractually, you'll destroy that good work if you make the mistake of asking your non-designer clients design questions in the project process. They're not the design experts. You are. Therefore, you ask about their business, their needs, desires, challenges, etc…and then exercise your expertise on the design end. If you ask design-related questions of your clients, they'll expect their feedback to be implemented, destroying your previously expressed standards and perhaps even the project along with them.
Problem: Client goes silent for weeks without explanation then returns with ASAP requests
There are several components to the prevention of this issue. The first is that you establish in pre-bid discussions—and support with contractual constraints—that client stakeholders must be available throughout the project…with any planned-for absences exempted, of course.
Next, and most importantly, your contracts should detail that any client absence or lack of necessary communication for more than 5 days (or whatever works for you) will result in an equal amount of time once they return before work resumes on their project, allowing you to reallocate resources back into their project. In other words, you establish the standard that if they're gone for, say, two weeks, you'll be able to resume work on their project within two weeks after their return. Now, you might be able to resume work sooner, but that would be your option rather than a requirement, and you'll be insulated from potentially problematic ASAP requests.
One way to help prevent lapses of client participation in your projects is to explain in pre-bid discussions—backed up by language in your contracts—that project payment milestones, regardless of client delays, shall remain as initially scheduled. Moreover, lack of timely payment will halt your work. So no matter how unresponsive your clients might be, they're contractually obligated to render payments at fixed dates. In this way you can protect yourself against much of the damage caused by clients dragging their feet.
Problem: Browser based scope creep. “What do you mean IE has different versions?!”
This one's easy and, like everything else in professional project conduct, it's all on you. Your contracts should express specifics with regard to which browsers and versions your work will account for. If they don't, you're deliberately inviting such problems. Of course, browser compatibility is a scope issue, so it's something you should responsibly cover in pre-bid discussions. Once those parameters have been established in your contracts and the contract signed, any additional compatibility requirements will constitute additional scope, time, and cost that your client must bear.
Stakeholder committees are appropriate only within a narrow and specific context in design projects: as advisors and information experts, and never as decision makers. No design professional should accept a project wherein a committee—even if the committee is composed of 2 people—will have approval authority over any single element of the project.
Your job in pre-bid discussion (or that of the one conducting pre-bid discussion) is to, among other things, establish standards and expectations. Directly ask potential clients “who will be involved in the project and who will have ultimate authority?” Then convey your requirement that only one individual have approval authority. Your potential client will either meet this requirement or they will not, but that result dictates whether or not you should accept the project.
If you take on a project where you know that the ultimate authority for a part, parts, or the entire project is more than one person, you will have earned consequences of your decision.
Problem: Phantom stakeholders
To prevent phantom stakeholders, you should take the compulsory step in pre-bid discussions to express a simple standard: you require that anyone who will have any input into or affect on the project be involved from start to finish, participating in all of the significant steps (discovery, design presentations, etc…). Moreover, couple this with another requirement: that a single individual on the client's side must be designated to have final authority for approvals. Not two people and not a committee; one single individual. Voila! No phantom stakeholders.
If, by the way, your client introduces phantom stakeholders anyway, you're contractually protected from the disruption. This means that you can deal with that situation as you decide (end the project, add more cost and time to the now-increased scope, etc…) as best suits the situation as as is best for the project's success.
* * *
I trust you've noticed a couple of common threads through all of this.
Yes, there are specifics that need to be covered and there are contextual issues to consider, but the lesson you must take from these cases is this: you can solve almost all of your common project problems with competent pre-bid discussions and contractual references to your requirements and standards. Those two professional practices will prevent almost all of the unpleasantness designers commonly encounter in projects.Discuss
Back to the top