In over 10 years of the existence of PM Tips, we have had the pleasure of working with top-notch professionals who have made tremendous contributions in feeding the PM community with valuable information. One of them is Jon M. Quigley, a well-known author of PM books, a lecturer, mentor, and, above all, a wonderful collaborator who always has something new to share through his articles for PM Tips.
This year we are celebrating the fourth year of our partnership, which was more than enough occasion to have an interview with him and get a closer look at the man whose knowledge stands behind 70+ PM Tips articles.
PMTips: We know you well, and it's a real pleasure that we are doing this interview after almost four years of amazing collaboration, but we would love for you to introduce yourself more closely to our audience. Can you please give us a glimpse and a short introduction of yourself 😊
Jon M. Quigley: Certainly, I grew up in a trailer park. I worked before I was of age to drive. My mom would drive me to the farmer for whom I worked in the tobacco fields and barns. After high school, I did not know what I wanted to do for a living. I have always had a wide range of interests; this indecision led me to work at a fast-food restaurant. One day, I reconnected with a friend finishing up an engineering degree, and I thought I could learn to make my own bass effects pedals. I played bass in my youth, mostly metal (for example, Iron Maiden, Judas Priest, and Dio). So, I started working toward an engineering degree while working at U-Haul. I still play the bass, by the way. However, I have yet to build my first effects pedal.
I worked during my undergraduate degree. I rented a room in a house from before the 1920s (a converted porch) where I slept on a cot, in a sleeping bag, with my closet—a rope above the cot where I slept—and hung my clothes. I bring all this up to show, from humble beginnings, that we can work hard and persist in humble ongoings.
After my engineering degree, I found a job developing industrial control systems at a small company. This job exposed me to the things required to create a new product. I designed the hardware and wrote the software, and I would also play significant roles in testing the product. Eventually, I found a position in a company developing tire pressure monitoring systems as a project engineer, doing engineering work while managing the project for development, testing, and delivery to the OEM. I owe a debt to E. Allen Downs (he has since passed) for his mentorship. This job introduced me to commercial vehicles.
I worked with Rick Bertalan on introducing a tire pressure monitoring system for the Mid-America Truck Show that would interface with the Digital Message Center (development led by Rick Bertalan). I visited Mount Vernon, Washington, for vehicle RF field studies with an RF engineer. That place was beautiful in the late 90's. I told Rick if PACCAR were ever PACCAR were interested in my skill set, I would welcome the opportunity. They were interested in my working there, I got an interview, and I got the job. I found an apartment, got married, moved to Washington State, and started a new job all in 2 weeks. While there, I worked as a design and test development engineer on a team that produced three patents, among other projects. Also, while there, I realized that no matter how good an engineer a person was, not understanding the customer and market would lead to failure. PACCAR offered an education package that I was surprised so few availed themselves of.
Eventually, my wife and I had a child, and our family is in the east, so we moved east and worked for another OEM commercial vehicle developer and manufacturer at Volvo. I furthered my education via Volvo's reimbursement program, receiving a MSc in Project Management. While at Volvo, I was part of significant projects, one of which won the Volvo Technical and Volvo Technology Awards. I was part of the patent teams that developed telemetry and other vehicle control systems. The telematics systems we developed have functions we referred to as DOTA, or Download Over The Air. Now that we have a new car, constantly asking us to initiate software downloads to the vehicle. I find it annoying with these constant prompts, and I wonder what we have done. I have thought about writing about this, specifically whether this software download creates an environment where development teams and management become lax about testing because it is easy to update the software.
PMTips: So, Jon, first things first, let's go way back. You began your work as a design engineer in the 90s. Can you tell us more about your beginnings and what being an engineer in the 90s was like?
My first engineering job was at a smaller company, so what follows might be more indicative of a small company rather than a company in the 90s. In a small company, you wear many hats, but you will also learn by making stupid mistakes, hopefully only once. I designed embedded hardware and wrote software for industrial process controls in this first job. There were other engineers, but their area of focus was mostly high-power components of the industrial process control system. That is not to suggest there was no collaboration; there was plenty. I felt like part of a team there; I did my part, they did their part, and our parts would fit together to create the final product. We each had to deliver our elements of the design, electronics, power, and mechanical to be successful.
PMTips: You possess expertise in a wide range of product development subjects, including processes, quality, and cost improvement methods. You also hold PMP and CTFL certifications. Looking back at all this knowledge, what attracted you to the world of project management?
All my life, I have read and explored those things that I found interesting. Even as a child, I studied biology, drew stuff I found in nature, and worked to understand internal combustion engines. This is one reason not to go to university right after high school. I like to go where my mind takes me to explore.
The project manager can get entangled in many product development activities. I think having been in many product development positions, coupled with this experience with the entanglements, leads to my ability to contribute on a broad front. In this way, while I am not performing the detailed work, I can contribute to problem resolution and proffer ideas that can be considered where there are roadblocks.
Somewhere along my career path, I realized it was not enough to be a creative engineer; designing a great product is only a fraction of meeting customer needs. We will lose if we do not understand the customer well enough to create the appropriate product with a good business case. This is the reason for my MBA in Marketing. Similarly, suppose we do not manage the project well. In that case, we will deliver late, spend too much money, eroding the business case or create a product that is too cost-prohibitive for the customer. It takes at least skills in these 3 domains to succeed. I was also fortunate enough to work at companies that held continuing education in high regard, to the point where the company paid for or heavily subsidized. I availed myself of these opportunities and was surprised to see so few people taking advantage of this benefit. I would encourage new employees to take advantage of these learning opportunities, not just externally. Take on challenges at your workplace that others will not. Find solutions to the problems that you encounter in your work. Follow your mind. If you want to know something, explore it.
Product development is massive in scope. So many elements must be considered to ensure a successful product, and we have written many books on many of these product development topics, from product management elements like configuration management to product testing. In our perspective, all of these and more are required to some degree, depending upon the project. All of these topics work together; these are cogs in the system to define, build, and deliver to the customer. You may not like the use of the word cog, but please note I refer to cogs as product management and project management processes, not humans. To deliver a product to market requires a combination of disorder and discipline, or in engineering terms, turbulent and laminar flow.
Turbulent flow – churns up ideas, perhaps even disparate ideas from which we can explore, and thinking applies to the product and the process. This represents the chaotic perspective of the work. The creative or non-technical.
Laminar flow – the disciplined approach to the work. At some points in the product and manufacturing development, it will require a considerable measure of discipline, for example, configuration management, product change management, and configuration management.
PMTips: Writing is a big part of your professional contribution to the PM world. So far, you have written over 10 books on various topics. Where do you get inspiration for writing, and is there a topic that you would like to cover in the future?
Yes, at this point it is closer to 20th book, I know, I’m surprised also. I wrote the first book after working on a project. I worked with a project manager from the supplier who used words that, in the project management world, mean particular things, and the words the project manager used had nothing to do with the situation. From experience, a common lexicon is essential for quick and clear communication and finding appropriate solutions for the circumstances at hand. This and other project management errors I had witnessed encouraged me to write something I hoped would be helpful. I had started and chatted with a friend about book writing; they had already written a book, and we ended up collaborating to create something like five books together.
Writing helps in so many ways. One must clarify one's own thoughts and find ways to explore the veracity of those thoughts. Writing requires experimentation and research, all of which will color your perspective. Some of these articles were written after seeing or having a negative experience with a project; sometimes, I was not even the project manager. This writing can be cathartic, entertaining, and perhaps sharing a lesson about what not to do.
I have had the honor to write things with knowledgeable, hard-working people from which I have explored, learned, and flourished.
PMTips: How do PM Tips fit in your writing, and can you share your favorite or most impactful article you've written for the website?
One of my favorite articles, borne from experience as above, is Pragmatic Project Management I have seen many poor decisions made, which were defended against those pointing out the foolishness of the direction by labeling those bringing facts as not being pragmatic. You are not a team player because you see how this decision will very probably lead to failure. I have been developing products for more than 30 years and writing for longer than I have been writing for PMTips. One of my favorite external articles is one on HOPE Project Management I have gotten some interesting feedback on this article. My third favorite, also from long ago and with considerable feedback, is When Words Collide.
PMTips: Jon, it was a pleasure talking to you. I believe our community will enjoy reading our conversations and thank you for your time.