|Developer Diary · You Heard It Here First · 9 December 2003|
|Complex Problems Have Complex Solutions|
Yesterday I wrote about how bugs will make mincemeat of any purported project schedule and that most non-programmer managers have little or no knowledge of their greatest enemy. The following evening I was in a bookstore and wanted to verify this. After all what do I know about project management? I had never so much as turned a page of a book on PM. For all I knew PM books were full of good advice for identifying and coping with bugs. (Having dealt with a lot of suits educated in the worldly ways of PM I strongly doubted it, but hey let's give them a chance). So at the book store I browsed a bunch of the latest books on managing software development. The reality was even worse than my imagination: not a single one of the books even had the word "bug" in the index. All of the books had "PERT" in the index. As far as I am concerned this totally validates what I said yesterday. Let's dig into this can of worms some more because it will teach us something important about how to go about not just writing software, but about accomplishing any complex project.
Of the books I saw at the store there were two main types. One type tended to see people management as the solution to the software problem. If you had a problem it was because you were not managing your people right. The other type saw project management as a blizzard of schedules, timelines and charts. The first type gave all reasons for project failure in human terms ("the team lacked synergy"), whereas the second explained failures as being caused by omitting key things from the charts. The first type presented software development largely as an exercise in psychology ("How to Cope with a Difficult Team Member"), and the second provided extensive advice on the best use of PM tools like Microsoft Project and Rational Rose.
One of the things I found amusing in the efforts of these authors is their apparent ignorance of the history of large projects which spans the length of human existence. You would think from reading these books that noone had managed a joint effort until the advent of software development a few decades ago. To me these fellows seemed like babes in the woods compared to the hoary old man of collective effort: the army.
The American army has been solving tough problems for 350 years and the British army a lot longer than that. I once had the experience of being exposed to a highly unorthodox passive test that was used on potential recruits for the U.S. Army Special Forces. I won't go into details here on this test (which I passed by the way) but the upshot of it was the moral that there is no shortcut or special solution to solve your problem for you: complex problems have complex solutions. Creating artifices or crutches like elaborate schedules are just ways of avoiding the real work of solving the problem and are the likely tools of posers and excuse-makers. The essential point of the Special Forces test was to separate people who liked to dive in and do real work from those who lean towards artifices like Microsoft Project. This teaching is as old as the pyramids yet precious few know it even today.
An interesting aspect of the lore of PM is how it's proponents coopt the army as a supposed founder of their techniques. For example, the Manhatten Project is often cited as one of the first to have used "advanced project management methods"--whatever that means. In my own reading of biographies of the participants of that project I find quite the opposite. The leaders of the project when writing about it stress that any kind of formal management was poo-pooed as childish and that everyone knew what needed to be done and just did it. Nevertheless you can read any number of PM authors who give the Manhatten Project as one of their great success stories.
I can understand why this is so. There is natural revisionist tendency to go back to a complex and chaotic process and find order and method where it never existed. For example, a big proponent of over-organization and a father figure to the PM types is legendary physicist Lee Davenport who is credited with all kinds of PM advocacy, but read what he said in an interview about his own life:
Bryant: What did you put on paper to schedule a project?
Davenport: You raise a very interesting point. A tremendous amount of this work was done in one's head because the identification of bottlenecks presented no difficulty. We didn't have to put anything on paper to know where the bottlenecks were going to be. We worked on getting the total job done as quickly as possible. I don't recall at any time having the equivalent of a progress chart.
Bryant: A Gant [sic] chart?
Davenport: What I call a PERT chart. At no time that I can recall did we use anything like that. Of course we did have schedules, but the formality of the charting method did not figure in my project control.
Bryant: Did your supervisor have a schedule as well?
Bryant: Was it simply handled verbally between you?
I think it is telling that Davenport, a major historical figure in military and industrial scientific projects does not know the difference between between a Gantt chart and a PERT chart. If you listen to the theorists they will give you the idea that the Polaris Missile would not exist except for the invention of the PERT chart, but the biographies of major participants always say the same type of thing, just like Davenport: "We worked on getting the total job done as quickly as possible. I don't recall at any time having the equivalent of a progress chart." Remember this is coming from a man who now (in the year 2003) advocates all kinds of micromanagement techniques as an approach to large-scale projects.
Even on the largest scale life reflects the foibles of human nature. On one hand you have project management theorists and on the other you have people doing stuff that I would tell you more about, but I have to go do some work now.
|Developer Diary · email@example.com · bio · Revised 9 December 2003 · Pure Content|