These questions can help you estimate the time you will need to complete a documentation project.

On average, documentation accounts for approx. 10% of the effort in a software project, meaning that documentation plays a crucial role in the overall cost. Estimating the time and effort a documentation project will take is no mean feat, but you can use some metrics to help you give a ballpark figure.

Although methods for time estimating already exist (e.g. top-down, bottom-up design, minutes/hours design), too many factors may come into play and affect the original estimate. Answering the following questions can make your estimate more accurate and well-grounded:

  • Are there any existing tech specs to support the creation process of the documentation?
  • Are graphics, screenshots or videos needed?
  • How many writers can take part in the project? How much time can each of them devote to it? How much experience do they have?
  • How complex is the project? Are the writers involved in the project subject matter experts or will they have to invest time in learning the tool/technology used?
  • Are the people who can provide the necessary information to the writers available at that point in time? How many meetings will have to take place?
  • How many tasks are needed?
  • Are you going to create a new manual from scratch or do you have to update an  existing version of the documentation?

Using a planing tool can help you estimate future projects based on the duration of previous ones. You can compare planned and actual estimates and analyze the factors that caused your project to take longer than expected. A planing tool can also help you justify the time and resources needed to complete the project.

De media, la documentación supone un 10% del esfuerzo de un proyecto de software, por lo que las estimaciones para su realización tienen una gran importancia en el coste final del mismo. Estimar el tiempo y esfuerzo que te llevará realizar un proyecto no es una tarea fácil, No obstante, puedes utilizar algunos parámetros que te ayudarán a calcular un dato aproximado. 

Aunque ya existen algunos métodos para la estimación temporal de un proyecto de documentación (por ejemplo, diseño arriba-abajo/abajo-arriba o minutos/horas), son muchos los factores que pueden entrar en juego y afectar a la estimación inicial. Responder a las siguientes preguntas puede hacer tu estimación más precisa: 

  • ¿Existen especificaciones técnicas que puedan ayudar en la creación de la documentación?
  • ¿Es necesaria la creación de gráficos, pantallazos o videos?
  • ¿Cuántos redactores pueden participar en el proyecto?¿Cuánto tiempo puede dedicar al proyecto cada uno de ellos?¿Cuánta experiencia tienen?
  • ¿Qué complejidad tiene el proyecto? ¿Los redactores involucrados en la materia son expertos en el tema o tienen que invertir tiempo en aprender a utilizar la herramienta/la tecnología?
  • ¿Qué disponibilidad tienen las personas que pueden proveer información a los redactores?¿Cuántas reuniones deberán celebrarse?
  • ¿Cuántas tareas son necesarias?
  • ¿La tarea consiste en crear un nuevo manual desde cero o tan sólo es necesario actualizar una versión existente de la documentación?

Utilizar una herramienta de planificación puede ayudarte a hacer una estimación de proyectos futuros, ya que podrás basarte en la duración de proyectos anteriores. Puedes comparar estimaciones planificadas con las reales y analizar los factores que causaron un retraso en el proyecto. Una herramienta de planificación también te puede ayudar a justificar el tiempo y los recursos necesarios para completar el proyecto.


Technical Writing

– Hi! What do you do?

– I’m a technical writer.

– Ah, ok! (No idea what she really does, he thought).

When having a conversation with someone for the first time, I always love to see his/her face when talking about my job. When I see a gaze of perplexity (which is quite common) I use to put it simply: I write instructions to help people learn how to use something.

Yes, I know, this may be an inaccurate description of my everyday activities, but it works. A usual reaction is:

– Oh, I see! You write these instructions nobody really cares about until something doesn’t work anymore or they can’t figure out by themselves what to do next.

– Well, actually, the right way to go would be to read the documentation before…Anyway, now you know what I do 🙂

Joking aside, to me technical writing means much more. When I write, my main goal is to help people find solutions to problems. I don’t mean to teach anybody (although I love teaching) but to help them fix what’s wrong or just show them how to use something they need in a clear and concise way.

What I really love from technical writing is the “how”. How to get the necessary information from developers, understand and organize it, how to write good examples to improve understanding, how to create supporting graphics, how to understand the customer needs and provide the type of information they really want…and of course how to translate the English text into other languages for an audience with a very different background. That’s challenging but also a lot of fun!

(Spanish version below)

Continue reading Technical Writing