I whipped together a quick video to somewhat explain this idea.
video platform video management video solutions video player
Title: Managing the Design Factory Author: Donald Reinertsen Length: 288 pages Published: 1997 ISBN-10: 0684839911 ISBN-13: 9780684839912
This book analyzes product development processes from a lean perspective. The author starts by introducing the concept of a "design factory", which shows the differences between lean principles applied to manufacturing and lean principles applied to creating new innovations. The key differences include information arrival processes and the repeatable versus non-repeatable.
This is an idea that I read about in Managing the Design Factory (detailed outline). Around page 226, Reinertsen says:
Let us start with the first source of technical risk, the high-risk subsystem. Which subsystems have high technical risk? To assess this we must perform our project-level analysis to determine how each program objective (expense, cost, performance, and speed) will impact profits. Then we assess each subsystem to determine how it might impact each of these factors. The easiest way to do this is to use a team meeting in which members estimate the downside risk for each subsystem in terms of magnitude and probability. This can be done by having each member assess risks independently, having a discussion on why different team members have rated risk differently, and then having team members reassess risks. The output of such a meeting is a surprisingly good understanding of project risk. Contrary to the common view that unknown risks are most important, most teams are surprisingly aware of where they are likely to fail in a program.
On a long enough time line, the survival rate for everyone drops to zero.
Chuck Palahniuk, Fight Club
In the long run, every signal dies. Paper rots, genes mutate, forests burn, files corrupt. Error correcting codes help, but they aren't enough. Perfect preservation of effort is not the way of the universe. Human languages evolve and break down meaning.
Will my personal journal be lost in an accident following the poisson distribution within my lifetime? Will my grandchildren care enough to translate my life's work to the technology of the day before it is unreadable? There is a difference between preservation and the ability to understand, as Robert Scoble points out.
My friend Tyson works at a major insurance company. Recently he shared with me a technique that he uses there: He keeps a work journal to write down domain-specific things that he learns.
Journaling could include writing down a technique or rule of thumb used, a page of a book that was helpful in a certain area, or who to contact in a different department in case of questions in a specific area. Sometimes it could be something that went particularly well so that he can look back when times are tough and remember a time when he persevered. Other times it is something that didn't go as well as he hoped. He also does this to clarify his own knowledge so that when he needs information he has a place to look, and for potentially transferring that knowledge to other people.
I recently tried experimenting with this technique. I suppose that I like writing, so this came somewhat naturally. I liked separating this from other writing that I do because it seems useful to have it all in one place. I am just capturing knowledge that I have gained from working on a project. Writing this down regularly is really helpful in writing documentation later because you explicitly state what you have recently learned. This prevents me from being blinded to what I learned and taking it for granted. It might be obvious to me at the end of a project why the build works the way that it does, but along the way I needed to learn a lot of things and make various decisions. So this seems to be a good way of documenting decisions for later understanding and analysis of results.