________________________________________________________________________Richard S. Kem
The problem was we had to do it all in a year.
Q:
Which is the length of the test contract, the pilot?
A:
The HarrisHoneywells had already worn out, and we needed to get out of them to start
really saving money. We were spending big bucks each year on HarrisHoneywells,
4,000 annually.
Q:
4,000 a year?
A:
4,000 a year per district Corpswide.
Q:
That is big bucks. So, you had that very important time deadline for acting.
A:
Right. So, what I was saying was the way I've always approached these kinds of things is to
break it down in parts and then work each part. Because of the tight deadline, it could not be
a sequential thing. We had to work them all concurrently.
What I'd promised him really was not that much different from my own viewpoint. I'd come
out of Europe where we had just developed two or three different automation initiatives,
starting down at the very bottom, at the work center, and doing something that made sense to
the worker, and then amalgamating upwards.
For example, Butch Saint had always wanted a company-level computer. He thought that
would save the time of the company commander and the first sergeant. The Chief of Staff of
the Army, General Wickham, had said, "We will never have a company-level computer." His
thought was you don't need the first sergeant tied to a desk in the orderly room. Two
different views of the world.
Our approach in the Army--this is where our problems came from--had been to figure out
what we needed at the top and then go down to the next level and the next level to the bottom
level, so they had to provide all that information up.
Our approach in Europe then, as Butch Saint did it, was bring in a smart captain as
commander of the company, have him design and build a laptop computer with the programs
he needs to run his company. Then we would buy the laptop, give it to every company, and
make each company commander able to pick up from our computer store the software
packages to do that. It would be his. Nobody could meddle with him and change it.
Now, if something the company commander has on there is useful higher up, then they can
pull it up and use it. It's his system. It was a pretty nice approach. Credit Butch Saint.
So, I brought those same biases into USACE. My bias was that CEAP ought to be
requirements driven. There's probably too much information that we produce that doesn't
really get used that ought to be scrubbed down. The biggest bias--because of the company
automation experience where we put the company commander who knew what he needed in
charge--was that we really needed a functional guy in charge, not the technical guy. So, you
459
Previous Page
