If you’re a writer like me, news of a fresh assignment brings both excitement and anxiety. New assignments offer opportunities to further our knowledge and expand our portfolios, and they may result in a bonus or a more lucrative contract. But new projects can also inspire angst and dread if you have past experience with projects that involved false starts, unrestrained scope creep, misunderstandings between team members, uncommunicative teammates, or unfamiliar technologies.
As a technical writer for a government contractor several years ago, I wrote and maintained online help and manuals for over 20 software applications, any ten of which were active at a time. Each new task or update filled me with increasing levels of dread. My history at the company included dealing with large and varied project teams of strong-minded individuals whose conflicting interests constantly undermined the software development procedures. I found myself in a whirlwind of projects that often changed in scope faster than I could keep up. A manager from technical support might say that the software fulfilled one need, while a manager from development felt it satisfied another. A developer added a software feature to help the end user, while a customer representative would never advise such an enhancement. I’d hunt for project leaders to take responsibility for various aspects of the project, often ending up with ambiguous remarks and high levels of confusion. All this went on as I tried to address the needs of an audience whose members and goals were different depending on which team member I asked for help.
To protect my deliverables from ambiguity and scope creep, I developed a project kickoff form. It rescued both the quality of my deliverables and my sanity. The form proved to be the best way for me to begin any project, and I relied on it to help me elicit information required to understand the purpose of my deliverable, begin research, and finish the work on time. It helped me identify individuals responsible for various aspects of the project and create a foundation on which the documentation could be built. I took the form to kickoff meetings and completed it in the presence of all project personnel. In addition to helping me gain critical project information, the form helped me to appear professional and confident in front of project members who seemed to have little understanding of the role of a technical writer or the requirements for developing online help and manuals.
On its debut in project meetings, team members tolerated my form with varying levels of impatience and humor. But subsequently, it was accepted more graciously. On several occasions its popularity grew as it acted as a reference tool when aspects of a high-profile project began to get muddled.
Just completing the form didn’t prevent all my troubles, but it did enable me to start projects quickly and resolve any issues that arose more efficiently. I referred to completed forms to verify project intent and to quickly locate the person in charge. Since then I’ve used the form at the start of every technical writing project that has come across my desk, as well as for several freelance Web site projects. In fact, in my current contracting roles, people appear quite pleased that I have a form we can fill out together before they send me into the trenches.
In short, the attached project kickoff form, available for you to use as is or to modify for your own needs, has been an excellent tool for launching and managing new projects.
Project Kickoff Form
- What is the name of the product involved in this project? If it has not been named yet, why? Do you need help with a name?
- What is the purpose of this product? What does it do?
- Who uses this product? Who are the primary users? (Data entry clerks, tech staff, engineers, salespeople?) Who are the secondary users? (Managers, executives, trainers?) Are they educated users? (In computers? In the application’s business functionality?)
- Where are these users located? (Internationally, nationally, locally, etc.)
- What is the price point of the product? (High-end, low budget, not applicable?)
- What is the primary purpose of this project/enhancement/product development? Are users/potential users aware of this project/enhancement/development? How are the users likely to respond to this project/enhancement/development?
- Are there any secondary purposes to be accomplished? (Public relations tactic, sales expansion, bug fixes, etc.)
- What are the documentation/Web site deliverables? (Manual, online help system, Web pages?) How would you like the work packaged? Is there an editorial style guide you would like followed? How is the audience likely to respond to the documentation? Are there comments you would like incorporated into HTML?
- Do you have existing art, illustrations, manual, or CD cover designs? Who is in charge of these elements (marketing contact)? Are there guidelines for logo use/color scheme?
- Who has overall ownership and veto-power over this product and its deliverables? (Name, phone numbers and extensions.) Who is the primary technical contact? Who is the sales contact? Who is the technical support contact? Who is the customer liaison?
- Who are the members of the documentation review team? How should reviews be submitted (electronic, hardcopy, etc.)? What is the length allowed for reviews? (One chapter or help system book/several help topics/maximum number of pages plus expected turnaround time.)
- When do you need the deliverables/work completed?
- Does the documentation have to be translated? When are the translations required? Will subcontractors/external vendors handle translations?
