PowerPoint Engineering Considered Harmful

I have always been inspired by Edward Tufte's work. As an engineer in the aerospace industry, successfully working in large organizations (read bureaucracies) is a necessary skill. Unfortunately, bureaucracy has its own particular pathology. The trick is to not catch the diseases yourself while at the same time thriving in close proximity. In that vein, I have lately been considering the Cognitive Style of PowerPoint, which is a popular tool in the industry.

Everybody likes to beat up on NASA, and there's plenty to find fault with (as there is in any bureaucracy). Honest past criticism from a much admired physicist:

It appears that there are enormous differences of opinion as to the probability of a failure with loss of vehicle and of human life. The estimates range from roughly 1 in 100 to 1 in 100,000. The higher figures come from the working engineers, and the very low figures from management. What are the causes and consequences of this lack of agreement?
...
Let us make recommendations to ensure that NASA officials deal in a world of reality in understanding technological weaknesses and imperfections well enough to be actively trying to eliminate them. They must live in reality in comparing the costs and utility of the Shuttle to other methods of entering space. And they must be realistic in making contracts, in estimating costs, and the difficulty of the projects. Only realistic flight schedules should be proposed, schedules that have a reasonable chance of being met. If in this way the government would not support them, then so be it. NASA owes it to the citizens from whom it asks support to be frank, honest, and informative, so that these citizens can make the wisest decisions for the use of their limited resources.

For a successful technology, reality must take precedence over public relations, for nature cannot be fooled.
-- Rogers Commission, Appendix F, by R. P. Feynman

The same "debt of honesty" that Feynman claims NASA owes the public can be reasonably attributed to any organization towards their stakeholders. Pretending the problems experienced by this particular organization are isolated would be foolish. NASA does provide an accessible case study of an organization being firmly infected by the pitch culture though. Others might put it as the triumph of the personality-ethic over the character-ethic, style over substance.

From a more recent report precipitated by disaster:

The Mission Management Team Chairʼs position in the hierarchy governed what information she would or would not receive. Information was lost as it traveled up the hierarchy. A demoralized Debris Assessment Team did not include a slide about the need for better imagery in their presentation to the Mission Evaluation Room. Their presentation included the Crater analysis, which they reported as incomplete and uncertain. However, the Mission Evaluation Room manager perceived the Boeing analysis as rigorous and quantitative. The choice of headings, arrangement of information, and size of bullets on the key chart served to highlight what manage- ment already believed. The uncertainties and assumptions that signaled danger dropped out of the information chain when the Mission Evaluation Room manager condensed the Debris Assessment Teamʼs formal presentation to an informal verbal brief at the Mission Management Team meeting.
-- CAIB Report, Vol. 1, pp 201

Any technical organization will have trouble clearly and accurately communicating technical information to decision makers, who most likely are not experts in the particular domain being addressed, and often are not even technically competent in any speciality. Even when they are experts, using an inappropriate tool never helps.

From Thomas Ricks' book Fiasco:

[Army Lt. General David] McKiernan had another, smaller but nagging issue: He couldn't get Franks to issue clear orders that stated explicitly what he wanted done, how he wanted to do it, and why. Rather, Franks passed along PowerPoint briefing slides that he had shown to Rumsfeld: "It's quite frustrating the way this works, but the way we do things nowadays is combatant commanders brief their products in PowerPoint up in Washington to OSD and Secretary of Defense...In lieu of an order, or a frag [fragmentary order], or plan, you get a bunch of PowerPoint slides...[T]hat is frustrating, because nobody wants to plan against PowerPoint slides." That reliance on slides rather than formal written orders seemed to some military professionals to capture the essence of Rumsfeld's amateurish approach to war planning. "Here may be the clearest manifestation of OSD's contempt for the accumulated wisdom of the military profession and of the assumption among forward thinkers that technology--above all information technology--has rendered obsolete the conventions traditionall governing the preparation and conduct of war," commented retired Army Col. Andrew Bacevich, a former commander of an armored cavalry regiment. "To imagine that PowerPoint slides can substitute for such means is really the height of recklessness." It was like telling an automobile mechanic to use a manufacturer's glossy sales brochure to figure out how to repair an engine.

This raises some of the same issues discussed in the report by members of the NASA Return to Flight Task Force in the contribution at the top of this thread.
-- Edward Tufte, August 11, 2006

Writing a good technical report or white-paper takes thought and hard work. Clearly communicating intent with effective mission orders takes initiative and competence. Throwing bullets on a slide is the path of less resistance (I say this as someone who has regrettably succumb to this temptation on more than one occasion). It is also the refuge of the bureaucrat "of an entirely different character" planning to profit from ambiguity and disingenuous politicking.

Knowing a thing is bad is nice in a theoretical way, but what about actually doing well because of that knowledge. How to effectively communicate technical results to hurried managers? I think the Tufte-inspired handout format is a nice start. Doing a good job of tightly incorporating relevant graphics into succinct narrative is probably the best an engineer can do. Improving the report to the point that it isn't a long-winded, dry, snooze-inducer means that management may actually read it, and their decisions may benefit from it. Of course, the hand-out can reference more in-depth technical documents for the competent, curious and critical reader.