Standardization of knowledge work

Standardization of knowledge work

28 April, 2015 3 min read
R&D

When we apply Lean Manufacturing ideas of standardising work on other functions, where work is more vague and creative, we are starting a slow drift towards a transactional, low-trust, controlling approach to work and relationships between teammates.

Standardisation of work in the context of product development implies the clean definition of work packages.

A work package ideally conforms to a SIPOC description and includes estimates of effort and duration, as well as roles and responsibilities.

Now, assume that there is an activity that happens in product development that you want to describe with a work package, because it is an activity that happens with every product.

The product cadence will affect the frequency of executing the work package.

If the work package is executed very infrequently, then a standardisation of this development activity is essentially capturing a best practice, and therefore desirable to an extent - as long as the activity can really be standardised at all and does not depend on the human factor of the development expert.

If the work package is executed very frequently, then there are two arguments to be made.

Note: “The execution of work depending on the human factor” means that the work content is such that the specific abilities, willingness, expertise and motivation of the person executing the work impacts the triple constraint of the activity to an overwhelming degree. I.e., that a disengaged person would possibly do work of high cost and/or low quality regardless of expertise, or a clear scope of the work to be done.

  1. If the work does not depend on the human factor that much, or at all, and it is an activity that anyone can do, then it typically should not be allowed to be part of the critical path of the product development work stream. Standardising or not is, therefore, of negligible importance, as that is not where the highest benefit is to be expected.

  2. If the work depends on the human factor, then this implies that the actual work cannot be easily replicated on a piece of paper - i.e., that the human factor acts as a black box within the micro-process of the activity, and involves the application of “expert rules” stored in the person’s mind or creativity, both of which cannot be planned or formalised. Additionally, if the work of that kind is frequent, then standardisation is not the primary concern. Rather, the following two are bigger concerns, obscured by the supposed need for standardisation: a) accelerating everything around the human factor and supporting the human factor by reducing lead times and increasing user-friendliness of the tools available (e.g. design rules, simulation tools), and b) managing the capture, re-use and flow of expert knowledge (to the extent this is possible) from the expert to colleagues working on interfaces of his work.