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:
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.
Reporting-
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.
