Friday, November 28, 2008

Would you like to take part in our benchmarking survey of UK Publications teams?

Cherryleaf is undertaking a benchmarking survey of Technical Publications teams based in the UK. Participants will be give a copy of the summary report of our findings that we'll be putting together.

If you head up a team of 3+ writers, which is based in the UK, and you'd like to participate, then please contact us.

Labels: , ,

Thursday, November 20, 2008

In a downturn, is it better to use contractors, permanent staff or an outsourcing company?

In a downturn, priorities in a business often change, and these changes can affect technical authors as much as others. At the London Connections event earlier this week, where I was promoting Cherryleaf's technical writing services, I was chatting to Mike Southon about business strategies in a downturn. Mike is Visiting Fellow in Innovation and Entrepreneurship at London South Bank University, amongst other things, so I value his judgement. He said, in a downturn, businesses should focus on its Return on Investment, minimising risk and watching its cashflow.

So, does this mean you should favour contract technical authors over permanent staff, or vice versa? Should you outsource technical writing work instead? Actually, each option has its merits.

The case for and against contractors


Contractors offer flexibility to a business. You can increase and decrease the amount of people more quickly than you can by taking on permanent staff.

This ability to reduce costs quickly is one of the main reason why organisations often begin reducing costs by getting rid of contractors. Contractors can appear expensive compared to paying for permanent staff. This means there's a temptation to avoid using contractors at all during a downturn. There is often a premium, because you're using paying for someone who is good and who is experienced. However, remember the contractor is bearing holiday sickness and taxation costs that otherwise would be borne by the organisation.

It's worth bearing in mind that in terms of uncertainly, this flexibility could be a good reason to favour contractors over permanent staff.

The case for and against permanent staff


Permanent staff offers continuity of service. They can also be part of a team that works in a consistent manner that conforms to the organisation's long term goals. They may be able to be deployed elsewhere, such as in usability testing, training or support.

However, it is less easy to reduce the number of permanent staff than it is to reduce the number of contractors. The process can take much longer and can be more stressful.

The case for and against outsourcing


Outsourcing can mean using a technical writing company, such as Cherryleaf, to write an online Help file (or other forms of user assistance) for a specific project. It can also mean establishing a more longer term relationship - acting as the technical publications department, being available on a "call off" basis or acting a part-time (say three days per week) resource.

Outsourcing offers benefits similar to contractors, with the added benefits of continuity of resource, project management, predefined deliverables, and the collective knowledge and of expertise that organisations can offer over an individual. It's worth considering when work is unevenly spread throughout the year, when it comes in peaks and troughs, or if there isn't enough work to require a full time resource.

Outsourcing does not work well when deliverables cannot be defined, and the information needed to do the work is not available (although this is true of all projects). It's often done off-site (but not off-shore), as the work can be scheduled around other writing projects and a team of writers can work together, but some organisations are able to work with such an arrangement.

What about offshoring?


Offshoring of technical writing is something that is less common than the offshoring of programming resource. The standard pros and cons of offshoring apply (lower initial costs v quality and project management issues), but there are some additional considerations. The key skills needed in a technical author are great writing skills and good project management skills. This means nearly always that the person needs to be a native English speaker. A non-native English speaker can write a sentence that is grammatically correct, but be written in such a way or use a word that just would never be used in the UK or other English speaking countries.

The "do nothing" option


Some organisations opt not to develop any user assistance at all. This saves them the cost of developing online Help, user manuals and other forms or assistance. Is this a false economy or a sensible saving?

User Assistance is often seen as a necessary evil, and its value can be hard to measure, in the same way that quality can be hard to measure. It depends if you are producing the equivalent of an Austin Allegro (UK's "Ford Pinto") or a Toyota Corolla. User Assistance is tied up with an organisation's long term view of its customers. The more important it sees customer loyalty and after-sales service, the greater the value of user documentation. User Assistance, be it delivered via Web pages, paper manuals or online Help provides immediate assistance and can reduce the number of calls to support lines and the number of dissatisfied customers.

There's a poem I once saw on the Web that began something like, "If an application doesn't need user assistance then is there really a need for the application itself?" It's like the idea of the software that sells itself - in a perfect world, you wouldn't need a sales team either.

Could the programmers write the documentation?


Programmers do write user documentation, and often it shows. If the programmers have nothing better to do, then there could be a case for them writing the documentation. However, programmers are not always a cheap and available resource.

They often suffer from the "curse of knowledge" - they know so much about the system that they cannot see the world as a user (beginner or advanced) does. It's unusual for a programmer to be also a good technical author. Indeed, perhaps there is a stronger case for the users to write the user documentation instead?

Conclusion


All these options have different merits, which is why organisations such as Cherryleaf needs to offers a range of options (outsourcing staff, contract staff and the placement of permanent staff). Your organisation is unique and the requirements you have will differ from others. The key factor is often the spread of the workload. If work comes in peaks and troughs then outsourcing may be the best option. If the nature of the work itself is unclear then permanent staff may give you more flexibility.

The challenge for us at Cherryleaf's is to use our expertise in the field of documentation to help you save money: by finding the best solution for your business needs and giving you a good return on your investment.

What do you think?



You can comment below.

Labels: , , ,

Wednesday, November 19, 2008

There's the tribe, where's the technical author?



I've just downloaded Tribes Q&A, a fan book inspired by Seth Godin's latest book "Tribes: We Need You to Lead Us". The book talks about the basic need humans have to connect with other human beings from a social and a commercial perspective.

There's one sentence that stood out for me: Connecting people and giving them a place in the world IS (what makes you a living).

I immediately thought, this affects technical authors. They connect people to information, rather than people. They help people find their place. They play a role in building and maintaining an organisation's tribe. They show there's more to the supplier-customer relationship than the moment of the sale.

The user assistance that technical authors provide is part of the longer term relationship that leads to customer loyalty.

The book asks and answers some great questions:

- How does a tribe awaken its “sheepwalkers"?
- How does the leader of the tribe walk the fine line between being inclusive and allowing the tribe to become a democracy? Between setting direction and becoming an autocratic factory?

It raised some questions in my mind:

- Does Cherryleaf have a tribe?
- To which tribes do you belong?

Labels: ,

Sunday, November 16, 2008

The user manual in advertising



A photo of a mid-1980s ledger application for the IBM PC.

The ad copy stated:

“For the introduction of the IBM PC, we designed the packages and software manual, creating, instead of the industry’s usual cheap plastic binders, hard-bound linen covers and slipcovers in pastel colors to stress cultural elegance and personal values.”

Spotted in Gearfuse, via BoingBoing.

Would an advert like this work today?

Labels: ,

The user manual in TV advertising

I came across these classic TV adverts today, which feature the humble user manual.





Would an advert like this work today?

Labels:

Friday, November 14, 2008

New Technical Author vacancy added to the Cherryleaf Web site

We're just uploading a new technical author job vacancy to the Cherryleaf Web site. This one is in Cambridge.

Labels: , , ,

Cherryleaf launches new course on editing and proofreading


We've just introduced a new classroom training course on editing and proofreading.

This course is aimed at individuals who have to create text and documents as part of their day to day work. They are not professional copywriters but may be called upon to provide reports, leaflets, instructions, fliers or web copy as part of their daily activities. This course covers the basic principles of providing coherent and engaging writing - and how to check its suitability for purpose and accuracy.

See our "Editing and Proofreading Course" Web page for more details.

Labels: , ,

Sunday, November 09, 2008

Oh dear


This is a photo taken by Garr Reynolds.

Friday, November 07, 2008

Basics of Technical Authoring self-study training course page goes "live"

We’ve just uploaded the files and activated the Buy link for "Basics of Technical Authoring - a self paced, home study training course". In other words, we can now take orders from people wanting to purchase it.



This course teaches general, basic technical authoring principles and writing approaches suitable to user documents. It describes the entire documentation process: planning, writing, editing, indexing, and production. This book focuses on documentation for computer hardware and software. However, many of the concepts described apply to other forms of technical writing, such as writing about manufacturing environments, medical and pharmaceutical topics, and science.

Labels: , , ,