When she introduced the STC Region 2 Conference (13th-14th October 2006, London), Nancy Halverson stressed the importance of showing how technical communicators add value to clients and employers. Historically, technical communication has been perceived as a cost centre, but that meant the engineers ended up writing the documentation. And we all know the results of that.
Presentations were in two tracks-I attended the ones with the strongest business focus. Here I summarise what I got from the presentations.
Visual manuals-I must admit that I've always been a bit sceptical of the practicalities of purely visual instructions. Patrick Hofmann disagrees, and in the opening session, he proceeded to demolish my doubts. I've previously seen similar presentations from him: what changed my opinion this time were the case studies that showed the initial problem, the analysis, the visual documentation, and the huge cost savings.
My favourite example is of a laser projection system. Workers in leather-cutting factories use it to help with the cutting of hides. A big problem was that workers could not remember the complex key combinations. The client wanted a 10-page text-based online help system. As you may expect, there was no budget for audience analysis. Patrick took it upon himself to visit a factory and observe the workers. They spoke many different languages and most had a poor grasp of English. Most of them had hand-written reminders of key sequences near their machines. Despite the client's brief, Patrick produced a wordless poster, which appears on each worker's terminal.
The client was not impressed initially, but that soon changed. The workers made fewer mistakes and they were much happier. Training time was reduced from four days to less than one day. The return on investment (ROI) was large. The total cost of the project was about £7,000 over a 4-week period. The total benefit was about £120,000 in the first six months. Additionally, purchasers of the laser-cutting system were delighted, and so there were new orders for the product. Patrick concluded by saying that sometimes we have to take a risk. I agree. Clients don't always know what is best for them. Our job as professionals is to educate them.
Every technical writing company needs tools to help run the business. Nad Rosenberg from TechWRITE discussed some tools that her company created. The project status system was one that I found particularly interesting. It is web-based, and not only do staff have access, so do clients, so they see the status of a project, and they really like that. The change system is another web-based tool. This was developed because clients had been sending requests for changes by email and phone, and it was difficult to track these requests. Now clients can enter changes online for any draft, and there is an audit trail of the requests. All the requests are collated automatically, it's easier to proof the changes and to incorporate them into documents, and clients are more satisfied.
Silvia Cambié from the International Association of Business Communicators explained the importance of taking a strategic perspective. Technical communication is part of an organisation's communication strategy, and technical writers who are aware of the bigger picture will be able to help their companies achieve the company's strategic goals. Business managers will then value the work we do.
Strategic communication helps an organisation to achieve its objectives. It doesn't focus on how to use tools, but rather, how to accomplish the desired outcomes. Silvia suggests that technical communicators should understand things such as strategic planning, marketing theory, accounting, business law, and finance. Obviously, we can't be experts in these fields, but a basic understanding is important.
A clear link exists between communication and intangible assets such as customer loyalty and brand awareness. Intangible assets are important because competitors find them difficult to imitate and most of the value of an organisation comes from its intangible assets. But what should we measure, and how? Measure outcomes, not outputs. For example, whether or not the company newsletter was published on time is not as important as whether it changed customer behaviour.
Geoff Hart has a regular column in Intercom. That's always interesting, so I eagerly awaited Geoff's case study of process re-engineering (which lived up to my expectations). Put simply, 'process re-engineering' means changing what you are doing. Geoff works as an editor in a research and development and technology-transfer organisation in the forestry sector. Geoff's division has about 30 researchers, four communicators, and one editor (Geoff). Two major problems existed:
- processes were messy (they had evolved over 25 years)
- The production time was excessive (often over six months for reports that averaged 12 pages)
Geoff evaluated the situation in a consolidation exercise. He found there were 14 types of report and that authors revise their reports many times. The process had too much repeated handling and there was no control of deadlines. For a poor report, the author might revise the document 50 times (yes, fifty!) as the document was bounced between internal and external reviewers. On the positive side, the reports were all very good, and the organisation had a high reputation.
To improve the process, the organisation examined and described all the steps in the current process, produced metrics, and identified problems. The proposed solution included automatic routing and tracking of documents, setting deadlines, adopting on-screen editing, and removing unnecessary reviews.
Authors were given much help, not only with the technology, but more importantly, with their writing skills. Reviewers were asked whether deadlines were reasonable (people in the organisation often worked away from their desks in remote parts of the country). Managers were helped by having a simple tracking system.
Overall, the new process was a success: meetings in which a document was planned meant fewer subsequent changes, editing before a review made the review more efficient, on-screen editing was adopted by everyone, and there were no lost reports (historically, a problem). Quality was maintained or improved, less staff time was used, and fewer staff were needed.
Why did the process re-engineering work? Geoff concluded by saying that metrics make managers aware of problems and solutions. Frustration with the original process provided a motivation to change. Management support and buy-in from staff allowed the change. Not all the recommended improvements worked, so it is important to monitor changes.
'How to reduce the chance of failure in the first year' was the subtitle of the presentation by Derek Torres and Ethan McCallum from Standard 6. Two reasons for starting a business are control and freedom (which also happen to be disadvantages of running a business-you are the person to blame if it all goes wrong). Derek and Ethan explained the importance of research and preparation before you start your business:
- What exactly you offer, and the people who need it.
- Business plan. It's your roadmap to success. Your bank may need it. In some countries, it's a government requirement.
- Financials and banking. Choose a business bank carefully. In some countries, you may need much paperwork.
- Legal people. Find an accountant and use an attorney to review your terms and conditions.
- Business structure. Choose this carefully. In the EU various countries have different options.
- External communications: marketing, brochures, web sites.
- Fees. How much should you charge?
Derek and Ethan recommended that excellent sources of information are www.businesslink.gov.uk, www.startups.co.uk, and www.buncosquad.net. In the closing discussion, I added www.pcg.org.uk to their list.
The formal part of the conference concluded with a panel discussion, moderated by Brian Martin. The panel (Andrea Ames, Cindy Currie, Derek Torres, Patrick Hofmann, Paula Berger, and Silvia Cambié) discussed whether people in the profession are ready to define technical communication in terms of business objectives and requirements.
The panel recommended that to flourish, we need so much more than technical skills. We need people skills (leadership, team building), business skills (project management, negotiation, selling). Additionally, we need to participate by becoming involved in professional activities (speaking at events, writing articles, networking).
Not everyone likes this: after the conference, I talked to someone who said that she liked the writing part, and didn't want to do more than that. For her, leadership, business skills, customer relationships, and so on are of no interest.
Where do I stand? There will always be a place for people who want to 'do the work'. However, to move up the food chain, you do need the business skills. Only when we show how we positively affect a company's profits will we get the recognition we deserve.