It’s your problem.
Does any of the following sound familiar?
That’s not what was discussed during the meeting.
Well that’s not what the terms and conditions say.
It was in the spec/requirements document.
These are the kind of statements you’ll hear thrown around when a client’s (or manager/senior’s) expectation hasn’t been met. Be that a feature not working how they wanted, a design they want to change, an expectation of support long after a project has concluded or many other seemingly unreasonable requests you might find yourself on the receiving end of.
The thing is, even if all of the above statements are true and you can prove you’re right and they’re wrong, if you’re dependant on them for your income, this is still your problem to deal with. And you have to do so extremely carefully.
Being “right” and being able to prove it is not the point here. Even though you may have all of the above arguments to deploy, you’ve still failed to realise that your client hasn’t actually absorbed the information presented to them. Now you’re in the situation where you have to tell them they are wrong and no matter how obvious that might be, their emotions are going to register somewhere along a scale that includes embarrassed, let down, disappointed or angry. In fact embarrassed is the best case scenario, and that’s still not good.
That’s not to say you should simply roll over to each and every request no matter how unreasonable. You should certainly not expose yourself to unnecessary risk, but what’s important is that you take responsibility for being aware of what your clients expectations might be throughout an engagement. It’s down to you to make best efforts to ensure their expectations are aligned with what you’re going to deliver. Generally, having a point loosely mentioned in legalese as part of your lengthy terms of business isn’t going to be enough.
Chances are, your client is busy and largely leaving the details of a project down to you and your team. They may even be overwhelmed and out of their depth (which is why you’ve been recruited in the first place) so are waiting until the end result to pass judgement. If you suspect there’s even the slightest chance they might be overlooking something that would benefit from more thorough acknowledgement, make it more explicit to them.
“I just wanted to make absolutely sure you’re aware, as highlighted in ticket #12345, if we do make that change we will save time now but there will be an impact on performance down the line. We can of course address that at the time but that won’t be covered in the current budget. Let me know if you’re happy to proceed still or if you’d like to discuss further?”
This is a conversation much better had up front (with the most appropriate person) than “down the line” when your client is yelling down the phone for you to fix the issue as a matter of urgency. By making an explicit point of it instead of leaving it to a conversation buried in comments on a discussion with a lower level member of the client team, you give them the opportunity to acknowledge the issue and ask any questions and potentially even work out a better solution with you.
Of course it’s not always viable and there will always be cases that you cant predict, but being mindful of this can go a long way to maintaining healthy relationships and reducing stress for all involved.
We’ve found being very open and transparent with our clients helps with this. Even going as far as offering access to source code, task tracking systems and direct access to the project team via slack throughout a project. Whilst this offers very granular access to our work and lots of transparency, they do still rely on the client having the time and inclination to review these tools. So as well, we make a point of raising particularly important issues and highlighting any relevant discussions even if that means picking up the phone or a face to face catch up.
Feel free to pester me on Twitter if you have any thoughts or questions.
#adventblogging post 7 of 24 see the rest.