Updated: 07 June 2007
Table of Contents
- 1. Preface
- 2. Part I: Getting Started
- 3. Part II: Managing People
- 4. Part III: Managing Projects
- 5. Part IV: Managing Technology
- 6. Appendices
- 7. Bibliography
- 8. Glossary
- 9. Index
An introduction to what this book is about and who it is for. The book has four major parts: Getting Started, Managing People, Managing Projects, and Managing Technology. The style of most sections is to start with a real life situation or story pertaining to that section’s topic, and draw from that situation specific conclusions and suggestions.
The audience is primarily documentation managers, but also includes writers who have to manage their own work and managers who have one or more writers on a product development or marketing team.
Describes how I became a documentation manager, and how I became “educated” by my team. Also discusses my philosophy of management and sets the stage for the style of the book.
Many people become documentation managers with little or no experience dealing with technical documentation. This chapter provides a high level overview of technical documentation for those in that boat. It identifies seven elements of technical documentation: product, developers, audience, tasks, deliverables, environment, and schedule, and presents them from the perspective of the technical writer.
The definitive management challenge for documentation is power. Documentation lives at or near the bottom of the formal hierarchy of project disciplines. Some documentation managers simply accept this; more successful ones find ways of gaining informal power. This chapter uses an example where my team was able to increase its influence on a major project to illustrate several ways to improve the position of documentation in the power structure.
This part discusses the human side of managing.
A discussion of what your Personnel/Human Resources organization can do for you, what you should expect and what you shouldn’t expect from them, and when is it essential to work with them.
A discussion of selecting the best people so that you rarely have to do that “other thing.” What you should be looking for when you hire technical writers, how to interview, and how to evaluate writing samples.
Or more accurately, how to avoid de-motivating. A discussion of what motivates employees and how you as a manager can create an environment that provides the fewest possible de-motivators.
In most organizations, you will be forced to evaluate and probably rank and/or rate employees. A discussion of what evaluation is about, how to make it a positive experience for employees, and how to deal with the twin evils of ranking and rating.
Outsourcing is a reality, whether we like it or not. A discussion of what it means to the documentation manager.
What it takes to plan and execute a project.
- The truth about plans. How project management uses plans and how you need to use plans to be effective.
- How to create a documentation plan. Steps to create the plan and steps to write the plan. Who should write which parts of a plan. What form should the written plan take.
- How to make useful estimates.
- How to anticipate and deal with changes.
- How to work with the project management team.
What to track, what to record, what to report and when to report it, and how to know when you’re in trouble.
How do you deal with the rest of the project team; what do you need from them, what do they need from you.
How to manage translation and localization.
You will need to deal with at least some technology.
General thoughts about technology, plus a set of guidelines for living with technology.
A discussion of what you can reasonably expect to get from technology, and how you can avoid over-reliance on technology. For documentation, the critical point is that technology is not a substitute for good research, logical organization, and good writing.
The failure rate for big ticket documentation projects, especially content management projects, is notoriously high. This section discusses why this is so, and how you can avoid disaster.
- Understand costs and benefits. In particular, do you need that new content management system/XML authoring system/single source publishing system? You may not. Make sure there are realistic, measurable benefits before taking the plunge.
- Understand your requirements. This is the big one. You’d think it would be obvious, but many projects founder on poorly understood, misunderstood, or simply non-existent requirements.
- Understand your processes. Make sure you understand your existing processes before you try to automate them.
- Plan for change. You will underestimate the time needed adopt new technology. This section discusses how to deal with that and avoid having changes and delays torpedo your project.
An overview of XML technology as it applies to documentation. Contains a brief history, an explanation of the key concepts, a discussion of pros and cons, and a consideration of when it makes sense to use XML and when it doesn’t.
A look at how the internet is changing documentation. In particular, it will consider delivering documentation on the web via “traditional” web pages as well as newer vehicles like wikis.
A consideration of these topics, with an emphasis on pealing back the hype and looking at where these technologies make sense and where they don’t.
I’m not sure whether there will need to be any appendices. This would be a logical place to put planning templates and checklists, if I end up creating any.
Just what you’d expect.
Just what you’d expect.
Just what you’d expect.
Copyright 2007 © Richard L. Hamilton