This final chapter deals with walking clients through the Drupal process. It collects what Iâve learned over years of running a studio and dealing with clients, and also touches on how to collect what you learn over the course of your projects, so that the next one is always just a little bit easier.
Over the years, Iâve learned to break the discovery process into two distinct phases. The first, outlined here, happens prior to estimating the project, and gives me the background I need to create a proposal and estimate for the project. The second, more comprehensive phase happens during and after the project kickoff. This phase, described in Chapter 2, is where we start framing the design challenge that weâre facing, fleshing out the user experience, and making sure that the client is on board with our approach.
The initial discovery phase should give you enough information about the client, the projectâs goals and the level of complexity that you can put together an accurate proposal. During this phase, youâre looking to learn:
Who is the client?
How well do they know the business, and themselves?
Who are they trying to reach?
Whatâs the real goal here? What are they hoping their site will accomplish for them?
What kind of functionality are they going to need? Is it something you can handle on your own, or will you need to bring in external resources?
Whatâs the process for decision making within the organization? Are we dealing one-on-one with the main decision maker, or does everything have to go through one or more layers of red tape before it can be approved?
What kind of content are we working with? Do they have examples to show? How many pages, sections, etc.? How do they expect people to access or organize the content?
How big is their budget?
How open are they to your ideas and approach? What âvibeâ do you get from them?
All of these questions should help you get a sense of what itâs going to be like to work with the client, and whether youâll be able to create a productive working relationship. During initial conversations with potential clients, I often start putting answers to these questions in a standard Project Brief (available in Appendix A, at the end of this guide), that will get fleshed out in the project kickoff meeting as the beginning of the Discovery phase. Iâve also included it as a download from my website for potential clients to fill out before we estimate projects. While it doesnât replace an initial phone call, itâs very good at helping weed out clients who may be more interested in price-shopping than in hiring a serious design team.
The question of how to charge for Drupal is a sticky one. On one hand, most significant web projects will carry with them a level of uncertainty that makes an hourly rate attractive. What happens when the client needs extra changes? What happens when a certain functional problem is trickier to solve than you had accounted for, and you end up spending twice as many hours as you had intended? All of these are very valid reasons to charge hourly for your work, and many developers I know have no problem getting clients to agree to hourly billing.
That said, many clients (and designers) prefer a fixed-bid approach. Clients often equate the hourly approach with a ticking clock that must be shut off before things get too expensive, and that often means that quality gets sacrificed in the name of doing things quickly. Iâve especially seen this in consulting work. For example, working with a client to reposition their brand can require anywhere from 20â100 hours of time to really see results; however, many clients working with an hourly rate will cut the process off as early as 6 hours in, afraid of getting a huge bill at the end of our work together. As a result, the client doesnât get the results they were hoping for, and they often feel that they wasted their money.
Using a fixed-bid approach attaches a very real and specific value to your work that clients have an easier time dealing with. It also helps with creating consistent income and cash flow; if, during the process of learning Drupal, you find yourself building websites much more quickly than you used to, a fixed bid allows you to charge the same (or higher) than you used to when you were still learning the ropes.
The trick, I have found, to working with fixed bid pricing is the following:
Keep very detailed time records. Over time, youâll start to realize how long things actually take to build.
Have a contract that specifically states what clients will get from you. In estimates, I always account for up to three iterations of a siteâs look and feel, with one opportunity to completely redesign it. Anything above and beyond that becomes a change order, and results in hourly charges.
Work with clients to establish payment schedules. With smaller clients, I tend to take an initial deposit, and then break the rest of the balance into monthly installments, regardless of when the project is finished. This helps me plan cash flow, while giving the client a chance to budget for the work. Other designers prefer a milestone-based approach, with one installment due upon approval of designs, and another due at the end of the project. Both approaches carry certain risks. With the monthly billing approach, you get paid sooner and more regularly, but it can be harder to define where, exactly, a project ends. With the milestone-based billing approach, you risk running into a negative cash-flow situation at any point where the project runs into delays. And believe me, it will run into delays.
Ultimately, whether you work hourly or fixed bid, you still have to be able to give the client an approximate idea of what their job will cost, and how long it will take to complete. The best process Iâve seen for estimating Drupal projects comes from CivicActions in San Francisco; their Estimating Spreadsheet[5] is a brilliant way to break up the individual pieces of a Drupal project by hours needed for specific team members. For working with distributed teams, I find translating the spreadsheet into a Google Doc offers a great way to collaboratively come up with numbers for a proposal.
Once youâve collected the initial discovery, and estimated what resources youâll need and how much the project will take to build, itâs time to craft a proposal. At a minimum, a good proposal should include:
Your initial assessment of the goals, audience and objectives of the project, based on your discovery sessions with the client.
A statement of work that describes what youâll deliver to the client. This should include a number of original concepts youâll deliver, as well as how many rounds of revisions included in the budget. It should also include a list of deliverables youâll need from the client in order to proceed, and a note about what happens if theyâre late on their deliverables.
Estimated prices for the project youâre discussing. Many teams like to give a low and a high bid, with the note that pricing is based on the information you have on hand, and that new information, such as additional stakeholders or new content that wasnât discussed up front, may push the project into the upper price range.
Any terms and conditions that apply to the project. This should include things like a schedule, what happens if you or the client decide to cancel the project, and how youâll deal with issues such as delays or new information.
In addition to these things, some teams find it helpful to include:
An overview of the design and development process, which gives the client an idea of what to expect.
Case studies or images of previous design work done for other clients.
A more detailed scope of work, which would include Drupal-level deliverables, such as custom page templates or content types included in the estimated cost. Include this information with caution; not all clients understand âDrupalSpeakâ¢,â and it could cause confusion.
Bios of team members, and other information about the company.
In my own work with clients, I use two proposal formats. For larger projects, especially ones where I have to put together a team for the project, I use a proposal format adapted from Chicago design firm Rogue Elementâs proposals[6]. The format has the benefit of being both concise and comprehensive, and itâs easily adaptable to any studioâs needs.
For shorter projects, I use an amended proposal, or Work Agreement, that includes just the first set of information above. I use this format for smaller projects (for example, budgets around $5k or less), or for repeat clients. For new clients, I may also include a bit of information about the studio and a list of previous design work.
A sample of both the proposal and Work Agreement is available in Appendix A. The content is unique to my studio and the client involved, but the format is free for you to adapt as you need to.
There comes a time in every Drupal project where you are going to have to say ânoâ to something your client wants. This could happen for a number of reasons. Your client could have seen an amazing widget on somebody elseâs site and feels that they MUST have it on theirs. Or they decide all of a sudden that what they really need to âengage their communityâ is a full set of social media tools that customers can use directly through their site. No matter what the reason is, youâve already set the scope for the project, youâre probably already worried about meeting the deadlines you have, and you need to find a way to diffuse this situation without losing your patience or the client.
There are a few things to remember when this happens to you.
Most of the time, the client will actually have a very good reason for making this suggestion.
Just because something canât be part of the site now doesnât mean it canât ever be; in fact, often these types of conversations lead to future enhancements down the line.
What the client needs from you is to know that theyâve been heard, and to know what youâre going to do about it.
This is why itâs so essential to have up-front documentation that clearly describes the technical and design scope of the project, user objectives and business goals. The documentation wonât prevent these ideas from cropping up; what it will do is give you a foundation for the conversation you need to have with the client when they do.
For example, letâs say that you contracted with the client to build a simple, mostly promotional site with an events listing, news page, blog and contact form. Youâve gotten through the discovery phase and have already started theming and approving designs, when the client realizes that sheâd really love to add some interaction to the mix. Sheâs seen other companies that have forums where users hang out, converse and help each other. Sheâs heard that Drupal âmakes it easyâ to add forums to a website, and she wants to implement it straightaway.
First, does Drupal actually âmake it easyâ to add a forum to your site? Technically, yes. Forums are part of Drupalâs core functionality, and you can enable the forum simply by clicking a button on the Modules page. However, enabling the forum is just a tiny piece of whatâs actually involved in creating a forum. You have to figure out where it belongs in the siteâs architecture, decide who has access and who doesnât, set up the appropriate permissions, and style it to mesh with the look and feel of the rest of the site. Also, the client will have to promote the forums, create categories for forum topics, get people actually using them, and monitor them consistently for trolls and spammers. What we think of as âeasyâ at first glance rarely is once weâre in the process of making it happen.
There are several ways to approach the challenge of pushing back, most of which will at some point involve referring the client back to the documentation you created at the beginning of your project. My personal approach is to say, âGreat idea! Let me ask just a few questions to figure out how this can work...â This assures the client that youâre listening to them, but also helps them talk through the business logic behind the request, and understand all that actually goes into making their request happen. Often, this approach will either talk them out of the idea completely or put it in the works for the next iteration of the site. Either response is a good resolution.
To elaborate on this example, any of the following questions could work with most reasonable clients, depending on where you are in the project plan:
âA forum could be great! How were you planning on promoting it? Do you have resources to monitor it for spammers and trolls?â
âI like that idea, but one of our business objectives was to focus on the organizationâs human-friendly approach to customer service. A user forum might give the impression that you prefer your customers to handle issues among themselves. What do you expect the user will gain from the forum?â
âThat sounds like a great idea, but right now, our push is to get the basic functionality into the site before launch on Tuesday. Do you want to have a discussion about adding it to the next iteration of the site? Iâll work up some estimates on what it would cost.â
There are a few things to note about this approach. First, clients really love it when you tell them theyâve had a great idea. Second, youâre making it clear that although the idea is good, they have to be prepared to do some work to make it happen.
Third, and this is the really important part: youâre not pointing to a specific document and saying âif you remember the piece of paper you signed...â
In my early days of working with clients, I used the âthatâs not in the contractâ line frequently, and it never ever worked. Something about referring people back to legal agreements sets up the conversation to be combative; the client ends up perceiving that youâre trying to pick a fight with them. Referring to themes that youâd agreed on in the course of discovery shows the client that youâre interested to see how this new idea might work with what has already agreed upon, and you want to find a solution that works for everybody.
This process of dealing with client requests that push a project beyond the original scope has caused some teams to adopt a hybrid Agile approach to Drupal projects. While the process still involves defining the scope of work and planning things out up front, design and development happen together, iteratively and collaboratively. This helps teams keep everyone on track while accounting for the inevitable bumps in the road that come with designing for Drupal. Says Four Kitchensâ Todd Nienkerk of their Agile process:
We rarely say ânoâ to a client with regard to functionality, but we do explain that:
Adding something before launch means something else needs to be pushed back;
Their current budget doesnât really allow for this extra work, so letâs reprioritize or find more money, etc.
Scrum provides a very handy framework for this discussion because all ideas, regardless of how enormous or superfluous or whim-driven they may be, go into the project backlog for future discussion. Usually having it in the backlogâi.e., captured somewhere for the client to see every so oftenâis enough to make them happy and never actually push for that feature to be implemented.
Of course, this approach doesnât always work. Occasionally, you run into the type of client that I like to call âthe Dictator.â They grab ideas completely out of left field and present you with them, and youâre expected to take that idea and run with it. If you try to spin the conversation back to the scope that was agreed upon, they get hostile and say things like âthis is what I hired you to do,â or âjust make it happen.â
Or, worse, you run into the type of client that loves everything you do, gives you complete creative freedom, and gives you absolutely no direction, feedback, or restraintsâbut will come up with an idea once a week that absolutely wonât fit into the budget, and she canât understand why when you explain it to her.
When you run into these types of clients, you have to make a choice. Is it more important to preserve the client relationship, or to stand your ground and risk walking away from the project?
Iâm fortunate in my career to have grown skilled at managing âdifficultâ clients. But the most important part of this skill is knowing myself well enough to know the types of clients that I just canât work with. In my entire career, the handful of times that a project has gone sour can be directly attributed to deciding to take on a project despite the obvious conflicts between myself and the client. If youâre on a team, it can be easier; you have other team members who you can lean on when things get to be more than you can handle. If youâre working solo, or as part of a small distributed team, it can make you wonder why you got into this field in the first place.
Either way, part of managing your career is learning how to navigate difficult situations with grace. If you find yourself faced with a client who refuses to hear the word âno,â itâs on you to evaluate whether their request can be accommodated within the current budget, and to make any adjustments that need to be made, including possibly letting the client go.
Recently, I gave a brief talk on the state of designers and UXers in the typical Drupal team. During discussions after the talk, I mentioned the âProfessional Relationshipâ clause that I include in all of my Work Agreements, that establishes the working relationship I expect with clients, and states that I (or the client) can terminate the agreement if one of us isnât living up to the terms of this relationship. This statementâthat I basically told clients how I expected them to treat me, and what they could expect of me in returnâwas met with expressions of shock and curiosity by everyone in the room, most of whom were developers.
The reason I put the clause into my contracts was simple; as a self-employed designer, Iâm selling my time and energy. If that time and energy is being sapped by abusive or disrespectful clients, I need to be able to address the situation proactively in a way that protects my business and my sanity. The âProfessional Relationshipâ clause, which encompasses a few bullet points on the front page of the contract, helps clients understand that Iâm here to help themâand if they wonât respect that, they should find someone else to work with.
I put the clause into my contracts with the help of Jessica Manganello, a client, friend, and co-founder of New Leaf Legal[7], a terrific team of entrepreneurial lawyers in the Boston area. She and I got together to look at my contracts after a particularly nasty situation with a client who turned abusive after ignoring his project for over a year. Although he had clearly breached his end of the contract, I had also set up my initial contract, which was cobbled together from sample contracts I got from a copy of Legal Forms for Graphic Designers (Allworth Press) and the AIGAâs website[8], with no way for me to get out of a project that wasnât working out. Establishing the clause helped me make it extra clear to clients that I meant business, and Iâve yet to meet the client who refused to sign as a result of the clause.
If you want to consider adding the clause to your contracts, you can find it in my sample Work Agreement in Appendix A. If you want a contract that fully covers all your bases and makes sure that youâre covered for anything, give Jess at New Leaf a call.
[5] available as an OpenOffice download here: http://civicactions.com/estimating-worksheet. It should also open in Macâs Numbers application or Microsoft Excel. Iâve also imported it as a Google Doc with some success.
[6] Which you can find in this article: http://www.howdesign.com/article/proposal/
[8] The AIGA (American Institute of Graphic Arts) is the international association of graphic designers, based in the US. http://aiga.org
Get Planning and Managing Drupal Projects now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
