In my last
blog I pointed out why there is a need for documentation. What we at digitec Galaxus figured out during the last year
working with our Lean PPM system was:
- Who concrete are the target reader of a type of information
- What abstraction level and format does a target reader prefer to use
- What tools and environment does a target reader prefer to use
- What tools and elements do we already use in our Lean PPM that offer options for documentation
Based in
these findings we now agreed to establish some rules how we want to deal with
the topic documentation. I guess in many organizations the situation is
similar, so hopefully my blogs about documentation are useful.
At this
point I have to say this is nothing new about documentation in any way. Already
before agile and lean these findings were well known. The very basic concepts of
documentation are:
- Create a documentation only if there is a consumer that gets value out it
- The documentation must meet the needs of a consumer in respect of amount and abstraction level of information, the format and the tool to use
- If a user searches an information within the documentation, the documentation must support a structure and search so that the consumer will find the information easy and fast.
Sources
that address these basic concepts are for example the International Requirements Engineering Board
IREB e.V. in its foundation
certification, the International Institute
for Business Analysis IIBA with its BaBOK, or the differentiation
between a product repository and a project repository as recommended by the International Software Product Association
ISPMA.
Instead of
listening to the needs and requirements of the human sources and sinks of
documentation many organizations instead go primarily for standardization and
the satisfaction of compliance constraints. From my experience organization should
care to develop good documentation practices for the workforce with first
priority and with second priority to be compliant to external constraints. In
my experience it is always possible to transfer a documentation that follows
good documentation practices into a format that as well satisfies external
compliance constraints.
Funny that
so many organizations and companies disregard the basic concepts as listed
above. From my experience the overwhelming compulsion to create standards and
satisfy compliance constraints outreaches the objective consideration that an
unbalanced harmonization ends up in more drawbacks than benefits. Especially
the demonic one-fits-all thinking that still creeps through the management
floors – as well in respect of documentation…
A year
before today we created documentation at digitec Galaxus following good practices only partially. We
used epics and user stories in software development, we tried to avoid
exhausting documentation in the requirements and design phase – but we did not
follow good practices that support all types of consumers of our documentation.
In the last year while establishing our Lean PPM, we discovered basically three
different types of consumers. I use the terminology of digitec Galaxus as described my blogs “The value stream of the digitec lean
portfolio Kanban system”, “The life cycle of an initiative” and “about project leads and business
analysts...”. There
is one blog dedicated to every consumer type.
