Leaving an Impact

When confronted with a new role at work, I often review the existing instructions, procedures, and templates. Frequently, I have found them out-of-date and involving wasteful steps. To pass on things better than I found them, I try to leave an impact through making process improvements and updating those documents.

Toiling away at updating job instructions

SAP Quoting

The first instructions I remember making at work were in my second role. As an analyst in Supply Chain focusing on quoting and proposals for out-of-production military spares, the templates were hard to use and the procedures outdated or nonexistent . For the templates that we had to fill out for the customer proposal team, I worked with them to update the template, which came back to me for another update more than 10 years later. The version I developed first made copy/paste easier from the suppliers' quotes, and highlighted the "best value" option (cost + lead time + supplier scorecard) for each part/quantity combination we were quoting.

We were also only two years into using SAP, so we used it in a very clumsy way: we put all of the proposal requirements information into SAP to generate a "collector" number for the quotation package, and then either ignored SAP thereafter (the more efficient option), or generated requests for quote (RFQ) in SAP, printed out the resulting dozen-page RFQ forms, scanned them, and then emailed those to the supplier. I tried to push us into using SAP to capture the suppliers quotes after they came in, but that didn't happen. I wrote up the job instruction required, but with management not interested in pushing the changes and me too immature to do it myself, they fell by the wayside.

I was very thankful to "past Adam" a decade later for that job instruction, as it saved me re-learning about SAP quoting when we developed the next-generation quoting and proposal tool.

Program Management

As a Program Manager (later Senior Program Manager), my manager asked me to lead continuous-improvement (Lean) activities for our site's Program Management team. Over time, because our site's Lean team was the only one functioning in the business unit, I took over leadership of Lean for all of the military business unit. During this time, I revised templates and wrote up instructions for our bill of material tool (used on new program introductions to schedule) and created/updated templates for schedules, customer proposals, and management reporting.

Although some of those updates stuck better than others, change management went through major sustained changes, including updating the formal procedure, job instructions, and templates. I also worked with the Contracts team to achieve the company's first successful assertion of commerciality per Federal Acquisition Regulation (FAR) part 12. Landing gear is modified for each aircraft: it's integrated with the aircraft structure so it's very sensitive to the specifics of aircraft weight, landing speed, etc. No one wants to carry extra landing gear weight, so the landing gear is beefy only where needed and as light as possible everywhere else. The methods of modification are common to military and commercial aircraft, and we convinced the relevant parties the modifications were, "of a type customarily available in the commercial marketplace". As I was researching the references here, I see that the project (un-credited to me or the rest of the team) currently appears on the Collins Aerospace website:

Screen grab captured 4 September 2025; © 2025 Collins Aerospace

Program Management was also when I started getting pulled into quality system audits more regularly, which brought me to the strong belief that the as-written procedures had to reflect what we were actually doing, because completing corrective actions was extremely tedious. In Program Management, we consolidated and eliminated procedures and instructions where possible, and updated the remaining ones. An auditor finding an old procedure still on the books was unpleasant, and so we avoided it.

Supply Chain Work Transfer

When I inherited the Work Transfer Senior Manager role, the team's processes were immature: the company had rolled out updated procedures a few times in recent years, and the team was trying to keep up with the changes. This meant that the business-unit-level work instruction was not yet updated, and many of the tools were not yet in place.

As I worked with the team to identify their pain-points and struggles, I also found the various caches of job instructions, templates, and other documentation lying around. I moved all of those instructions to one place and began working my way through them. After my experiences in Program Management, I kept many of them as "job instructions", which per our processes meant that they were not part of our auditable "quality management system" but instead aids which could be used or ignored as needed. Key for me was that we owned the documents and could update them as frequently as needed without going through an extensive approval process every time: we weren't mature enough yet to be publishing only every few years. I devised a numbering scheme (based on the phase of the project where the instruction would apply) and updated everything. This totaled over 20 instructions in less than three years, with a few being just format updates and some being complete clean-sheet write-ups.

The instructions helped me understand the process, and also answer questions faster because I could just point people to the instructions. I was frequently teaching other functions what "work transfers" were, and how my group fit in and what we needed from everyone else. I developed a two-page document in a conversational style which explained when to bring us in and the best way to ask for help. That was a "go-to" document for emailing to new people, and my training sessions for work transfer were normally in two parts:

1. Email out the "Working with Work Transfer" document as part of the training meeting notices. I hosted ~3 training sessions with the same content so that people could join whichever fit best in their schedule.
2. Spend 5-10 minutes up-front on a short presentation, but reserve the majority of the time for questions and answers. The invitation made this clear: please read the document beforehand and then let's all discuss. Some people joined multiple sessions to hear the different questions, and often I sent out a summary to everyone with the questions from every session so that people could learn even if they didn't attend.

I also linked job instructions, so that an instruction on "getting approval for a gate 3 presentation" might link to the "gate 2 outputs" instruction, instructions on how to use the overlap tool to demonstrate line-of-balance, or the cheat-sheet with names that go with each title on the approvals document (updated by me quarterly).

After I left work transfer, my successor GR stopped using or changed his use of some of my tools and instructions. That's fine: everyone has their own way of working, and as much as I tried to make them user-friendly to update, I know they weren't perfect. But the collection of job instructions did continue, and so I know that I did leave an impact; the team is better than I found it.