Clear & Constant Communication

Along with gathering and disseminating requirements, communication is the very essence of your role, your raison d’être. Even if you have nothing to say, you should be in constant contact with the project owner, to re-assure them if nothing else, especially if they’re paying you. Doing this increases your perceived value and their sense of ownership. It’s important to always be clear about what your team is doing — remember that the project owner may not share your technical knowledge or expertise — and also to be completely honest. Even in an email it’s obvious when someone is lying or deliberately trying to withhold information, and this can seriously harm your relationship with the project owner. If something does go wrong then let them know, and reassure them by also letting them know what your team is doing to remedy the situation. Maintain the same tone. If your relationship with the project owner is friendly and informal then that’s how your communications should be. On the other hand some people may prefer more formal or succinct language.

At the very least you should be sending daily updates to your project owner and having weekly meetings during the course of the project. Even if they say this is unnecessary, it’s a point you should insist on. There is nothing worse for both them and your team than submitting a “big reveal” after a long period of silence — they will feel inclined to make changes or offer comments than require your team to go back and re-do some work or in a worst case scenario undermine their own strategic decisions. This is especially scary and frustrating when a deadline is looming just over the horizon. By setting out a communication schedule at the start and sticking to it, communicating as much or as little as required, you will be able to more easily manage their expectations.

Regular communication will also help you to understand and get to know the project owner, which will in turn build confidence. At some point you will need to be able to say “no” to them. Whether it be rejecting a feature request, revision request, a new deadline, design feedback, or when talking about costs, there are some circumstances where you or your team know best and you will need to assert yourselves. It’s much easier, especially in your role, to be the salesperson with the positive, can-do attitude, always agreeing to every request. Sometimes, however, it’s just not a good idea. You can’t say “no” directly. Nobody wants to hear that from someone they’ve asked, even paid, to do something. Of course, when faced with such a situation, a good web professional would understand the business driver and suggest alternative solutions that convey the same message and achieve the same goal but that are unique, original and creative. The best approach here is to say “yes” and explain the consequences, or say “no” but at the very least offer a viable alternative solution. This is where your confidence will come in handy — you need to be able to convince the project owner to drop their request or to go with your recommendation, so it’s important that you’re speaking their language and talking in terms of benefits to their business. This may sound like coercion, but really it’s a form of honesty and will draw more respect from a project owner than agreeing to everything and then delivering something late or of poor quality or that fails to meet their expectations. Furthermore, having a project with a bunch of patches and hacks for every complaint or spurious request usually ends up being hard to iterate on and maintain .

If your communication thus far has been professional and you’ve established yourself as the expert then you should be able to convince the project owner to go with your recommendations. If necessary, don’t shy away from citing industry experts. If however you really have to admit defeat then take it as an opportunity by suggesting installing some analytics tracking or A/B testing to assess the success of the decision. Once you have hard data to backup a decision you’ll know the best way to deliver return on investment. You never know, the project owner’s decision may even be the right one.

Communication isn’t just phone calls, video chats, emails, instant messenger dialogs, and meetings either. Documentation should be provided at every stage along with all deliverables. Sometimes for instance you may discuss strategic decisions over the phone, but unless such conversations are documented then it will be difficult to reference them later. That doesn’t necessarily mean you need to make a transcript of every phone call, but you’ll want to at least follow up quickly with an email covering any important points. Before arranging communication, you do need to consider the best method for different situations. When handing off deliverables for example, be it mockups, prototypes, or even code, is there accompanying information to help the project owner and their team to fully understand the decisions made about how and why you’ve done it the way you have? If not then be prepared for long e-mail threads that only really serve to waste everyone’s time. Insist on thorough documentation from your team and make sure they are aware of the requirements when planning schedules. They should bear in mind who, on the project owner’s side, the documentation is aimed at, and you should check this before delivering. It’s no good writing technical documentation for a non-technical project owner. You’ll also need to consider how the documentation is going to be received or presented. If it’s something you may need to discuss in a meeting then maybe it should be in the form of a presentation. If it can be shared and read individually then a PDF may be more appropriate. If you need to give a presentation to a team of people in different physical locations then you might consider a video. Compiling documentation takes time and certainly isn’t easy, but it’s an essential part of the 2-way communication that your role entails.