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: , , ,

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: ,

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: , , ,

Saturday, September 27, 2008

Give me your technical writers yearning to breathe free

We've two clients, one in France and the other in Denmark, willing to hire US American and Canadian technical writers who have the skills they need. Salaries are up to $150,000 pa.

There are approximately 1,500,000 Americans of Danish origin or descent,according to Wikipedia, so this could be a homecoming of sorts.

See the Vacancies page on our web site for more details.

Labels: , ,

Friday, June 06, 2008

Trends in Technical Communication - Peering into the crystal ball

I'm starting to think about a conference presentation I have been asked to make later this year. Sometimes, our talks are about "big picture" issues, such as "what makes a good technical author?" or "what's the value of documentation?", and I'm currently considering whether I should talk about the future trends in technical communication.


The two current trends in technical communication


There seems to be two trends in technical communication, at the moment.

The first is the move away from a craft-based approach to creating documentation, and a move towards a more "engineering" based, methodological approach. It explains the interest in and move towards single-sourcing, XML, DITA and such like. It promises more efficient writing processes, faster "time to market", but little change in what the end user actually receives.

The second trend is the adoption of Web 2.0 technologies to provide user assistance. I've heard it also called "free documentation", "right to remix", the "democratisation of documentation" and "tech writing 2.0". I don't think any name has stuck yet, apart from the generic "Web 2.0". It's a trend that promises a major difference in what users actually receive as user assistance.

We describe Web 2.0 as having three main themes: the aggregation of knowledge; collaboration on content creation; content as conversations (and linked to that, the wisdom of the crowd).

When I presented on Tech writing 2.0 at the end of 2006, the major developments mostly related to the aggregation of content across the Web. Today, the biggest developments seem to be with conversational content.

It's content that is, today, being created away from the Technical Publications department.

What does this mean to technical communicators?


I think the questions technical communicators should be keeping in the back of their mind are:

1. Should I be adopting and embracing these trends?

For some organisations, particularly those with a small user base or a small authoring team, the answer is NO. It's hard to see where the participation and the benefits will come from. However, will that mean their documentation will look inferior to more mainstream software?

2. Can these two trends be unified?

Will these trends converge? Will Web 2.0 content rip apart all those carefully laid plans for a single repository for all your content?

3. Who will take on the role of editor?

Who will keep all this information in order? Maybe you will need to take on the role of an editor.

The correct answers, I believe, have yet to emerge.

What else should I be reading apart from the Cherryleaf blog?


Take a look at these articles:
Why Do People Write Free Documentation? Results of a Survey by Andy Oram
The State of Free documentation, by Adam Hyde
The state of free documentation by Anne Gentle

What do you think?

Labels: , ,

Monday, May 12, 2008

The eee pc and the right to remix documentation dilemma

Last week we purchased and received an Asus eee pc 900. Its popularity illustrates the dilemma manufacturers will face in the future, with regard to their user documentation/user assistance.



Background


The eee pc is a ultra portable laptop, which costs roughly a fifth of the price of an Apple Airbook or a Sony Vaio.

It runs on Linux and it was originally designed for children, which explains why it is so cheap. It has a simple interface that provides links to the key software but restricts you from doing much else.

The consequence


Its low cost, low weight and size means the eee pc is popular outside its target audience. The consequence of which is Asus now has a group of users who want to do more with the laptop than was originally intended. They want to add more software and access the Linux desktop hiding underneath.

The manual supplied provides basic, but usable, information on how to use the laptop as originally designed. It doesn't provide any more detail than that. So, as a consequence, a number of Web sites have developed, such as eeeuser.com, which tell users how to access the advanced features.

The problem for Asus is they now have a group of users making modifications to their laptop, based on completely unofficial information. Users have to trust this information is correct - hoping it won't trash their machine.

The dilemma


Here's the dilemma:

Should Asus distance itself from this information? They might miss out on sales to business users if they do.
Should Asus let its documentation be "remixed" - supplemented with additional, more geeky information from users? The information might be incorrect.
Should Asus moderate this user information in someway? They might end up with more support calls if they do.

So what should they do?

Labels: , ,

Thursday, April 03, 2008

Quote of the month

We've just received this nice testimonial from a client:

"I had some basic instructions for my new online application, Opportunity Matrix™, but absolutely no idea how to turn them into a proper help system. Carol at Cherryleaf was able to take my rough notes and turn them into a professional Help file.

She worked through the application, suggesting appropriate changes where I was making assumptions that would have left users confused. Once we were both happy with the file, Carol liaised very effectively with the programmer to make sure that the Help system worked perfectly right from the start.

The information and guidance from Cherryleaf was always top notch, so I always knew exactly where the project was, and what the (quite reasonable) budget needed to be. I shall have no hesitation in using Cherryleaf again, and in recommending them."



Andrew Horder, CEO, Opportunity Matrix™.

Labels: , ,

Wednesday, April 02, 2008

Why does this project manager have so many lines on his face?



Notice the man's wrinkles. What have past software development projects done to him?

Maybe this time it will be different.

Maybe this time he can sleep knowing the users will get the documentation they expect. Because maybe this time he'll use a technical author.

Cherryleaf works with developers of software helping them ensure they have the technical authoring resource available to give their users the user assistance they really need. Whether you need either a managed or unmanaged resource, then the people to call are Cherryleaf.

Call us on 01784 258672.

------------
(Testing a new advert)

Labels: , , ,

Wednesday, February 13, 2008

Better than Free: User Documentation?

Kevin Kelly has posted an interesting post called "Better Than Free." It's about what succeeds in a market where most assets are free.

"The internet is a copy machine....When copies are super abundant, they become worthless. When copies are super abundant, stuff which can't be copied becomes scarce and valuable.
When copies are free, you need to sell things which can not be copied.
Well, what can't be copied?....


There are a number of other qualities similar to trust that are difficult to copy, and thus become valuable in this network economy... We can start with a simple user question: why would we ever pay for anything that we could get for free? ...From my study of the network economy I see roughly eight categories of intangible value that we buy when we pay for something that could be free."

Kevin argues the eight generative qualities add value to free copies, and therefore are something that can be sold. They are:
  • Immediacy
  • Personalisation
  • Interpretation
  • Authenticity
  • Accessibility
  • Embodiment
  • Patronage
  • Findability
How does this relate to user documentation?
Documentation is often very easy to copy in itself. However, documentation can also be a mechanism to help create these "generatives" in a product.
Furthermore, these generatives sound familiar to anyone who has ever attended a documentation conference debate on the future of technical communication; in particular: Immediacy Personalisation, Accessibility and Findability.
Perhaps the future value of technical documentation lies in these eight factors?

Labels: ,

Friday, February 08, 2008

The ROI of documentation and support

In two conversations this week, the issue of "how do you measure the value of documentation?" has come up.

The benefits of user documentation (reduced support calls, increase in the perceived value of the product, happier customers, better customer retention, increase product usage etc) can be identified, but it can be hard to measure them and accurately quantify the Return on Investment.

Here are two ideas:
  1. Conduct a test with two groups of potential users. Give one group your product to install and use for a period without documentation. Give the other group the product with documentation. Ask each participant (a) At what price should this product be sold for? (b) What monetary value would you place on the documentation? For (a), those that had the documentation should value the product more highly than those that didn't. The difference between the two prices gives you one indication of the monetary value of documentation.
  2. If you have a Web-based application, use Google Analytics to measure the number and types of people using the Help pages. By placing a value on each visit (e.g. every 2 Help pages visited equals 1 support call avoided), you have another indication of the $ value of documentation. You can use Google Analytics to measure usage by embedding its code into the HTML of each page. Also, some of the Help Authoring Tool vendors offer analytics software for LAN based Help.

Labels: , , , ,

Thursday, January 31, 2008

121s - review

Our first day of 121 meetings went really well yesterday. It's always a surprise what ideas and suggestions other people have, and it's always a pleasure to give advice and feedback. Everyone turned up early - is that a technical author trait, I wonder? No-one got lost; everyone found us.

We'll be scheduling more dates soon.

Labels:

Thursday, January 10, 2008

The user assistance skill set

We were having a clearout when I found a handout from a presentation made by Joe Welinske on the user assistance skill set. Although this presentation must have been made four or five years ago, it still rings true today.

According to Joe's survey, the skill set of for user assistance comprises:
  • Writing
  • Editing
  • Indexing
  • Quality assurance and testing
  • Graphics development
  • Information design
  • Usability testing
  • Task analysis
  • Localization
  • Coding Help
  • Coding Web content
  • Programming
The most valued user assistance skills were:

Writing procedures (92%)
Experience with tools (85%)
Writing reference information (79%)
Interviewing (74%)
Coding HTML (72%)

As Joe put it, you get paid for the writing.

Labels: ,

Monday, September 10, 2007

Technical Authors and the right to remix

One feature of Web 2.0 is the idea of the "right to remix". This means giving people the ability to remix your information and services.

This could impact the documentation department in two ways:

1. Your organisation decides to allow others to remix and "mashup" its application or service. As part of this, the documentation needs to available to third parties to help support their (and now your) users.

2. Your organisation develops software as it has always done, but you still want to enable others to modify and remix your documentation.

So what would be the implications of giving others the right to change and republish your user documents? A few questions spring to mind:

- If your document were to be combined with other information (say training material from a third party) would users have a better product?
- How do you ensure all the safety information and legal disclaimers and retained and referenced in the right places?
- Can the document be remixed? Does it need to be modularised?
- Would/could somebody do a better job at presenting the user information than you?
- What would the impact be on support call reduction and product perception?
- Would they add or remove information?

This is an area where some technical authors and documentation managers will need to establish a policy in the future. If you want to encourage remixing, you'll probably need to amend your license and copyright agreements to enable people to do this legally. You'll also need to establish some publishing rules and standards too.

Labels: , ,

Saturday, July 21, 2007

Harry Potter and the deathly Help file

Last night, my family and I went to the midnight party of "Harry Potter and the Deathly Hallows" at The Lion and the Unicorn book shop in Richmond upon Thames, Surrey. This children's book shop is located in a narrow paved alley, so the queue of 100-odd people dressed up as wizards conjured up an image straight out of Diagon Alley.

So what does this have to with Help files? Walking back to the car park, I remembered that, in the distant past, in our time at Digitext, we wrote the text for the Helper character in "Lego Creator Harry Potter". We were asked to write help text appropriate for an eight-year old boy (Lego is for boys, apparently). This lead to issues like, do eight-year olds understand the word "cylinder"? It was agreed they didn't, so we had to come up with an alternative term that would work internationally. We eventually settled on "this type of object is like a baked bean tin". It was a great project to work on.

My 8 year old bounced out of bed, six hours later (groan). How do they do that?

Labels: , , ,

Thursday, July 19, 2007

Nine little known secrets about creating great user information

We've written a new article on nine little known secrets about creating great user information.

Please read our article to find out more.

Labels: ,

Monday, July 16, 2007

Six biggest mistakes Project Managers make with documentation and how to avoid them

We've written a new article on the six biggest mistakes Project Managers make with documentation and how to avoid them.

They are:

1. They don't communicate their central message and their desired outcome.
2. They are inconsistent or unclear in what they want to say.
3. They don't use the best style of language.
4. They leave insufficient time to write the information, or spend too much time on presentation.
5. They present the information badly.
6. They don't have a manageable way to maintain the information.

Please read our article to find out more.

Labels: ,

Wednesday, July 04, 2007

Free tool for opening Word 2007 documents in Word 2003

Martin Lewis, the money saving expert, has just mentioned Microsoft offers a free tool for opening Word 2007 documents in Word 2003.

If your computer is using Microsoft Office 2003, XP or 2000 programs, download the Compatibility Pack from Microsoft.

You may need to install software updates before the compatibility pack. See the compatibility pack overview section for more information.

Labels: , ,

Friday, June 15, 2007

AuthorIT Live!

Ray Duncan from AuthorIT was in town this week, and I had an excellent chat with him yesterday afternoon. It was a great opportunity to throw out some suggestions for their product, and to get an update on what's due out in the near future.

AuthorIT Live!, which is due out very soon, sounds really exciting. It should offer a great environment for collaborative authoring - a flexible environment for professional technical authors and a controlled environment for engineers; access to the system wherever there's a PC with broadband access; plus all the other existing AuthorIT capabilities.

Labels: , , , ,