Project Management & "The Software Mechanism"

Of course, "lots and lots and lots of books" have been written about "project management," and most of them describe "successes." So then, why is The Mythical Man-Month, a tome written circa 1975 about the spectacular failure of IBM's "OS/360" project, still in print?

There's a lesson to be learned here. And that lesson is: "software is different."

"Fundamentally(!) different!"

In fact, "software is a Mechanism."

In other words, it is "an autonomous, self-directing software machine," uniquely tasked with satisfying serious business requirements when the team that built it cannot directly influence it. (Imagine, if you will, "a game of Rugby that is going to be played by a robot." The team that built the robot is going to now push the Start button and then walk off the field.) When you stop and fully consider the implications of this, you begin to see why existing project management strategies, fully-applicable though they might be to the construction of any sort of physical thing, simply do not apply to computer software.

Full Disclosure: these ideas are actually not original to us. We first encountered them in a still-obscure eBook, Managing the Mechanism, first ePublished in 2012 by author Vincent P. North. The book is available on Amazon, on iTunes, and now – for the very first time – in PDF form right here.

When you drive your car down the road – (at least, at this writing! stay tuned!!) – there is for example a simple and direct mechanical relationship between the position of the steering wheel and the orientation of the tires. So, the designers of that [purely mechanical] mechanism can step away from their design-tables knowing that your car's steering wheel will always work. The linkage is mechanical. The car does not "decide, based on your 'input,' how to" position the tires. So, your task as a project manager is relatively simple: unless a bolt breaks somewhere, nobody's gonna get hurt.

But the very-unique problem with "software mechanisms" is that you can never say that. Computer software does "respond" to its inputs, and its final outputs are determined by if..then..else. However, in mechanical terms, a software mechanism is hideously complex. Virtually every part could be connected to every other part. Untoward influences could come from parts of the software that are "within your scope and purview," or from those that are not. In mechanical terms, a software mechanism has almost-unlimited "degrees of freedom" in its "motion."

Thus, effective software project management must consider far more factors than merely the "user stories" that most pundits easily talk about. "User-oriented requirements gathering" views the problem from the point-of-view of one operator of the software machine, but this is not enough to determine how to modify the innards of the software machine itself. The software project manager must maintain control not only of the change-request stream but also the actual changes that are made to the software source-code itself. The software must be made to transition from one "provably known-good state" to the next.

These are, very simply, "things that you won't find discussed in the PMBOK®." Neither will you find them adequately dealt with by common methodologies like "Agile" and "Scrum." But you will find them well-treated in Mr. North's little book.

Probably the most vexing problem with software is that "virtually everything could be affected by anything else." Software systems contain multiple layers of concern, of which "the user interface" is only the topmost surface. The true effects of even the most innocent-looking change could be very great ... and, might not be detected unless a very rigorous testing plan is constantly on the lookout for so-called "regressions." This is not the sort of thing that a project manager ordinarily has to think about. But, as it turns out, "computer software is a profoundly fragile thing!"