One of the classic mistakes novice writers make is to start writing without looking at the overall picture. Planning the scope of your project is key to its overall successful.
So, before you start writing, identify everything involved in the development of the project. By the way, this applies to any type of project, whether it’s writing, development, design, or cooking…. You must have a plan.
For a documentation project, Identify the;
- Software Templates and Style Guides
- Access to IT Systems
- People resources, such as graphic designers
that need to be in place so that you can write the documentation.Don’t assume these will be ready!
A lot of this may seem very obvious, but based on experience, client often underestimate the resources you will need to have in place. They tend to overlook system access, passwords, swipe cards, parking spaces, technical resources and other such requirements. Without these you can’t accomplish your tasks.
Encourage your client (gently but firmly) to ensure they‘re in place; otherwise your schedule will be knocked off balance. Don’t wait until you arrive at the building before asking if there is a test system you can use. Ask these questions in the warm-up meetings before you start on-site.
Here are some areas to consider before starting your project:
- Does the Writer have access to Test Systems?
- Is the Writer is provided Training on the system that they are to document?
- Will the Writer be working on site during the project?
- Will the Writer have access to SMEs?
- Will new Change Requests occur once the project has started?
Creating a Project Plan
Examine the following areas so you can define a project plan that reflects the amount of work that’s involved:
Training required for you to understand how the system works – eg 2 days
Gap Analysis between current documentation (if it exists) vs. proposed documentation – eg 2 days
Review current documentation (if it exists).
Can any material be reused or do you need to write everything from scratch. Re-writing existing material can be very time-consuming as you have to modify the tone, style, and phrasing to match your writing style. You also need to test the integrity of their documentation as you can’t assume the instructions are correct. eg 5 days
Agree on the Document Format – this will affect the workload if the document needs to be delivered in multiple formats, such as MS Word, Adobe PDF, Online Help, or Web Help.
Determine the number of pages that will be written per day, for example:
5 pages per day
100 page output
= 20 days documentation
Number of SMEs to review documents (allow 1 week turnaround) and provide feedback:
If you assume there will be 25% changes to the documentation (20 days) then the total project is increased to 24 days approx.
Note: SMEs are Subject Matter Experts, i.e. individuals with in-depth knowledge who can review the documentation accurately.
Speak to the client’s Project Manager and make sure you have access to the following:
Company image library for product screenshots, samples of training material etc.
Graphic designer to create illustrations, complex screenshots, splash screens, box shots.
Style Guide or, if none exists, agree on using an established guide such as the Microsoft Style Guide for Technical Publications.
MS Word Templates – make sure these are available before you start. If not, factor their design and development into the project plan.
This list is not exhaustive by any means.
The key thing is to think ahead and anticipate any areas which may undermine the project’s success.