Nobody really likes planning. Plans are bad in the eyes of many people, seen as a necessary evil by others and some people would rather just jump straight in and figure things out as they go along. However, if you approach them the right way, planning can provide more than just a set of deadlines. Specifically I’m talking about the type of Information Plan that is covered in Managing your Documentation Projects.

In that respect, plans are good. They help set the direction and make sure everyone knows what they need to do to get there.

Yup, plans are good. The creation of a plan usually drives discussion around the deliverables and the audience of the information.

It goes without saying then, and I’m sure you all agree that, and this is just in case you’ve missed my point, plans are good.

Unless you don’t revisit the plan throughout the project. At that point, through no fault of the plan, the plan is useless.

It’s very very easy to get sucked into the detail of your current work, understanding how to explain to users how Widget X works if you are running Component Y, and I’m as guilty of that as the next person. Revisiting your plan throughout the project will help keep you from losing sight of the woods for all those damn trees.

Having had a few days to process my thoughts about the Technical Communications Conference I can confidently say that it is the best professional conference I have ever attended.

I’ll post up specific notes tomorrow, but I wanted to touch on some of the themes that seemed to be driven out of most of the presentations I attended. Now at this point I should make a confession, it’s about the presentation I gave on the Thursday morning (the second day) of the conference.

My presentation had a theme, a single word that I was focussing on, so throughout the first day, in all the sessions I attended, I was listening out for that word. That word didn’t appear in one session, and I had to push to get the word out of another of the speakers (the last of the first day).

I claimed that word appeared in all of the sessions I attended, it didn’t. Now, as far as confessions go, it’s not exactly earth shattering news but it’s important to me that I let you all know because, as I said in my presentation, if you are blogging you need to be honest.

The word I was looking for throughout the first day was “conversation”, and I was pleasantly surprised when I heard it crop up in the later sessions of the second day and I admit I was quite pleased when the closing speaker, RJ Jacquez from Adobe both mentioned my presentation and had a similar view to mine.

As for the sessions I attended, I don’t think there was one where I didn’t learn anything, even though there were a couple where I was asked to facilitate when I probably would’ve ducked out to chat to some vendors. It’s good that the speakers, whether well versed in public speaking or complete amateurs (like me), seemed comfortable and relaxed and really engaged with their audience.

And that for me is a good way to sum up the entire conference. I shudder to think just how much hard work went into organising the conference but from the smaller touches (the goodies in the hotel room), to the softer, informal approach that Paul and Rachel embody so well, really made a difference.

Given that our profession is both broad and deep, it was great to have other aspects around the fringes covered as well (cognitive psychology anyone?). All in all I think there was something for everyone, and the benefits of being exposed to other niche areas really made the conference worthwhile.

If you are in the UK next year, if you work in a profession either directly related to, or relatively related to, technical communications then I’d urge you to consider coming along next year. For me the best thing I’ll take away from the conference is the continuing conversation that is happening about our profession.

* #tcuk09 was the hashtag for the conference

It’s funny how these things come together sometimes, when two separate discussions, one here in the office and the other in the Author-it Forums, nicely lead me to a conclusion on something I’ve been pondering recently. How to measure what we produce?

The first discussion was with a new guy in our team, who was voicing concerns about the amount of information he was producing. He stated that, when describing some of the concepts our product uses, he would spend a lot of time figuring them out, talking to people about them and understanding them, but that usually translated into “not a lot being produced”.

I pointed out that, as far as I’m concerned, the more concise and effective the information, the better. Some things do require a lot of content, others don’t. There are additional benefits when you consider the single source aspect as well, it’s much easier to re-use a tightly focussed topic than one which tries to cover too much information.

The second discussion, in the Author-it forums, was someone asking if there was a way to track the number of words each writer was producing, apparently as a way to track productivity.

Don’t worry, plenty of people pointed out the fallacy of that line of thinking; it’s very easy to pad out a document or topic with additional words even though they might not add any value and may lead to ambiguity.

However I’m not really thinking along the lines of productivity, nor measuring the individual, I’m more concerned with measuring what we produce.

But how?

The obvious answer is to engage with our audience and get their feedback about the documentation. There are various ways of doing this, and depending on your audience some might not be available.

Arranging time to sit down with the people who use the product, and your documentation, is best and can be run as a product focussed session. If your company runs customer forums or workshops then it should be easy enough to schedule time into the agenda (your company understands how important documentation is, right?), but even if you can’t get direct access you could try a questionnaire, allowing customers to ‘score’ the documentation.

Ultimately you need to get feedback from the people who use your documentation, find out whether they can find the information they need, once they’ve found it do they understand it, is it clear, accurate, unambiguous? It’s not easy to quantify what we do at every level but using a questionnaire which includes an indication of a score can give you a way to start further discussions. The score itself isn’t the important bit, it’s what you do with the feedback that matters.

I’d love to hear if you’ve tried other ways of measuring your documentation, and I’m not alone. In the current economic climate there is more pressure to justify what we do, so making sure we have some good weapons up our sleeves will benefit us all.

I am a paper junkie. I’m a whore for a nice caliper of paper, not too thick as to be card, not too thin as to be unsubstantial. I love the feel of paper, the rustle and rigidity that give way with a subtle movement. I love the sound of ink being laid down, the gentle drag as my hand loops and dots across the page.

Despite all the advances of modern technology, I don’t see this changing. In fact I’m such a slave to this way of thinking that I’ll often print off an email if it contains important information that I’ll need at some point in the next day or so.

As such I walk around with a notebook (A4 size, hard bound, company branded) stuffed with ‘important’ sheets of information, with said sheets usually adorn with numerous, equally important, scribbles and notes.

And of course there in lies the problem. As of yet computers cannot match the speed nor convenience of pen/pencil and paper.

It is then a short leap and a step to full on stationery porn. Lusting over Moleskin notepads, gushing over the smooth flow of ink from a Mont Blanc. I’m not quite there yet. Yet.

But what of paper in our profession? The last time I was involved with a print house was over 10 years ago (blimey), and these days whilst we still produce user manuals, they are in the now ubiquitous PDF format. Information these days is largely thought of in electronic terms, yet everyone I know prefers reading novels in ‘old fashioned’ print format.

And I guess that is the problem, whilst the main thing we consume and produce is electronically focussed, many of us are still looking to paper as the medium. Which, if you are a paper junkie like me, is a good and a bad thing.

But mostly bad.

Having been off work the past week, spending most of my time sleeping on the sofa (think I’m fighting off a virus), I’ve been pondering what I do and how I do it.

And I think I’m at that point in my career when experience plays a large part and, despite any processes that are in place, I have to agree with what Donna said.

I’m making it up.

Whilst that sounds like a very glib and unprofessional statement, it is probably true for you as well. Making it up is actually quite hard to do. It presumes that you have enough knowledge about who you are creating your information for, why they need it, how they want to access it, how you are going to get it, and how best to create it.

After that, no matter how much detail you try to plan to, you will end up making decisions on a day to day basis, sometimes they might contradict the plan but, with the knowledge you have, you will probably make the right call. More times than not, at least.

Anyway, that’s as far as I got with that train of thought. I’m off for a snooze.

I’m currently pushing a business case to allow me to hire a new member for our team. The premise is that, particularly with our product set, there will always be areas of technical content that need writing but that with an additional member we can start to create other forms of content.

Which begs the question, what other forms of content can we create?

One thing I would like to get my team more involved with, both to give them a wider view of the product and to help the rest of the R&D team better understand why we build what we build, is in the creation of our Business Requirement Documents (BRDs). These documents drive the product features, setting out the requirements for the new features that we want to add for the next release cycle.

Early on in my career I remember reading (somewhere) that the technical writing team are user adovocates and that we are “the interface to the interface”. With that in mind, we need to understand both why a feature is in the product and how we expect it to be used (or at the very least, how we would like people to use it). By getting involved earlier in the product lifecycle, helping to understand and articulate the business requirements at the start of a release, we can be better placed to act in the best interests of the customer.

Being part of the team that collates and creates the BRDs will place us bang in the middle at the start of a stream of work and, by nature, we are also there at the very end, checking our documentation as the final stages of the release tweak and refine the functionality. My hope is that this end to end view of the product will help both the technical writers, and the development teams in which they are embedded.

Are you involved with early development documentation? If so I’d love to hear your thoughts on this.

I’ve mentioned before that I’ll be attending, and presenting at, the Technical Communication Conference this year, but as the programme is now full I’ve been trying to pick my way through which sessions to attend. I think I’ve got it sussed.

Wednesday

Kicking off with the keynote from Peter Anghelides (who recently re-tweeted me on Twitter!).

Session 1 – Matthew Ellison – Pattern language for information architecture
As we delve into providing more of our information online, understanding how best to structure the information is key.

Session 2 – Kim Schrantz-Berquist – If you can write an article, you can write anything!
I have a long term goal to get my team to a position to allow them to write different kinds of information. Articles for our developer community are a good path towards that.

Session 3 – Linda Urban – Paths to success: networking and contributing (it’s all about relationships)
Largely because I think it’ll fit in with my presentation the following day.

Sesson 4 – Chris Atherton – Visual attention: a psychologist’s perspective
Not something I’m particular clued up on so will be an interesting session.

Session 5 – TBC
Nothing really catches my eye, and still waiting to see what Paul Ballard is going to present. Might a good time to go grab a coffee?

Session 6 – David Mackay – talking about how he wrote his book
Always interesting to hear how these things come about.

Thursday

Session 1 – Me!
I’m guessing I need to be at this one, right?

Session 2 – Nigel Greenwood – Quality Improvement in technical communication
A different take on things, and it’s usually informative to look at the way other professions do things, so this should be good.

Session 3 – Justin Collinge – The secrets of telepathy
Who wouldn’t want to learn telepathy! This will be useful as I’ve recently taken on Line Manager duties for some of the wider development team.

Session 4 – TBC
Either going for the session about localisation or the one on how to start up your own docs business…. hmmmm

Session 5 – TBC
There is still a slot to be filled, so I’ll wait until that happens and then decided. At the moment, its looking like an early end to the day.

Session 6 – Adobe
Will probably skip this as we are no longer an Adobe house.

So, add in the Gala Dinner and it’s a pretty busy couple of days. As ever I’m going to miss some sessions that I would liked to have attend but I’ve got a pretty good balance of things here, most of which benefit the company that is allowing me the time to attend, a couple of which will help me as a professional.

I’ll most definitely be twittering and will write some thoughts post-event as well. The chances of me blogging are slim but you never know (I’m wary that my 9am slot on the Thursday morning may be in jeopardy if I get ‘forced’ into the bar on Wednesday evening…).

I’m looking forward to the conference, my first ISTC conference as it happens, and as two other members of the team are off to Cardiff for the UA Conference it’s safe to assume we’ll be heading towards the end of the year a-buzz with ideas and enthusiasm.