Project Journal: Earliest Project Memories

Introduction to the Project Journals

I am participating in the 100DaysofIndieWeb and my original 100 day project was to post my photo albums (fix past broken albums that were the result of my IndieWeb website transformation, current albums). And then I decided to change my project because I have been thinking that I wanted to post a journal of my past and future experiences as a project and program manager, including when I didn’t even know technically what a project was. My hope is that these project journals might inspire an aspiring project manager. Personally, I also wanted to have a record of my project activities.

#100DaysofIndieWeb, #IndieWeb, #ProjectJournal, #ProjectManagement

Day 1 of 100

What is a project?

PMI defines a project as:

”A temporary endeavor undertaken to create a unique product, service, or result. The temporary nature pf projects indicates a beginning and an end to the project work or a phase of the project work. Projects can stand alone or be part of a program or portfolio.”

Source: Section 1.2 Key Terms and Concepts, The Standard for Project Management,  PMBOK Guide – Seventh Edition. A guide to the Project Management Body of Knowledge.

This definition of a project does not say it has to be formal or documented which says to me that it could be a wedding, system migration, system upgrade when you are in an operations and maintenance phase, cookbook, website, piece of clothing (designing, sewing), party, trip, selling, home relocation (selling and moving), field trip,  school play, conference, workshop, and so many more things that we would not typically consider a project. It also does not say that it has to include all of the PMI Knowledge Areas or Process Groups. This results in many endeavors being able to be labeled a project.

Earliest Project Memories

My earliest memories of professional projects are below. At the time I did not think of these as projects, but they were small projects that did take a little bit of planning but more importantly had a beginning and an end and reduced a result for the customer.

IBM Copier Maintenance

When I was in college I had an internship at IBM where I cleaned copiers. 


The copier maintenance always started with someone letting me know that the copier had reached the copy count needed for maintenance.


I would reach out to the customer to schedule the maintenance. I possibly ordered a copier maintenance kit.


I would drive to the customer’s location. Upon arrival I would take my tool case, small vacuum cleaner, and supplies to the copier location with my hand cart.  At first I would put on a protective suit so that my clothes would not get dirty. Later I could clean the copiers in a white shirt and yellow pants and not get dirty. 

A copier maintenance is a dirty affair. It’s all about removing toner that is either dry particles that were all over or fused toner that may be on rollers, the fuser, or other parts of the copier. 

My recollection of the process is that I would:

  • Replace the filters.    
  • Vacuum all of the dry toner particles inside and outside of the copier.  
  • Clean the fused toner off of the rollers, fuser, and other items with IBM Cleaning Fluid.
  • Clean the glass where you place the originals.
  • Ensure the developer drum was protected from light.
  • Clean the covers.

Monitoring and Controlling (Risks are documented, monitored, and responded to in all process groups but I will note them here.)

The risks associated with this project were toner getting into your nose and breathing the IBM Cleaning fluid.

Of course there was also the risk of the copier not working after you cleaned it, but I don’t remember that ever happening. 


At the end of the call, I would do my paperwork and let the customer know that the machine was ready for use so that they could test it before I finally left.

IBM CRT Replacement

I totally failed on this project.


My manager provided the list of CRTs that needed to be replaced in accounts that I was not familiar with. I just remember thinking that there were no contacts on the list and that sometimes the addresses were incorrect. This tainted my view of this project.


I didn’t really know how to plan this. I would know exactly what to do today. I would ask my manager for more information, I would ask for their guidance on how to plan and execute the project. I would ask how to obtain accurate information on the accounts. I would have probably asked the other customer engineers if they had knowledge of the accounts.


I think I replaced 2 or 3 monitors. The project went to another customer engineer. 

IBM ECA’s on IBM Personal Computers, IBM PS/2s, or IBM AS/400 and IBM System 36s

Periodically, many pieces of hardware would receive Engineering Change Announcements (ECAs). We Customer Engineers would implement the EC (Engineering Change).


The ECA would be announced and in a separate role I would let my peers know through PROFs, our email system back then. Additionally, the Support Customer Engineer would let us know also. Planning

As far as I remember most ECs were installed if there was a problem call on the machine that related to the symptoms in the ECA. But I believe there were ones that were required also. If a call was received for hardware that had symptoms related to the ECA then I would order parts, if required. Some ECs were software based.


Upon arriving at the customer location, I would install the hardware or software update.

Monitoring and Controlling

The main risk would be that the EC would brick the hardware. I don’t remember ever experiencing that.


At the end of the call, I would do my paperwork and let the customer know that the machine was ready for use so that they could test it before I finally left. Paperwork by this time included placing a label on the parts and completing information on my Motorola Portable Terminal (PT) ( This device allowed us to send messages to others, receive service calls, update service calls, order parts, and close service calls. It was a device ahead of its time. I returned any used parts to the parts department in our office.

Conclusion and Lessons Learned

I didn’t know any of these were projects. Ideally the customer benefitted through receiving an improved version of their hardware when the project was completed. My naïveté led to my failure on the one project and my goal is to never ever let that happen again. Lesson Learned: If a project has been given to you without the information you need ask questions, no matter how simple the question.

Link: Project Journal: Earliest Project Memories

Project Journal: Earliest Project Memories





One response to “Project Journal: Earliest Project Memories”

  1. Deadra Welcome Avatar

    This Article was mentioned on

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: