Monthly Archives: January 2011

Audience Reaction?

I’m a bit slow on the up take on this one but …

I was talking to a radio presenter on Friday about getting a business related slot on his station and the conversation turned to the topic of customer care. I made the point that where many businesses go wrong is that they concentrate on what is important to them rather than to the customer.

He asked me for an example and here is what I came up with:

Did you see Ricky Gervais presenting the Golden Globe Awards and see how flat the reception to his jokes was? He obviously thought he was being hilarious but the audience was on a completely different wavelength. Most were impassive and some were visibly shocked. Not a good reaction.

The message here is that what you say has to resonate with the audience – it doesn’t matter how good you think your content is; it’s what the audience thinks that matters.

The same goes in customer care – it is all too easy to add bells and whistles to your product or service but if they are not what the customer wants then they won’t value them. How many products or services have you bought and found that whilst they have lots of fancy features, they fail to deliver some of the essentials?

It is incredibly easy to solve this – give your customer a good talking listening to!


Never, ever insult your customer in public or in private – others will pick up on this and think

“If they talk about that customer like that … what do they say about us?”

That’s not what I thought I was getting!

It’s a scene to send a chill down the spine of any project manager:

You are proudly showing off the asset you’ve worked for a couple of years to develop to the end-user, only to be greeted by “Oh! That’s not what I thought I was getting!”

How can this be?

What you’ve delivered meets the agreed specifications in every detail and still the customer is not satisfied!

It’s time to rewind to the development phase to understand what has gone wrong.

In many cases, the group which will use the asset is isolated from the project delivery team by a series of internal and external groups which are more focused on project delivery than the business itself. Even with effective procedures to define every aspect of the project, there is a danger that things will get lost in translation.

In most projects, there is a “one shot” transfer of end user requirements into the project team – OK it might happen a few times but fairly early on the input from the end user is scaled down. The project is then largely in the hands of “the techies” – engineers, architects, software developers etc. These groups are intent on delivering the best possible solution to the problem which has been defined in the project brief, User Requirements Specification or whatever you call it.

As the project proceeds, a plethora of new and more detailed documents, drawings, specifications, 3D Models, Schemas, Flow diagrams etc. is produced. These are intended to convey the requirements to other groups who are more and more expert in their element of the project. So they are formatted in ways that make sense to these groups.

Good project practice will ensure that these documents are circulated to the end-user who may even have responsibility for approval of the design. What is often forgotten is that the people involved are experts in something completely different: running factories, operating data centres, managing buildings etc. They are not experts in project management, design or construction, so there is a risk that they won’t be able to interpret the documents well enough to make informed decisions on the suitability of what is being proposed. They may also be overwhelmed by the quantity of information and miss what is important to them.

Knowing this, it should come as no surprise that from time to time what is delivered is not what was expected.

So, what can you do about this?

  1. Think about it from their perspective – what do they know about and what are they interested in?
  2. Think about the types of document are they used to seeing and aim to produce documents, mock-ups, prototype screen displays, sample reports in formats that will make sense to them, even if this means extra work. Take them to see examples of what you are proposing, they may not be able to visualise what you are proposing from the design documents.
  3. Be very careful in selecting the documents you want them to approve – don’t overburden them with detail they don’t need, aren’t interested in or don’t have the skills or knowledge to assess.
  4. Aim for a dialogue which allows a two-way flow of information throughout the project process.
  5. Most importantly, treat them as what they are – your customer, so be customer focused.

In short, put as much effort into describing the “asset” to its end users / future owners in terms they will understand as you put into describing to the implementers in terms they understand.