Five monkeys are caged together and there are some bananas hanging from the top of the cage. Some scientists attach an automated device for sensing if the bananas are moved; once a monkey tries to get any, an electric shock travels through the cage so that all monkeys get shocked. In the beginning, a single monkey climbs up to the bananas, touches them and every monkey gets shocked. So he doesn’t try anymore, but the other four monkeys try the same thing and the result comes to be the same. Therefore, the monkeys learn something in common: that is, do not get the bananas! You’ll get a painful electric shock! The scientists then replace one of the original monkeys with a new one. This new monkey sees the bananas and wants to get them right away, but the other four monkeys beat it when they see its actions. Since these original four monkeys think the new monkey will make them get shocked, they stop the new monkey from getting the bananas. This monkey tries a few times and the others beat it every time without it ever getting the bananas. Of course, all five monkeys don’t get shocked. The scientists then replace another of the original monkeys with a new one. This second new monkey sees the bananas and you bet it wants to get them immediately. But, sadly, the others beat it and the first new monkey beats the newest one even harder then the others (for the newest one is the rookie and has the lowest social status). Just like before, the newest monkey tries several times to get the bananas and is stopped by the others when they attack him. The scientists continue to replace all the original monkeys until no monkeys who actually felt the electric shock remain. Now none of the five new monkeys dare to touch the bananas yet none of them know why. They only know whomever wants to get the bananas will be beaten.
An interesting thought; has anyone else tried to implement it fully rather than piecemeal? Certainly it sounds a good idea and one to try on my next project.
If you come into FreeBSD and commit non-style(9)-compliant changes, people will yell at you. Most of the time people don't know why style(9) says what it says, but still zealously insist on it being followed.
There's one, maybe two FreeBSD developers who know the reasons behind most of style(9), and that's because they have been working on FreeBSD for 30 years -- since long before it was called FreeBSD. The rest of us have simply learned to follow it.
I'm not sure whether you are defending or criticizing this state of affairs. I wouldn't understand the former and expect action in case of the latter. Why does this state of affairs persist?
You want to see the most perfect example of how to document process? Get hold of a copy the McDonalds franchise operations manual. It is a genuinely beautiful artefact. There is literally no aspect of running a burger restaurant that isn't in the ops manual; How the parking lot should be managed, how employees should wash their hands, how a hand-cart should be unloaded. Almost every sentence speaks of a lesson learned the hard way, ten thousand little edits because of a lawsuit or a process bottleneck or a QA problem. It's an incredible example of what happens when you take something simple and spend several decades optimising it.
Interestingly, in many franchise operations, you are paying not just for access to brand and supplier relationships, but for that mighty operations manual. In effect, you are paying for the right to use their vetted process for your own business. Some of the contracts reserve the right to sue if you leave the franchise, set up your own business with very different brands and suppliers, maybe even a different vertical... but still can be shown to be using their process.
Not quite the same, but this fifty-page document is what they use every six months to check up on every franchise.
Fun fact: if you fail this, your franchise fee to McDonald's Inc goes up. If you keep failing, your fee keeps rising and eventually gets high enough to make your business fail. At that point home office takes over and runs it by the book or sells it on to someone who will.
Nice to know. What if you pass the review with flying colours after you failed last year? Will you be able to reverse the franchise fee rise?
Fun fact: When a McDonald's is closing each day the staff has to pack up all the sauces, meats, bread, etc. When I worked there, to get home early, in the last hour I pour the tomato sauce and some of the mustard from the containers (which needs to be emptied and washed), mix them into a cup and put them on burgers with a plastic spoon.
By doing this the containers could be washed earlier.
I expect they reverse the rise if you are doing well. After all, they don't _want_ to take over your McDonald's - they want you to run it right. But I don't know this for certain.
Business answer: With everything, including this, there needs to be a balance. The ROI on documenting every single inch of progress as accurately possible is extremely low in most cases. Additionally every case (industry, business, project) is different and one size doesn't fit all.
I agree that there has to be a balance to how much an organization documents. But I'm more concerned with how little organizations read than how little they write. If they wrote a little less, they might read more.
Maybe instead of voluminous meeting minutes, organizations should have a little notebook labeled "Why we decided what we did."
1) If the record is not electronic, there is no way to share it and typically no way to discover it. Manual search of paper documentation sucks.
Before Al Gore invented the interwebs, I kept lots of notes in notebooks. I almost never shared the notes and almost never referred to them after the development phase of the project ended.
I now use a wiki and "issues" in a tracking system (e.g. Redmine) to keep my "engineering notebooks". This has proven invaluable time and again.
2) The importance of decisions is mostly discovered in retrospect. :-( I find many holes in my notes when I do something a second time, even when I think I'm keeping good notes the first time. The good news is that my notes are pretty good after the second pass.
3) I don't know if it is laziness, inconvenience, or otherwise, but my experience is similar to the OP in that I tend to take fewer notes that I should and I have a hard time getting my coworkers to take half as many notes as I take. :-( Again, I find an electronic notebook open in a web browser on the desktop you are doing the work on is much more effective than paper and pen.
I started using Tomboy notes (and recently Gnote) to write short notes. They have a good, quick search built in to lookup old notes. They are easy to backup as well (copy .tomboy/ or .gnote/ subdirectory from home diretory).
And who decides what goes into that notebook? In a committee of 10 people you'll have at least 10 and usually far more reasons for and against any significant proposal.
Maybe a committee could include a brief summary of pro and con arguments, sort of a miniature version of the legal practice of consenting and dissenting opinions.
On the other hand, I could understand why some organizations would be afraid to do this. They don't want to write down anything that could look bad in the future as part of a legal discovery. In that case, there's an incentive to promote institutional amnesia.
Most decisions in business end up being arbitrary anyway. Humans are largely irrational creatures who make choices on emotion. I am not sure you can properly document why a given choice was made, and even if you can, it is of little interest to future readers who come with their own set of emotions.
Another option is to document the failures to warn future generations. However, as the article points out, things change rapidly. What didn't work yesterday might be the perfect solution tomorrow.
It's fun to think of candid rationales. "We did this because Joe bullied us into it. When he leaves the company, we're undoing it the next day." Or "Sue was able to keep her wits later in the evening than the rest of us, so we agreed to anything she wanted just so we could go home and sleep."
Capturing this kind of knowledge - especially from ad-hoc decision making - for future reference is an explicit goal of SAP's Streamwork product. It is of course open to question whether that goal is achieved, but certainly SAP (as an organization very focused on the way businesses are run) are very aware of this problem and actively trying to provide a solution.
(Disclaimer: I was the lead architect for the initial release of Streamwork, but have since left SAP.)
It's difficult to document all the factors that go into a decision because some are common context (and tedious to document all such assumptions). Over time, context changes.
In addition, decisions that turned out to not work are abandoned; decisions that work are kept... showing that the reasons for making the decision may not be the reason it works.
The article assumes we know what we're doing, top-down rather than agile/lean.
The problem often becomes that even if it is written, the documentation is rarely or never read. People then wonder if they should write more or less and why it is this way. I think one of the problem is we think we are finished after we write it. I would like to see a place where someone went over the documentation and rewrite it to extract the cultural references instead of the specifics of one situation. The documentation would be more about how to react than what to do exactly.
I'm not interested in insulting the author, who's probably a nice guy. But I've been conditioned to expect very little content when I click on a link and his picture pops up, so I'm just wondering what the deal is.
Five monkeys are caged together and there are some bananas hanging from the top of the cage. Some scientists attach an automated device for sensing if the bananas are moved; once a monkey tries to get any, an electric shock travels through the cage so that all monkeys get shocked. In the beginning, a single monkey climbs up to the bananas, touches them and every monkey gets shocked. So he doesn’t try anymore, but the other four monkeys try the same thing and the result comes to be the same. Therefore, the monkeys learn something in common: that is, do not get the bananas! You’ll get a painful electric shock! The scientists then replace one of the original monkeys with a new one. This new monkey sees the bananas and wants to get them right away, but the other four monkeys beat it when they see its actions. Since these original four monkeys think the new monkey will make them get shocked, they stop the new monkey from getting the bananas. This monkey tries a few times and the others beat it every time without it ever getting the bananas. Of course, all five monkeys don’t get shocked. The scientists then replace another of the original monkeys with a new one. This second new monkey sees the bananas and you bet it wants to get them immediately. But, sadly, the others beat it and the first new monkey beats the newest one even harder then the others (for the newest one is the rookie and has the lowest social status). Just like before, the newest monkey tries several times to get the bananas and is stopped by the others when they attack him. The scientists continue to replace all the original monkeys until no monkeys who actually felt the electric shock remain. Now none of the five new monkeys dare to touch the bananas yet none of them know why. They only know whomever wants to get the bananas will be beaten.
An interesting thought; has anyone else tried to implement it fully rather than piecemeal? Certainly it sounds a good idea and one to try on my next project.