Lean PPM – step 10: Consumers of documentation and their needs

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.