Towards the end of last year I started to see how several related, but disparate, strands of work would start to come together. The information produced by my team, the training collateral, the partner focussed material, is all focussed on the product and this coming week will see the first step towards the realisation of all that hard work coming together into a cohesive story.

The final push comes in the form of a content audit, which will allow me to see where the gaps are, and where rework is required, to complete all the ‘stories’ that run from the main product messaging, down through our information strategy pyramid.

At present we have successfully moved to a single source/content re-use system which allows us to publish content to a knowledge centre hosted on our developer community website, that content is also used by the sales/pre-sales department who receive it in a different format.

The developer community website will be used by partners to both learn and keep up to date with product developments, and reduce the burden on our Support team (something that is already happening with call numbers going down since we introduced our new knowledge centre). The website also means we can look at producing our forms of content for information delivery, videos, screencams, example tutorials and such like.

This is an area where the training team and publications team will come together and which the content audit will help drive.

On a personal note it’s nice to be on the final straight of some ideas I’ve had brewing for a couple of years now. I’ve been lucky that I work with a team of guys who I trust completely to do a good job and who’ve never let me down regardless of the challenge.

It’s going to be an exciting few months, with much to learn and many hurdles to be overcome but once complete I think we will have an excellent, information focussed culture throughout the company.

Buy-in for the information strategy will be re-enforced by the content audit as I’ll need to talk to everyone who could/should be involved, but it is noticeable that there has been a shift in understanding throughout our company with the realisation that information will play a larger and larger role in driving us forward.

Pulling together my monthly column for the ISTC (I write about blogs, unsurprisingly), I noticed something rather odd. I really, sincerely, hope this isn’t something I’ve been unconsciously doing but it does seem that many of the technical communications blogs I follow, and which I feature in my monthly column, are written by men.

Given that, for the bulk of my career, I was usually outnumbered in many a Documentation department, with on one occasion when I was one guy in a team of six, I find this gender balance quite odd.

Thinking back to the Technical Communications conference I’d say there is a fairly even split of gender in our profession, but I can’t say I was paying that much attention.

Is it just me? Am I being over-sensitive about this?

Of all the blogs I monitor, the split is pretty even (a rough count suggests about 55% are written by men) but that doesn’t tell the whole story. Some of those blogs are very topic specific and I tend to look for things which will have the widest appeal, so perhaps the topic specific blogs are more likely to be written by a woman than a man.

Or not.

It’s a minefield!

We all have a need to make sure we are working on the most important thing, the thing that needs our attention and focus the most. Given that all of us will have more than one thing that needs to get done, you need to prioritise.

But how?

Ivan Walsh recently posted his thoughts on this topic but he doesn’t cover the process that comes before the daily decision making of “what shall I do today?”.

Presuming that you don’t lurch from day to day and that you have a plan, or at least a list of things that you need to deliver, how do you go about setting the priority?

Some people will be lucky to have a direct customer who knows exactly what they want, you can work with them around any constraints of time and budget (resource) to prioritise the work that needs done.

But what if you have two customers, or three, or seven?

Well that’s close to the situation I’m in and my solution is quite simple.

Let them decide.

A few months back I started to jot down, in a spreadsheet, everything that my team COULD do. It includes some items like scouring our Wiki for any useful information that we can use, as well as “hey you know what would be really great..” requests we get which aren’t urgent but which I didn’t want to lose.

I soon realised I might as well track every information request there and very soon after that I realised that I needed a way to sort the list and make sure we were working on the right thing, at the right time.

Given that many items on that list were ‘put’ there by other people, I realised that if we estimated (very roughly) how much effort each would take, we would be able to bargain with people and, ultimately if two requests are in conflict then, hey, I can get the people who requested them to discuss the reasons and let them decide.

So we now have a big list of work items, each estimated, each prioritised (we are using MoSCoW) and which I can use to drive discussions when the next “must have, immediately” request lands in my inbox.

Ultimately, our customers decide what we work on and as I can give them a full picture of what, and why, it’s much easier for them to understand those times when they don’t get what they want. Having that information to hand makes the act of getting real priorities much easier.

My response, via Twitter, to Ivan’s post was this: “I tend to let other people set the priorities for my work. That way they all have (to have) a view of it.”

How do you set your priorities?

Seriously, do we spend too much time worrying about this? What do we get paid for after all, to write documentation, so that’s what we should concentrate on doing. So what if no-one reads it, as long as I’ve done my job I’ll get paid.

And no, I don’t care if they don’t understand how to use the product properly, if they choose not to read the documentation then there isn’t much more I can do, is there? Yeah, they might get stuck but if I can learn it, so can they. If not then maybe they shouldn’t

Pander, pander, pander. I’m sick of it. The documentation is perfectly good and until people learn to read it then they really should stop complaining. Ohh and if they choose to look on the internet for an answer to their question, good luck! We all know that those bloggering things are a lot of rubbish and no, I don’t use that Twatting thing either, what a waste of time. Don’t even start me on Facebooks.

I’m perfectly busy enough, doing the job I was paid for, so yes, they should RTFM and it’s not my fault if they don’t.

…

Obviously I’m jesting, but this seems to be a bit of a hot topic right now, and rather than rehash what has already been said, I’d highly recommend you spend 10 minutes of your day reading the following:

• If no-one reads the manual, then why bother?
• If No One Reads the Manual, That’s Okay
• If no one reads the manual, that’s NOT okay
• Getting users to read the documentation

I guess it’s safe to say there are challenges ahead but hey, it’s a new year, what better time to start tackling them.

A few days ago I received an email about a new website. I’ve seen it mentioned on other blogs but think it’s worth repeating as there is some useful information there.

I am contacting you because I have just thought that maybe a post about my new web site on software documentation and user assistance could also be interesting for your readers. In addition to about 250 useful links for technical writers, the site for example provides checklists and up-to-date market surveys of more than 350 help authoring tools, screen capture tools, screencasting tools and other utilities for technical communicators. All information can also be downloaded as a PDF booklet (approx. 100 pages).

On the website you can find some basic know-how, checklists, tools and links, which will help you to create clear and concise user-friendly manuals, online help files, software demos, tutorials and other forms of user assistance. Go have a look.

Thanks to Marc Achtelig of indoition for getting in touch.

Like many, I struggle at times with a common perception, one which was highlighted to me yesterday by a colleague.

Like most team leads/managers, I have a lot of tasks that aren’t purely focussed on the creation of information. I don’t do much technical writing, instead letting the guys in my team focus on that (they are better at it than me anyway) whilst I work around the edges of what they do, things like taking a document through a review with some SMEs and processing the output, or building a new output template, or proof reading some of their work.

My team and I have a good idea of what I do, even though I also get dragged into chats about other information related initiatives (document management systems being the latest). But as far as everyone else in the organisation goes, I am obviously not doing a good enough job communicating that out.

So my colleague was asking how my team were doing as we are approaching the last few weeks of this current release cycle. When I said that it was a bit tight and we were probably going to have to move some of the ‘could have’ information, he asked why and then asked what I was working on myself.

Thankfully, to answer his question I have a whiteboard directly behind me that holds all the ‘other’ stuff that technical writing teams need to think about; Product Glossary updates, creation of a Knowledge Centre, Release Notes and so on.

However the point here is that, whilst we all struggle to convey the importance of what we do (until people get to that “ahhhhh” point which most do eventually), it is in all our interests to evangelise our services. Yes this will only have direct impact within your current organisation but the ripple effect over the coming years will start to grow as people move on and take your messages with them.

It may mean that you, and your team, need to stand up in front of the whole company to ‘introduce’ themselves and what they do (same applies for lone writers!), as well as backing that up with updates and conversations with people you may not normally chat to, and I realise it’s probably not something that comes naturally to many people.

So to give you a kick start, as soon as I’ve finished it, I’ll be sharing a sanitised version of that very presentation. It’ll be focussed on a software company which is being re-introduced to that wee team they all know of, but don’t know much about. I hope it might be of some use.

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.