The Engineering and Project Notebook

Back when I was in engineering school one of the requirements for nearly every class was to keep an engineering notebook. Typically it consisted of a bound book with graph or engineering paper where we would keep a chronological record of our adventures including class notes, test results and project data. One professor went as far as to make the engineering notebook 40% of the semester grade.

Probably because my memory is not great and I am somewhat obsessed with organization I continued keeping an engineering notebook after college. I started using a loose leaf binder and punching holes in documents or graph paper and carrying my current notebook wherever I went to work. I would use tabbed dividers to separate different projects or months within the binder.

Less than a year after starting my own company, wonder of wonders we got a job processing and packaging 3 ring binders for Avery Dennison! At that time we did all of NAS’s controls work and Tom Nalle allowed us to take as many binders as we wanted. We processed literally thousands of binders and packaged them in corrugated boxes. At one point we had boxes of binders stacked to the top of our ceilings in several rooms of my shop. At this point I started keeping a separate notebook for each project which I still continue today.

Before I became comfortable with being able to simply write a program from scratch I would actually hand draw ladder logic on graph paper before I typed it in. This was in the days when programming software was written in DOS and not nearly as user friendly as it is today. I would often start by writing a tentative I/O list, a hand sketch of the machine layout and a flow chart of the logic. If there was anything special about the project such as a Basic Module (remember those?) or complex device my coding or a cut sheet for the device would also go into the binder.

It was fortunate that we processed binders from 1″ to 4″. I could usually tell what size binder I would need at the beginning of the project. As time passed I had to get special bookcases just for the binders and kept them in a common room as a resource for other engineers that worked for me. I also required them to keep binders for each project they worked on.

After I closed my company in 2006 I started working for the large Machine Builder where I am currently employed and put most of my old project binders in storage. I had kept several boxes of the old Avery Dennison binders when I moved and donated them to my new employer thinking that they might be useful for other engineers. Surprisingly, I found that none of the engineers where I currently work keep a project notebook. In these modern times it seems that nearly everything is kept on the network in a giant project folder. But what of the ideas that come up when you aren’t at your desk? What about the napkins that we write on during happy hour?

I have gone back to my notebooks many times in the past to look up some method of solving a problem or technical issue. There is also no telling how many times I have visited a plant to evaluate a potential project only to find that there was no or insufficient information on a machine to properly estimate the time it would take to solve the problem. This of course contributes to the cost of the project and makes it more difficult for plant maintenance personnel to troubleshoot.

In an interesting article by Keith Campbell, he laments the lack of documentation in many modern facilities:

“Documentation is the primary and most important tool for troubleshooting. Just as you can’t take a trip to a strange place without some sort of map, you can’t troubleshoot a system without good documentation.”

This not only applies to the documentation that came with the machine or system, it also concerns the maintenance records and notes that operators or technicians keep on the equipment. This is one of the simpler things companies can do to help their bottom line. For the cost of some paper and a little bit of time it is possible to save thousands of dollars in troubleshooting effort by simply recording the events in a system’s history.

Happy Automating!