Information Developers in their work oftentimes stumble upon the cases when content creation may seem to be a much easier task than predicting how much time it would take. And usually, it happens when we are involved in a new project or in the presales activities, but it’s also a part of our routine activities on any project.
The first temptation is to use the industry averages like 4 hours per a help topic. But are you sure this will work for your project?
It’s the estimation phase when you have to employ all of our knowledge, experience, and a little guess to provide detailed and precise estimates.
When working on estimates, you never feel sure and always feel the lack of information. It seems that you cannot provide valid results within the given time frame. But in fact, you can if you’ve got a framework of what things to consider when estimating.
To start with, identify who your documentation is for. This will help you obtain the big picture of the project as well as identify what content type will best meet the end users’ needs. Answer the following questions:
- Who will be the target audience?
- What is their background (experience with PC, experience in the industry, etc.)?
- What user roles can be identified?
- Will you have access to the end users?
- What problems and business needs will the developed software solution solve?
- How can the documentation help make the users’ experience with the application more pleasant?
As a result of this analysis, you may create user personas by roles they perform in the software application. This will help you keep your users in mind when creating content on the further stages.
After that, review all of the information and resources at hand:
- Are there any publication standards established on the project: style and writing conventions?
- Should a Style Guide be created for documentation on the project?
- Are there any documentation templates that should be used on the project? If no, are there any specific requirements to the template that should be created?
After you’ve got answers to these questions, move to considering all of the life cycle stages that the content will live through.
Document Design stage
- Template creation/update/analysis.
- Skin and CSS stylesheet creation/update/analysis.
- Documentation project setup (for single sourcing documentation solutions).
- Documentation outline creation for each of the deliverables.
- Graphics that will be required (diagrams, flowcharts, screenshots, etc).
- Documentation environment configuration.
- Documentation source control setup.
Document Development stage
- SME interviews or application trainings.
- Creating content.
- Document navigation and searchability: index, navigation, gathering user feedback, etc.
- Creating custom graphics.
- Peer-review, SME review, Customer’s review.
- Final documentation testing.
- Documentation compilation and troubleshooting.
- Help System context-sensitivity testing (if applicable).
- UI text review.
Document Delivery stage
- Documentation acceptance testing.
- Document Maintenance stage (only for long-term projects):
- Analysis of updates to the software solution.
- Corresponding updates to the documentation.
This list has proven its effectiveness multiple times and allowed me to provide detailed, thorough, and precise estimates for numerous projects.
What’s important, you should always enrich this list with the lessons learned from every project or presale. Thus, you’ll get a base that will make your estimate more precise with every next request, and it will not seem to be such a scary and difficult task to you anymore as you’ll be sure that you haven’t missed anything in your estimate.
Have you got other important tips in mind that this list doesn’t include and that you would like to share? Do include them in comments – your feedback is very important!