Categories
octaneinteractive
Octane667
octaneinteractive
ForbesBingley
« Blah, Blah! Technology: trends, opinion and commentary — 5 technology disasters, horrors and tragedies »
The value of business knowledge
Tuesday, 30 October 2007 — by Wayne Smallman
Adults don’t just pop into existence, fully educated and well heeled. The same applies to businesses — things need to be learned along the way. However, the expectations of clients can be that the knowledge we apply to their projects is old, tried and fully tested. But it’s sometimes borrowed and totally new…
Sometimes, as designers and developers, we’re learning on our client’s time. But that’s not a bad thing, nor is it unusual or wrong — we can’t know everything there is to know.
Client expectations of our business knowledge
Problem is, the expectations of our clients are such that 1. they sometimes resent the discovery process, as if we should already know these things, and 2. fail to see that the discovery process aspect of a project is not just essential, but billable, too.
To be fair, let’s just look at things through the eyes of the client for a second, shall we? First of all, setting aside issues of copyright, IPR’s (Intellectual Property Rights) contracts and such, most clients would feel that whatever we learn on their time and their money should only be used on their projects and nowhere else.
After all, they can’t be expected to be the unofficial R&D lab’ for our other clients, some of which are possibly their competitors.
As much as anything else, the client wants / needs to trust our judgment. And if they then see that we’re researching or experimenting with ideas, concepts and methods, what signals are we sending out to them? Mixed, I should imagine.
In fact, I know we’re sending out mixed signals. But the thing is — and I know this is going to sound cliché and trite — we’re students of life and simultaneously apprentices of our professions, too.
There have been many occasions when I’ve taken on a project whose constituent parts exist only as grey areas in my mind, right up until the point where I begin to do the actual work.
This might sound weird to some people, but if it’s a PHP or a creative design issue, I’m rarely vexed; it’s more a question of time and the amount thereof.
The value of our time to our clients
But then the client’s expectations can be quite different, too. Sometimes their opinion of what we’re doing for them is that our job is easy — it’s just computer stuff!
Yeah well, we might make this computer stuff look easy simply by being sat on our arses much of the time, but the mental manual labour and heavy lifting is very much underway in our heads.
It’s during these times that the perception of our success can be skewed somewhat. So some education is in order, and here’s your chance to bring your clients up to speed with what your job entails by inviting them to the office. Let them sit with you and learn first hand the time it takes to turn Widget A from blue to red.
My feeling is that most of the perceived “us & them” client versus supplier arguments that emerge are almost entirely borne out of ignorance.
Talk to your clients, ask them what they think, what they feel. Allay their fears with a little light education and you too could prevent Project X taking on a life of its very own, devouring your time, and consuming all of the good-will currency you’ve banked with your clients in the process…
Recommended reading
- The perception of business success
- Run a business? Invite a client to the office
- Beware of would-be psychic clients and mutant projects
« Blah, Blah! Technology: trends, opinion and commentary — 5 technology disasters, horrors and tragedies »
This is a fantastic point, especially for clients who want something that stands out or pushes the envelope. I believe often we need to spend more time educating our clients on what it is we do for them, and why it does take so long to make “simple” changes sometimes. This of course leads into a conversation about how to make sure the client has thought through their needs BEFORE a line of code goes down to minimize those sorts of changes, and if anyone has tips on that I’d love to hear them!