Category: Work

A few weeks ago I mentioned that we were looking for a new way track our tasks. After checking out a few different applications and web applications, I think we have a solution.

The problem we have is that, whilst the bulk of the work is scheduled against a project plan, there are a myriad of smaller tasks and documentation changes that we need to track. These come in through various channels, our Support team, our ‘Core’ team (who maintain the latest stream of the product), and through our team inbox.

Previously we mirrored the development teams approach and used index cards and a BIG whiteboard but it wasn’t really working for us for a variety of reasons. So I spent a couple of days downloading task tracking applications, and hunting for a web-based application that might meet our needs.

There are many out there and the first thing I realised is that most of the are aimed at the project management set and are very date driven. Most of the tasks we wanted to track aren’t heavily date driven, and so are picked up as and when the team has a some spare time in the project plan.

One of the first applications I found was TeamWorkPM which seemed to fit our needs and then some. However it was still quite over-spec’d for what we had in mind so when I stumbled over No Kahuna it was soon apparent that I’d found a good match.

Importantly, No Kahuna is a task tracking application. Dates do not feature. You simply create a project, add project members, then start creating tasks. You can assign a task to a specific project member (or take it for yourself) and when it’s done, it’s marked as completed.

You can add comments to tasks, which is useful when some tasks may sit in the list for a while so you can build out a level of information for when they are finally actioned.

All very simple, it worked well enough in our short trial that I’m happy to shell out $7 a month to get a private project (not visible to the public). If you are looking for an online, lightweight task tracker, check out No Kahuna.

Technical Communication UK
22nd-24th September 2009

http://www.technicalcommunicationuk.com

Technical Communication UK is the new annual conference that aims to meet the needs of technical communicators, their managers and clients, from every corner of the industry.

The conference is hosted by the ISTC, and run in partnership with X-pubs.

Technical Communication UK runs on 23rd and 24th September 2009, with pre-conference workshops on 22nd September. It will deliver more than 30 sessions over the three days, with presentations, workshops, case studies, and hands-on product demonstrations from experts in their field.

Let me know if you are coming along, as I’d hate to be sitting in the bar on my own on the Wednesday evening!

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.

Twitter is changing. Whilst the technology is the same, the way it is being used (or perhaps the way I use it?) has been slowly evolving.

Evolution is a good thing, but that does mean that I now find myself evolving how I use and interact with Twitter.

Maybe I need to slim down my followers list and remove those that are only making noise.

I include those who have endless conversations between themselves, for me that’s just noise.

Hashtags present another issue, whilst they can be useful they are now used in other ways which add to the noise.

I’m worried that I’m actually considering the categorisation of some Twitter posts as “types of noise”, but maybe that is what is needed?

Whilst I can use apps like TweetDeck to filter out “types of noise”, it would be better to have opt-in than blanket messaging?

But then, that’s not Twitter, is it?

I’m really not complaining about Twitter or those who I follow, although a little self-policing would help.

After all, what happens when you put 100 people in a room mostly talking to themselves?

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.

Like most technical writing teams we are small in number. As such, monitoring and tracking both the work that needs done as well as the work that is in progress can be a challenge.

So I’m currently casting my net far and wide to find a good way to keep a handle on this so that I’m always reasonably up to speed with where we are in the grand scheme of things. Forgive me if the following isn’t particularly well delivered, as I am thinking this through as I type it up.

First things first, we need a plan. Actually we need two. One is a high level map of the documentation structure for the entire product so we always have a view of what we are writing and where it will go, and the map will include indicators about the audience so we know who we are writing for at a given time.

Then we need to plan the next batch of work inline with the development teams, estimating what new content is need and how long it will take. Alongside that is the daily churn of small bug fixes and enhancements, some of which will need to be documented, and the supported streams of older versions of the product as well.

The occasional request via email rounds out the various routes in which new items of work are generated.

I’m ignoring, for now, passing comments by colleagues (most times I’ll just email them to our team email alias to make sure we’ve captured the request).

So, project plans, topic breakdowns, bug fixes and open requests for more information. Nothing to out of the ordinary I’m sure, nothing that each and every technical writer has to deal with.

Which begs the question, how DO you deal with it all? Over to you, how do you track your work?