Lost Processes: A Formula One Example of Brain Drain

At many organizations I've worked with as a contractor, more than a few directors/managers refused to document business processes, saying "we're too busy to stop our work just to write down how it's done."

While workload pressures are real, the risk of serious brain drain from lost processes is also equally real, though not as immediately threatening. The following story shows the real damage of brain drain from lost processes, when workers change jobs/roles.

Surprisingly, this comes from F1 Racing Magazine (f1racing.com)! In a recent interview with Patrick Head, Engineering Director of the former Formula One World Champion team Williams [now Williams Toyota], I saw a Formula One example of brain drain from lost processes.

There were several factors in Williams' recent loss of engine partner BMW -- a critical setback in competitiveness -- but Head was shockingly frank about one in particular:

Some people had reached retirement age and so retired, and the people put in their place were much younger and didn't necessarily have all the method and procedure given to them in written form -- so a number of approaches we'd developed over many years departed with the people that retired and were not suitably replaced.

Willams BMW had arguably the most powerful engine on the grid in 2006, contending for the Championship as a top-3 team. After BMW left in 2007, the team dropped into the midfield and didn't win a single race.

So, I guess the relevant question for all businesses is, how much productivity do we sacrifice for process documentation, in order to properly manage or minimize risk of this kind of brain-drain damage?

Your Comments, please! :D

"Never Let a Good Editor Go" article on BATimes.com

"When documenting systems, quality assurance requires quality support people, especially final content editors. They are worth their weight in gold-edged certificates. If you are part of a large project that has a very large documentation aspect, learn to nurture, develop, and retain a good editorial staff, and do not forget to keep everyone's skills current on the tools you are using!..."
Read more of David Egan's article on BATimes.com:
http://www.batimes.com/index.php?option=com_content&task=view&id=179&Itemid=1
[full story requires registering with batimes.com]

I've seen many IT projects in many companies suffer terrible UATs and roll-outs exactly because end-user documentation was inadequate. Both business and IT execs are prone to cutting user-training from system rollouts [to "save money"]. They think a user guide written by the programmers can replace this training. Well, I don't think anyone needs to read this article to know how bad user guides can be these days. Good programmers don't really make good editors or writers. :D