George L. Ball
Memories and Thoughts
Chapter 5

More Ball Busting


Since my first PC, that 4k Radio Shack Model I, I've been through a number of computers. First I upgraded the RS Model I with more memory (I think it got up to 16k), disk drives (not only storage but more language in the basic programming), and a dot-matrix printer to print full readable pages. In between that and a thermal printer which came with magnifying glasses, I used an old teletype machine which some HAM converted to respond to ASCII. Its main problem was there were only capital letters and the ribbons wore out rapidly.

My next computer was a "True Blue" IBM 8088 based PC with 2 5-1/4" floppy drives and a hard drive of, I think, 20Meg in size. It started with a monochrome yellow screen, but I eventually went to color. I'm not sure how much memory this computer had, but it carried me until I got a Generic MS-Dos based 386 (33MHz). This had 2 40Meg hard drives and 4Meg of memory, sound, high resolution color and a 9600 baud modem. Eventually I replaced the 386 chip with a 486 Cyrix. Improvements were not obvious. I also increased the ram to 8Meg and put in a 540 Meg hard drive. I then added a 90Meg Bernoulli drive which always worked great. Some where in this time frame I switched to Windows finally ending up with Windows 3.11 (a lot of fascination and a lot of pain).

I then added a Gateway 2000 486 Laptop (on which much of this is being written). It started with a 130Meg drive which I eventually upgraded to 325 Meg. At about that time I decided to give Windows 95 a try. The way I did it was to first install it as an upgrade on the 130Meg drive (which is great on the laptop because you can just slide one out and the new one in. The only restriction is shutting it off while you do it.) It seemed to work well and importantly would still let me use a number of DOS programs. In particular my favorite piece of software is dBase III+ and it would run.

I bought dBase for Windows assuming this would be a good time to "move up" but it did not work. It crashed the system every time I tried to run it. To this day it sits in the drawer and I still use the DOS version. Every now and then I move a database from dBase into Works and play with it, but I still prefer the dBase III+ operation. Recently I took a quick look at the Microsoft Database Access. My first test was to try and move a dBase dbf file into it. It wouldn't work (unrecognizable format). I couldn't believe it. That is the end to that part of Office, even though I'm using Word to be compatible with some of my work needs.

I had had very poor experience with hard disk doublers in the past and therefore had stripped any evidence of them from my drives. While I was testing Win95 on my 130Meg laptop drive I decided to try doubling it with the Win95 double. It worked well and gave me about a 250Meg drive. After a bit of testing on the 130 drive I finally decided to install Win95 on the 325Meg drive and to double it. That I did (to 500Meg) and it has worked well and still handles my dBase III in a window. That is not to say that my testing was free from problems. Erasing unwanted program files can create a mess (the kindest words I can think of to cover the situation).

One of the things I do on the computer is work with digitized photographs. They have built in compression so the doubling of the disk is not as effective. Being aware of that I try and keep my photos and videos on external removable media. First the 90Meg Bournelli and now a 100Meg Zip Drive. The Zip drive is on a parallel interface so I can move it from my table top to my laptop. It works great and except for Win95 wanting to rename it all the time it does a fine job, at a very reasonable price.

It soon became apparent that the 486 table top computer could not match the 486 laptop (now with 12Meg of ram) and I could not readily handle the MS Office components that I needed for my job. So I took my box to a local dealer and put in a new board with a Pentium 166 in it. I also swapped some ram to end up with 32Meg and put in a 1.2gig drive I had gotten at a computer show the year before. This drive lasted for about 4 months before it crashed. When it did I upgraded to a 1.6Meg and installed Win95 from a CD. This computer has 2 CD's, one 4X and one 8X. Since a lot of the software is coming on CD's I also added a PCMCIA interfaced 2X CD to the laptop (just enough to get the software in).

Now my laptop is fine for word processing and doing HTML markup but handling of photos is a little slow. I leave the photography to the Pentium 166 and 32Meg ram. There I digitize photos either by sending them to Kodak who does a great job and puts them on CD for scanning them into a flat bed scanner. The scanner does a better job than I expected and has plenty of resolution for the Home Page application.

Project Management-

There are all kinds of names for various forms of Project (or Program) Management. I have been exposed to most forms. Regardless of what it is called, however, there are a few common principles that are important to all of them. I would say that I probably learned some of the best techniques while under a Matrix management structure. This was a major change in the way our operation had been run, so it could have been that the change itself had a lot to do with forcing the understanding.

Each and every time I started a project and interfaced with anyone who was going to be involved in the project, I wrote down the following:

_______________When .................Project Manager
_______________How Much
_______________How To...............Functional Manager

I was usually the Project Manager (PM) in the discussions, but it doesn't matter which one you are at any given time, you can be either one. You just need to put the correct hat on and remember which one it is.

The Project Manager should know why the work is being done. This is very important during the planning and proposing stages since it will help set priorities. The Why may and hopefully will include some good technical reasons like "a newer higher performance material is needed to reduce costs resulting from early failures". Just what kind of failures, and what kind of performance is needed is important. If the PM doesn't know he needs to do his homework over.

It is also not unusual that the Why is connected to some "political" reason. If this is the case, even though no one may want to publicize it, it is important to know. For instance if the person who has the funding is tired of something being green and wants it purple, everyone needs to know that. Proposing something green would be a waste of time and suggesting something other than purple would require an unnecessary and very difficult justification. This paragraph may seem a waste of time and to many unrelated to project management, but it is an important aspect and the job of the PM.

It is also the job of the PM to define When the result is needed. Figuring out what you're going to give someone for Christmas in January of the following year has little benefit. If the person funding the effort wants it in 3 months and you can't give it to him for 6, you might as well save your time in even proposing anything. That is not to say that if the request is entirely unreasonable that you should agree, but you might want to drop off some of the gold plating. It is the job of the PM to know this and also to know if what is in the request for proposal matches what the sponsor wants. These don't always match, sometimes because getting the procurement through takes more time than was anticipated to do the whole job. If it ends up being late, you don't want to be the real or apparent cause. If you tell everyone that it is going to be late up front, it makes no difference unless you write it down and everyone agrees that is acceptable. One law of project management is "Memories Are Short".

How Much money and/or resources are available for a project is to be defined by the PM. Knowing when and how it will be available is also his/her job. Also knowing if it is expected that this will be the only money or if there is a chance for more if continuing works appears promising is necessary. This will have a major bearing on the When. Poorly funded efforts may take longer.

Defining What is to be done is an iterative process between the PM and the FM. This is the most important step of the whole process. The PM should represent the customers needs and the FM the Functional organizations needs. First the PM should determine What he thinks the customer wants to be done and tell the FM. The FM, after review of the situation, will come back to the PM with agreement or an alternate suggestion. This revision may be due to any of a number of reasons including time, cost, quality, etc. It is here that negotiations take place to match the needs with the resources so that you end up with a Win-Win situation. You have to promise what is reasonable but include stretch to offer them the most for their money. It is from this What that the Work Statement is created. This is what you agree to and put down in writing.

If the organization is operating as it should, the FM will in time understand the customers needs, especially those that are repeat. It is important that that knowledge be factored in. However, the customers interests should be projected and protected by the PM. The FM should be looking out for the performing organization.

The How To is where the FM should excel. He/She should concentrate their efforts on knowing best how to do something. Whether this is performing some specific analytical test, processing some material, writing a report, etc. they should be spending their time on being the best. In proposing the work then they should know the best things to do and how and when to do them.

Knowing best How To do something leads directly to the Who and Where to do it (unless one of these is dictated for some reason). It is the job of the FM to have the staff and facilities to do the job. This of course includes anticipating what the jobs will be so that the organization is ready when funds are available.

Anticipating what is coming up requires the efforts of everyone. It is most important that the PM's and the FM's talk to each other. In essence the FM is the customer of the PM. The FM should treat the PM as a potentially good customer and keep up with his needs. Also the FM is a customer of the PM. The PM should keeps up with his capabilities and be aware where work is needed because of available resources (both labor and facility).

It is MOST important that the PM have some clout to get something done. No one reports to him except possibly a clerk. The power that the PM has is in having control of the funding. Work statements are written, agreed upon, and then the PM provides the funds. The FM then sees that the work is performed within the time and dollars. Nothing I've said rules out renegotiations. They are part of the business. Whereas it is best to not over run every project, Overuns are to be expected and both parties need to plan on them.

The FM should have room to cover just plain screwups on his or his peoples part. One of the best ways to cover this, I feel, is to have that type of screwup charged back to an overhead for which the FM is responsible. That way he will have pressure to minimize them. It has been my experience that the FM's don't like that way and since they usually have a vote on the organizational staff it usually doesn't happen that way. The upper management likes to keep the overhead down also so the PM's are usually outvoted. That still doesn't change how I feel about it. I have been both a PM and a n FM many times.

The PM also has to be able to cover cost problems and/or changes in scope. Changes in scope should be easy to accommodate. In fact they usually are a problem, partly because no one wants to admit to them. This is one area where the PM earns his keep. He has the dirty job of informing the customer that the scope has changed and it will cost more. The way that the PM can simplify this problem is to attack it BEFORE the scope changes and BEFORE THE MONEY IS SPENT. At that point (BEFORE) options are open and a decision can be made. Either the customer can come up with the money or not change the scope. Sounds simple doesn't it. Probably one of the biggest problem areas in the project management. Even when what is to happen is substantially in writing.

If the PM has screwed up in his interpretations of what is to happen, he needs to have some way of working around the problem. If he screwed up it is not the customers problem. It is also not the FM's. One of the best things he can do is to keep a reserve or contingency fund for such situations. How much he keeps will depend on how sure he is that the problems have been properly defined. There will always be minor changes in scope and/or unanticipated problems. For that reason the PM should keep his reserve fund so that he can resolve issues without bothering the sponsor every time.

Overrunning a contract is not good. That is giving away work unless it can be recovered. The only thing worse than overrunning, however, is underrunning. You really can't give it back and the sponsor can't do much with it if he got it back. The best thing to do is to spend it on as productive an aspect of the project as possible.


Every piece of work should be documented. This includes what went right as well as what went WRONG. The tendency is to report only the good stuff. How we started here, and through this logical progression ended up there. This is fine and must be reported (usually a requirement of a contract even if you run out of money). However passing on what you did wrong so that others don't unknowingly make the same mistake is also important and should be included. This may be contained in an Appendix, just as long as it is there. I also believe in recording and reporting all data. Again, so as not to clutter the positive explanation of what happened, this may be presented in an Appendix. In this way if someone wants to take a look at the data and analyze it in a different way, the information is there for them to do that.

My experience included work with the EPA (Environmental Protection Agency). We performed air sampling of industrial sites. They required that ALL the data be recorded and reported. These reports ended up consisting of about 10 pages of text and 300 pages of data. I considered these excellent documents which recorded what was done. These might have been a little unusual since the interpretation of the data was conducted in another report which referenced these, but I feel that this is the way that science should be done. Appendices do not need to be exciting and the cost of the paper is trivial compared to the cost of the work.

One approach that someone suggested to me once was to write the final report in the first week or month of the project. At first I thought they were crazy, but I gave it a try. My conclusion is that this is one of the best ways to run and write up a project. One major positive (among many) is that if you create a table having independent and dependent variables in it at the beginning there is a VERY high probability that you will perform those experiments and get that data to fill in the table. If you start putting a table together on the last month of a project and see that you should have some data which you don't have, it is probably too late to get it.

Reporting is important to everyone, the researcher, the Company, the Sponsor and all those who might try to duplicate the work in the future. I have observed a resistance to documenting projects with all kinds of excuses. "I need to wait until I get complete data"; "I don't have time"; "Let's wait until the end of the contract"; etc. At a minimum I think an annual report should be written on any project no matter how big or small. If it was worth doing, it was worth writing about and the writing is as much a part of the project as any of the experiments. I'm an advocate of writing the draft of the final report in the first month (as discussed above). As a minimum monthly reports should be written which are accummulative where the annual report becomes the 12th monthly. This is an excellent way of writing since it gives you a chance to look over some of the data and discussion 12 times. You'd be amazed how many little things (typos, misspellings, etc.) are missed but can get picked up by the multiple reviews. Don't retype text over, copy it.

High Quality. Be definitive. What relates to what. Push the snow out of the way. Use plain English, etc.

© 1996, 1997, 1998 George L. Ball

======= to be continued as George gets to it =========

============== 12/01/96 - 01/12/98========================

Start Return to the Start of This Chapter

Next Go to Next Chapter

Text Menu Go to George's Memories Menu