“You must define your why before you can begin with the what and the how.” – Maria Reyes-McDavis
My career in process improvement started when I was 11. While other kids were riding bikes, I was excited to go to work with my dad and help out in the accounting department. My dad left me to learn from his staff. I started working with other people, in different environments learning to figure out how things worked.
I helped answer the phones, made copies of giant 3’ x 5’ drawings, filed paperwork, and other “busy” work. My analytical skills kicked into gear in this environment, and prompted me to ask my go-to question: “Why?”
My questions started in the invoicing department: “Why do you file these invoices this way when you have me research them and they aren’t in the order you look for them?” Fast forward to me rearranging the filing so it matched the way the information was used, rather than the way it was easy to file. I also created lists that organized files in a different order – an index of sorts, that made retrieval faster when anyone needed to find the info in a different way than it had been filed. Eventually, I converted these indexes from paper to spreadsheets to make the task even easier. I only wanted to do a job once and be done. When I figured out the best way to do a job, my interest waned and I moved on to the next inefficient task.
I constantly watched the way everyone did their job so when it was my turn to step in and do it – typically when they were on vacation or out sick, or needed extra help – I could take over without missing a beat. I didn’t realize it at the time, but I later learned that when I took over positions I often improved processes, due to my WHY drive. I not only stepped into the job, I couldn’t help myself from improving it. As I experienced more positions — receptionist, filing clerk, accounts payable clerk, accounts receivable clerk, drafting, typing proposals, mass mailings (by hand, with paper mailing lists), bookkeeping, etc. I saw how work flowed – or in most cases didn’t flow together. I saw how foremen in the field had to fill out paperwork for payroll and job costing while having to manage a crew and work. In this steel fabrication and construction company, foreman worked with their crews; stepping in when a crewmember was out. They were not simply managers.
My analysis and penchant for improving things carried over into how crews and activities outside the office integrated with systems in the office. Information had to flow easily from the field (the people doing the work/making the money) to the office. The office then had the task of compiling and converting that info into usable information for the engineers and project managers to make decisions to keep the job and company profitable.
I like working on the inside to gain an understanding of how each part works, and connects to the whole. I am able to look at details and realize how the parts interrelate for the most efficient results.
My dad’s office paid a company to write a database application to compile payroll hours into job cost man-hours and labor dollars. It was written in dBase IV. One weekend, while playing on that computer, I broke the program. I quickly had to figure out what I did and ended up re-designing it. I didn’t know code well at the time and did it all with queries, which turned out to be faster and more flexible. No one was the wiser. Phew.
Soon after, I saw that the foreman timesheets for the crew, the employee time cards, payroll data entry, and the job cost calculations were all the same data just rearranged in different formats. That re-arrangement of data was all happening manually — touched multiple times and had to be reconciled each time. Since I was often doing the reconciling, I found a better way. I realized we should enter the data into the database and let the database do the work of rearranging the data, as it needed to be used. One weekend, I wrote more queries and reports. After some testing and what-if scenarios, I showed the payroll clerk, the job cost manager and the accountant what I did. They were amazed at how easy it was and how much time it saved. Some of the automated spreadsheets and databases I wrote for them more than 20 years ago are still being used today (with minor modifications for modern software).
Most kids used their first home computers to play games, which I did, but I also had spreadsheet programs, database programs, and even full-blown accounting packages like Great Plains (the DOS version).
Little did I realize, I was instinctively developing a methodology of process improvement that I would apply to every position, in every company – whether as an employee or consultant. Not only does it involve asking, “Why do you do it this way?” but asking, ”Why do you do this at all?”
Information technology became my gateway, or my excuse, to look at and evaluate all information flowing throughout the entire organization — and laid the groundwork for the work I do today.