Our contract deliverables on the program were three documents laying out the trained personnel requirements for maintaining the missile system, the training required to bring those people on line, and the course syllabuses for the courses.  We hoped to show that by cutting out the typing pool and having the training analysts prepare all of their own documentation, that we could do the job better, in the same amount of time, with one third the number of analysts.  It was the basics of what we now call lean process improvement.  We did that and more.

​

One of the "problems" with doing networked computing in the early 1980s is that it was not yet a recognized skill from the point of view of the HR system.  This would turn out to be hugely advantageous, but at the time, my coworker Dick Baker and I felt it was a burden.  It meant that to hire us on in the first place, Ralph had to classify us as training analysts (LFDB in Boeing's HR system), and it meant that from the point of view of his budget and top program management, we also had to do some of the work of training analysts.  I drew two tasks in this regard.  I had to get with the engineers on the missile program and learn enough about two of their things to be able to develop the course materials for them, then first teach dry runs of those classes to my Boeing training teammates, and then teach them to some folks in the Air Force.  So, I ended up working at Vandenberg AFB for about six months teaching Peacekeeper Ground Power Systems.  That was followed by a short stint at Hill AFB teaching Failure Mode Analysis (aka Failure Mode and Effects Analysis). 

 

It is surreal to go to work inside a missile silo every day - especially one with a real missile in it, as ours did.  It was not equipped with nukes, but rather test launch telemetry equipment.  But still - it is a very different experience to work next to a machine that can be a part of the apocalypse, and by being such a thing, it is hoped to actually avert not only that, but lesser conflicts as well.  It's certainly a far cry from doing tax and Medicare provider audits.  But learning to be an effective teacher of a critical part of a moderately complex electronic control system and the discipline of analyzing the whole system for everything that can go wrong with it, would turn out to be incredibly useful skills.  It also set me up for a once-in-a-lifetime opportunity to take advantage of the HR job classification system.  More on that later.

​

By in 1985, rumors had gotten around about that PC-LAN system I helped Ralph put together, so every once in a while someone from another part of the company would drop in for a tour.  This happened almost weekly.  While there, our visitors would often see our other projects, one of which Dick and I were working on together.  The idea was to see if a computer simulation language could be used to describe the training analysis job of converting the the output of the logistics analysis into the finished training analysis documents.  Could the computers actually generate rough drafts of the documents, which an analyst would then copy edit?  The answer seemed to be 'yes' with results of a sufficient quality that it scared a lot of people. 

 

It was clear we could cut the labor content of the training analysis work by almost an order of magnitude on top of the two thirds reduction we had already achieved.  This led to my first offer from Boeing's Advanced Research and Technology organization to come and join them.  It would have been doing more simulation work, but my real interest was in the networking and communications infrastructure, so I turned them down.  Besides, I only had my BA and CPA certificate, and most of the folks over there had their doctorates in one thing or another.  This was not the first time the folks around me thought I was making a crazy mistake, but it turned out to be a wise choice on my part.