Knowledgebase

Managing Documentation as a Project Print

  • 0

Producing it systematically.

WHAT TO ESTABLISH

What documentation is needed Who writes it When it is produced Who reviews it Where it lives

WHY TIMING MATTERS

Documentation written after release is late and it is written without time.

WHAT TO ESTABLISH

That documentation is part of the work, not after it.

WHAT TO PLAN

Documentation alongside development.

WHY

The information exists then, and it is forgotten afterwards.

WHAT TO PRIORITISE WITH LIMITED CAPACITY

What users cannot do without What generates most support contact What is most error-prone What changes least, so the effort lasts

WHY THAT LAST POINT

Documenting rapidly changing areas consumes effort repeatedly.

WHAT TO ESTABLISH

A minimum standard rather than a comprehensive ideal.

WHY

Comprehensive documentation is rarely achieved and the attempt produces nothing.

WHAT MINIMUM USUALLY MEANS

Getting started The common tasks The common errors Reference for anything with values

WHAT TO ESTABLISH ABOUT OWNERSHIP

Who is responsible for each area.

WHAT TO PROVIDE

Templates and a style guide.

WHY

They reduce decisions and produce consistency across writers.

WHAT A STYLE GUIDE SHOULD COVER

Terminology Structure for each document type Formatting conventions How to write steps and warnings

WHAT TO KEEP IT

Short.

WHY

Long style guides are not followed.

WHAT TO MEASURE

Coverage against what users need Support contact on documented topics Corrections reported


Was this answer helpful?
Back

Are you happy with your experience? Leave us a review on Trustpilot.


Trustpilot