Documenting the Why

---

Why on car
Originally uploaded by openpad

One of the pieces of knowledge which is seldom captures is Why things are done.

We often capture design data and information, we capture process and procedure, and we capture what has to be done, and by whom. But often we omit the Why.

An example comes from deepwater drilling back in the 90s, where one part of the organisation was learning from another part about a particular technique. The details of the technique were transferred, but not the reasoning behind it, and so the technique was applied in an inappropriate location, and didn't work. One of the partners involved with the well, however, picked up the technique and its rationale, and applied it successfully, at a saving of several million dollars compared to the previous technique.

If we capture the What of a technique, but not the Why, then

a) others can use it in the wrong situations
b) others can tinker with it, without understanding, and undermine the technique
c) when circumstances change, nobody knows how to adapt the technique
d) the technique can be applied long after it needs to be.

Its like the story of the cat in the monastery.

"When the spiritual teacher and his disciples began their evening meditation, a cat who lived in the monastery made such noise that it distracted them. One day the teacher ordered that the cat be tied up during the evening practice.

"Years later, when the teacher died, the cat continued to be tied up during the meditation session. And when the cat eventually died, another cat was brought to the monastery and tied up. Centuries later, learned descendants of the spiritual teacher wrote scholarly treatises about the religious significance of tying up a cat for meditation practice".

In this story, the practice has continued, because they lost the Why

So how do you capture the Why? I have seen this done using a document called Basis of Design. This captures the rationale behind a design of equipment or design of a process. It explains why the design is the way that it is.

Now many projects create a Basis of Design (BoD) document at the start of the project, as a preliminary document, but often the design itself evolves and is adapted to circumstance. The key to using BoD as a knowledge asset is to make sure that changes are reviewed, and the reasons for changes are captured.

In BP drilling, the Basis of Design was frequently used to capture decision making and the rationale behind well design, in case there were a gap in operations, and people had to come back later and start drilling again. In the past, what often happened was that knowledge would have been lost in the interim, but as one Alaskan drilling engineer said to me, "With a good Basis of Design, I could come up to this field and put a quality well program together in a week, and there hasn't been a rig drilling here for two years".