Tikalon Blog by Dev Gualtieri

Doing it by the Numbers

March 21, 2016

Nearly everyone, when confronted with the acronym, CPA, will think, Certified Public Accountant. A very small number will think Critical Path Analysis, sometimes called the Critical Path Method. This program management method is a way to find bottlenecks in a process so that they can be adequately addressed.

Essential elements of what became the Critical Path Method can supposedly be traced back to the Manhattan Project. NASA used the Critical Path Method in completing the Apollo 11 Project that landed the first men on the Moon. It's reported that this project involved two million tasks,[1] and I can't manage to shave and eat my breakfast simultaneously.

Buzz Aldrin, NASA image AS11-40-5903, processed by Eric Nelson

Buzz Aldrin of Apollo 11 on the Moon.

The original image was processed to enhance contrast of the faceplate area to reveal the blue dot of Earth, just seen at top edge (Click for larger NASA image).

(March 22, 2005, NASA image.[2])

While project management in those early days was handled using index cards and huge wallcharts, project management applications were among the first types of software for desktop computers. A colleague and I wrestled with one of these applications in the 1980s, since it was a requirement for a government project. Later, our employer required the use of Microsoft Project to generate Gantt charts for our projects, something that was more hindrance than help when doing research. I've also used ProjectLibre, a free and open source replacement for Microsoft Project.

My father was a building contractor who worked in an age before desktop computers. Even if his career had extended into today's reign of ubiquitous computing, he would still have used his version of program management that he called "doing it by the numbers." What he meant by this was that a daunting task like building a house from its foundation up is actually a series of small tasks. You start with task no. 1, and continue through all tasks until the house is built.

I was reminded of program management when I read Robert Lucky's article, "Planning for Greatness," in the January, 2016, issue of the IEEE Spectrum.[3] This article is a commentary on the book, "Why Greatness Cannot Be Planned: The Myth of the Objective," by Kenneth O. Stanley, an associate professor of computer science at the University of Central Florida, and Joel Lehman, an assistant professor at the IT University of Copenhagen participating in robotics and computer games research.[4] The thesis of the book is that setting objectives for projects discourages innovation.

Robert W. Lucky.

Lucky, a Bell Labs alumnus who was a vice president at Telcordia Technologies, is a well known electrical engineer and a member of the National Academy of Engineering.

(Via Wikimedia Commons.)

In the Apollo program, there was definitely a goal of putting a man on the Moon, thus, all the attention given to program management. Every engineering project, from building a bridge to producing the next generation computer chip, has a goal. As Lucky correctly observes, you're not going to write a winning proposal if a goal is not included.

Stanley and Lehman write that innovation can't come from projects that state a objective. I think the problem rests with the definition of the objective. If the objective reads like a specification for a bolt, in the end you'll get a bolt. As Lucky writes, if the objective is wireless communication (Marconi) or a solid state replacement for the vacuum tube (John Bardeen, Walter Brattain, and William Shockley), innovation will result, since the path to the objective has not be etched into a stone Gantt chart.

One feature of the Stanley-Lehman model is that progress supposedly arises through the intermediate step of creation of a series of stable points that they call "stepping stones." These stepping stones are created by a type of engineering that might be called "normal engineering" (c.f. Kuhn's "normal science" in The Structure of Scientific Revolutions).[5] Innovation is created by assembling these stepping stones into a new product not foreshadowed by any objective.

Isaac Newton, oil portrait by Godfrey Kneller

One person who believed in something like the stepping stone principle was Isaac Newton (1642-1727).

In a 1676 letter to Robert Hooke , Newton wrote, "If I have seen further it is by standing on ye sholders of Giants."[6]

(A 1689 portrait of Newton by Godfrey Kneller (1646–1723), via Wikimedia Commons.)

While Stanley and Lehman seem to advocate a near willy-nilly exploration in science and engineering just to build more stepping stones in the hope that they will eventually be useful, this approach can be reconciled with the usual program management scheme. We just need to equate the stepping stones with perceived tasks needed to complete a desired, but nebulous goal, as in the radio and transistor examples above. In this case, the timeline is as nebulous as the goal, and we're talking about really large projects of the type that Bell Labs once funded, but no longer exist.

In the 1990s, NASA administrator, Dan Goldin, introduced a "Faster, Better, Cheaper" initiative designed to improve NASA programs by reducing their complexity.[7] This approach seemed to work, and the reason it did work is that programs were allowed to fail; that is, the objective would be nice to have, if you could do it, so just try your best. The similarity of this to the objective-free approach of Stanley and Lehman is apparent.

Doing it by the Numbers

References: