Technical And Freelance Writing – Plan For Success

So you’re talking to your customer; you’re just about there with the scope and the price; but are you sure you’re thinking along the same lines as your customer?
A great many modern technical writing projects come unstuck for the most basic of reasons. How many times have you heard…?
– “I would have written the description differently.”
– “It’s just not what I expected.”
– “Where are the instructions for…”
– “Why haven’t you described the…”
In large technical writing projects like those for defense or aerospace platforms, project managers and technical writing specialists can spend months and even years, planning the project before a single word is written. For each project, this planning phase is undertaken not just to ensure that the writers will know what to write, but to ensure that the project is achievable in the first place; that the customer will know what is being produced for them; that they will then accept and pay for the project deliverables; to calculate what it will all cost; to schedule the work and mitigate potential risks in advance.
For the smaller scale or freelance technical writer, the situation is no different. Before taking on any project, large or small, you will need a clear statement of the requirement. This statement should articulate, unambiguously, what your customer is looking for and what he is buying from you. Some customers may not have this statement readily available: this can be for many reasons and is an opportunity for you to assist them in articulating their own requirement and gaining formal agreement.
The statement of requirements is, however, only part of the map that you are producing. This map will also need to show the scope of the work that you will be taking on.
– What will your responsibilities be? What will your customer’s responsibilities be? Make a clear record of these that you and your customer agree. This avoids ambiguity in the future. Ambiguity around key responsibilities could haunt you in the future if you don’t sort them out clearly at the beginning.
– What will you be delivering? These could be physical items like paper-based books or camera ready copy, or it may be electronic files. It pays to draw up a schedule of deliverables which details the physical items you will be delivering and when they will be delivered. Remember, for each publication you are to produce, you will need to specify the delivery format, the specification or standard it will be written to and an outline or synopsis of the content of the publication including some indication of the depth of treatment that your descriptive and procedural text will have. All of this is to avoid that killer ambiguity later when you want your customer to accept the delivery.
– What will you need to be able to deliver? This could be the technical source data that you need to base your output on, or it may be specialist software that your customer has agreed to supply you with for use on the project. These are your dependencies. There can be a great number of dependencies that are not immediately obvious and may not always be the responsibility of your customer. For example, if you need a style guide to conform to; where will you get it from? Who will provide technical verification of your output? To help with this, it’s an idea to list all of your dependencies and for each item to list whose responsibility it is, at what point in the project you will need to have it available to you and a description of the impact of not having the dependency met in time.
– What risks are you running? Make a list of all the risks that you are exposing yourself to by taking on the project. Not all of the risks will relate to the project but may be secondary risks affecting other projects as a result of your taking on the new one. Risks are occurrences, which if realised, will have a detrimental impact on either the cost, quality level or time schedule of your project. Using the list, go through each of the risks and decide what impact each will have in terms of cost, quality and time, what the probability of its occurrence is, and what you can do to mitigate each risk. if it’s a serious risk with a high probability of occurrence you will be able to determine whether you need to include more in your price.
All of these approaches are basic project management planning techniques that many technical writers, especially freelancers, don’t address when planning and quoting for new work. By planning properly, you can ensure that you limit your potential exposure to a bad project and increase your customer’s satisfaction at the same time.