One of the difficulties when creating documentation plans is determining the correct figures for the amount of work involved. For example, if you’re creating a user guide for an application you know quite well, then it’s easy to estimate the amount of work involved. And if you’re doing the writing, then you can also gauge how fast you can write the documents.
But what happens when don’t know the specs, haven’t seen the software, and won’t be writing the documents?
Here are some things to consider:
- Requirements – have these been signed off yet? If not, flag that your dates are based on the current requirements and will change if the requirements are modified. This is probably the most serious factor to consider when estimating the amount of effort required.
- Scope – clarify what is in the scope of the document plan and also what will not be delivered. Why? This removes any assumptions other line manager and business owners may have. If they want to change the scope, then fine, you can do that but it means updating the document plan.
- Software – make sure you have licenses for any authoring tools before you start, for example, if you’re running a globally distributed team and you want everyone to use the same version of FrameMaker. Otherwise time will be lost.
- Deliverables – do you need to develop both PDF and/or online help? While, in theory, both of these can be created from the same source, there is usually some extra effort to refine the PDF and to save them in the correct directories if you plan to share them from the online help.
- Revision – if the documents will be revised by subject matter experts, who are not under your control and who may impede your progress at some point, allow time to chase up these parties and, if necessary, allow time to show them how to use revision software or the revision tools in applications such as Acrobat.
- Conditional Text – if you plan to conditionalize the content allow time to check the outputs if the content will be significantly different.
- Resources – identify the names and roles of team members and confirm if these have been assigned to the project.
- Activity breakdown – list all of the documents and content types you plan to deliver. For example, User Guide in PDF and Online Help, Release Notes in PDF only. Admin Guide in Online Help only. If it helps, create a matrix to illustrate what will be delivered. Note that you may also factor in other deliverables and formats, such as for mobile devices if this will require extra effort.
- Time estimate – identify the start and end dates and, most importantly, any dependency you have on other departments. For example, if Development is late in providing working software, does this affect your timelines? If Business Analysts are late or change the requirement, what impact will this have? If Tech Support is unable to provide a staging environment to test the online help, how will this affect your dates?
- Printing and Production – if you have to outsource the printing, and for example, packaging, then factor in the costs and turnaround times. Also include any contingencies if they are unable to provide this service for whatever reason.
Documentation Planning
Essentially this is just common sense, isn’t it?
From one angle it’s a project plan for a set of documents. What you need to be aware of are any potential impacts on your schedule and interruptions that may undermine your efforts.
For example, if you are writing two sets of documents for two different projects at the same time, allow for the fact that the stopping and starting and switching from project to project will interrupt your progress as you lose momentum every time.
You need to anticipate things like this as on paper it should make no difference, but in the real world it will undermine your efforts.
PS – Download your Documentation Plan Template here.