Wednesday, October 19, 2005

BE afraid...advertising nonsense

A few weeks ago, I read a scintillating article (which I have unfortunately no record of) with an advertising guru, where he spelled out the lazy archetypes of advertising - the only one of which I can remember is the "literal metaphor" of which the Guiness Fish on a Bicycle ("a woman needs a man like a fish needs a bicycle") is an example.

Last night I was reminded of another lazy archetype that was not mentioned in the article; crossing London Bridge Station, I saw the new poster for "Billy Elliot" which used his initials to spell out a series of "BE" statements (I can't remember which, but I don't think "BE annoyed" was one of them!). This is lazy advertising at its worst in my opinion: there are so many companies (including one for which I used to work) with "BE" initials who go down this unimaginative, uninspiring path. It always reminds me of the Birthday card (which apparently draws on a quote from Kurt Vonnegut):

"To be is to do"--Socrates.

"To do is to be"--Jean-Paul Sartre.

"Do be do be do"--Frank Sinatra.

I can only remember "be afraid, be very afraid" ("The Fly") ever striking me as a good piece of "BE" marketing, and you'll notice that the initials of "The Fly" are not - by chance - "BE". Does anyone else have any pet peeves on this front?

Technorati tags: | |

Comments Spam

Owing to the large volume of comments spam I am receiving at the moment, I have switched some options to restrict comment posting to "registered users". If you have a valid comment, and are unable to post using the comments, send me an email instead and I'll maybe put it on the site as a posting.

Wednesday, October 05, 2005

Mitigating Development Risks

I am involved in a project at the moment, where we are looking to develop an online application using (for us) a new technology. The company has an outsourced technical team (not first-language English speakers) who will be doing the development, but none of them have experience of this technology.

I've been looking at mitigating the experience risk by getting them trained up, ensuring that they have the tools to practice with the development environment (and budgeting in some time to do so), and making sure that they may have access to some expert resource during development, but I am not entirely happy that the risk is completely under control. Does anyone have any other suggestions for reducing this kind of risk(s)? And, yes, I have looked at the avoiding it all together option!

Technorati tags: | | | |