Tips for Managing Even Your Toughest Client Expectations
Building and launching a Drupal site from the ground up can sometimes feel like piecing a spaceship and a launchpad together. To your client, it definitely feels that way. What is even harder is managing your client’s expectation of a three-tier, 16-engine, fully tricked out rocketship… on a $30k budget.
Before we start our spaceship endeavors, try to keep a few basic things in mind:
- A big part of this story is bringing your client with you for the ride – rather than taking them on a ride
- I always assume (to start) that everyone on the team has zero web building experience and will be working from the ground up. Leave no details behind, no term unexplained. The best I can do is start slow (for those who feel traumatized by my Drupal-ese) then speed up and/or take technical explanations offline for an advanced audience. This is a great way to build rapport with a client team of varying technical backgrounds.
With that in mind, here are my tips:
1. Plan carefully and consider various scenarios.
The key to any successful site build is a good plan. Even some of the most logistical planners I know won’t be able to predict every future scenario. However, coming up with a few possibilities and scenarios will demonstrate thorough thinking and considerations for the project and/or any problems you may face. Be sure to include your technical team in the planning. What your client may downplay or even dismiss may be a huge black hole in the eyes of your team. Are there meteors in space? Big or small? Yes. Then we should probably go ahead and put additional boosters on the back, extra fuel in the cargo, and “frikkin lasers” on the hull.
2. Be transparent from the beginning.
Most clients do not need (or want) a play-by-play and every reason behind why each feature is built the way it is… but be sure to explain any calculated risks for potential problems. Have a plan or idea of what may happen should you bump into one of these meteors along the way. Is there an alternative route? If the meteors are too big to go around, should we spend a little more time beefing up our laser systems versus adding more boosters? It is very easy to want to appease a client and hyper focus on the “want list,” but it is even easier to overlook critical foundational components. If your client’s “want list” is exceptionally long, prioritize with the necessary components and build from there. Yes, we want the rocketship to go very fast and look very cool – but we won’t be going anywhere if don’t save enough power to blast through the meteors in the first place.
3. Listen up and anticipate needs.
I find that in my first client meeting, I like to sit and listen. If I am asked a question, I will usually repeat back what the client is asking and rephrase it. This helps me in two ways: 1) It lets me talk through and understand the question, and 2) It lets the client hear my thought processes and ensure that I am interpreting their requests correctly. I usually call this part “translation” where I am taking non-technical requirements and attempting to anticipate Drupal needs.
For example, A client will tell me that they have a hard time keeping track of all inquiries coming through a single web form. They then ask me to build a web form where based on user selection, will route requests to very specific emails/contacts. In return it is my job to:
- Get as many requirements for necessary fields
- Consider if any of the fields should authenticate (by email, zip code, etc.)
- Determine which inquiries are routed where
- Determine what the output of those emails should look like
- Spam protection
At this point it’s not critical to get client input on whether we use Webform 3.0 or 4.0 (we would actually use 4.0 if you need to know what we picked). It's not imperative that they know that we decided Captcha is more affective than Botcha for spam capture. But it is important to anticipate needs -- such as letting the client know that changing fields after a site has launched will result in lost data.
4. Constant communication and feedback.
This one is more common-sense. Clients do not want to feel railroaded with decisions, but they also don’t want to be left in the dark. The client has hired you to be their “Internet Sherpa” and while it is important that you assert your experiences and best-practice recommendations, it is also incredibly important to seek feedback early and often. I often find that some of my best client-customer relationships are ones that feel more like a partnership rather than a one-way street. While the client may never feel the pains of testing hooks and API callbacks, it is still important to listen to how they feel things are going. This will help build open lines of communication, and establish that they can come to you with their needs and feel taken care of. No one wants to find out that their spaceship was built with 16 rockets and no portholes. Why go to space if we can't look outside and enjoy the view? While the developers we might not have focused on the portholes as a "necessity", it is still a feature that allows the user to enjoy the product.
These are just a few examples drawn from my own experiences and I hope that they provide useful insight whether you are just getting into the field of client/customer management or looking for some helpful tips for better client relationships.
