One of the most enjoyable presentations at the recent Btween09 conference in Liverpool was from Jon Drori on how to botch relationships between big (government / public body) entities and small businesses (independent social media agencies perhaps?). Jon is, amongst many other things, the former Head of Commissioning for BBC Online and with the Government’s DCMS as Director of Culture Online – a programme to bring culture and the Arts to new audiences. So he knows of what he speaks, having seen many a blossoming relationship successfully botched by any number of these methods. As a small independent entity who is almost always dealing with large entities it was salutary advice. And along with the rest of the audience I especially enjoyed seeing my own experiences (and mistakes) revealed in all of their naive glory.
To get the full impact you need to take a look at the original, which I am told will soon be available in the archive on the btween site. However for your short term elucidation I’ve included some of the ones that really stung me with their relevance; you can check my CV to see where they are most likely to have occured.
I should also add that Jon presented these not as I’ve written them; as things to avoid a botched relationship, but as their inverse; as things to ensure botching. His approach works much better as a comedic device, but not so much as a top tips for building better relationships with large organisations. I’ve gone for utility over hilarity (sorry).These pointers are from the point of view of what the small entities need to remember when engaging with the large. What is partilarly refreshing about this list, apart for the moments of recognition (yeah! I’ve botched exactly that!) is that these are all things that the small entity can actually take on board and do something about. I think often the issue with the large / small relationships is the lack of self determination that the smaller entities feel. All of these tips are things that we can do ourselves and from my experience at least, would have a huge benefit.
- “Understand the decision making process and the decision makers” Work out who is responsible at what stage and what process they go through internally to make decisions and the criteria they use.
- “Don’t try to go all the way on the first date; for example asking for money in first meeting.” I particularly recognised this. As a feisty start-up we have little patience for the lengthy courting period required by large clients and often walk away from first dates feeling (hopefully erroneously) jilted. We’d do well to remember John Cleese; “What’s wrong with a kiss, boy? Hm? Why not start her off with a nice kiss? You don’t have to go leaping straight for the clitoris like a bull at a gate.” Indeed.
- “Engage at all levels on both sides, don’t limit your exposure and understanding to the top echelons alone.”
- “Don’t use irritating buzz words and jargon.” At least one of the presenters at btween09 could have taken this on board. My back teeth are still sore from gritting my way through a solipsistic undergraduate’s attempt at an art theory description of what what may have been a really good idea, if you could actually see it through all of the bullshit.
- “If you are going to support particular aims of the larger organsiation, show evidence of doing this.” While this may not both the first engagement, it’ll come close to guaranteeing that the second engagement never occurs. Put it in the project plan.
- “When asking for assistance, be very clear and specific about what you need help with.” They’ve bought you on board because they think there’s some value you can add, so really really they do want to help you to achieve your goals, but they can’t if you don’t ask for clear and specific assistance. To avoid the risk of being pesky I think we often avoid asking clients for the help they’re usually (or should be) delighted to provide.
- “Use appropriate levels of detail.” I think as smaller organisations we suffer from an inferiority complex. We want to compensate for this by showing off every bit of the clever work we’ve done. Note to self; Make strategic use of the appendix. Also worth thinking about how we present that detail; think diagrams, charts and illustrations, picture worth a 1,000 words etc.
- “Give your partners tools to explain what it is that you are doing.” Which seems to me to be a logical extension of the point above; charts and diagrams that summarise what we’re doing are going to help both our immediate client understand what we’ve done and help them to explain it internally.
- “Explain what you have to stop if you are going to meet a different / new requirements.” A tendency to want to please-at-all-costs often means that scope creep isn’t resisted with any real vigour. As a result increasing amounts of reasonable work gets requested, and without any (polite and reasoned) push back it can quickly become unreasonable.
- “Look at tech early on.” Some legacy technologies are just not compatible with some of the more recent applications and processes (at least not without a lot of time and effort being invested on someones part) and the sooner these are exposed and solutions scoped, the better for all.
- “Identify risks ahead of time and how we’re going to deal with them.” I think this is just a useful extension the above point; the risks are not just in the technology, they sit in every layer and need to be acknowledged.
- “Don’t misjudge the knowledge of your audience by patronising”, that is to say talking down to them. The same btween09 speaker could ave taken this on board; once you’ve been patronised, its very hard to bring your attention back to the actual content.
- “Don’t reinforce prejudices.” Jon’s example of this was academics turning up in tweed coats with elbow patches, but the same could be said of independent agencies turning up in all black with last nights nightclub on their breath. I think there is a balance to be reached here between being understanding what it is that is unique to you that has resulted in your being engaged and recognising what is an unhelpful (cliched) by-product of that?
One of the things that didn’t appear on Jon’s list but that is worth considering in the planning stahges is; activly plan for unplanned disagreements and their resolution. Thsi is differnet to risk idntification and mitigation. It is more than likely there are going to be roadblocks, a few hiccups and perhaps the odd barney; that’s the nature of large complex projects, so plan for them and allow for time, budget and steps in the process to stop, review and resolve. I had a great conversation with Andy Wilson at L-Shift a few months ago about developing specific review and arbitrartion stages in the project cycle of agile development projects and providing an independent third party service for delivering this arbitaration process. Kind of a UN negotiation team for large tech projects to ensure that the disagreements are exposed early / regularly and dealt with. Its particularly relevant for first time agile deployemnt, but I suspect all processes could; benefit from some kind of ‘review and resolve’ stage.
