The first incident a new hire causes rarely comes from bad intent. More often it comes from a good idea. You've found a setting on test wafers that improves film uniformity, yield is at stake, and you want it live tonight. The owner's rep told you by phone to follow the drawing, and an idle crew wants to start now.
Management of change (MOC) exists for exactly these moments. In manufacturing, the points where people, machines, materials or methods change are often managed as "4M" change points. The semiconductor fab, construction site and IT company maps in First Run include quests for all four. This article uses them to set out the basics of change management a new hire should learn.
Changing the method: the better the recipe, the more it needs MOC
This is the fab's process engineer quest. A colleague found on test wafers that a slightly longer deposition step improves film uniformity, and production wants it applied from tonight.
- The data is clear, so put it into the production recipe tonight and do the paperwork tomorrow: Poor
- "Pilot" it first on production lots on one tool, and expand if it looks good: Risky
- Get a verbal OK from the section lead, change the recipe and leave a note in the change history: Risky
- Raise an MOC with the data, an impact assessment and a split-lot verification plan, and apply it once approved: Excellent
The two Risky answers are the two most common ways around change control: narrowing the scope and getting a manager's agreement. The feedback draws a clear line under both. A smaller scope is still an unapproved change, and a manager's agreement is missing the impact review, formal approval and verification plan. If something goes wrong, nobody can explain why it changed.
The line from this quest's feedback worth leaving with every new hire is this: MOC is not a process that blocks good ideas; it is the process that lets good ideas reach production without incidents.
An unofficial "short version" is a change too
In the equipment engineer quest, a CVD chamber's preventive maintenance is due tonight, and production control asks to push it back three days because of hot lots. The wrong answer worth noticing is doing a short PM tonight that skips the chamber clean, with the full PM next week. It's Poor. A short PM that isn't in the procedure creates the most dangerous state: complete on paper, not actually maintained.
Changing how a defined job is done is a change, whatever its size. Excellent checks the chamber condition data and agrees with production control on an approved deferral or a lower-impact time slot. Even a deferral is a controlled decision when it comes with evidence, approval and extra monitoring.
Changing equipment and materials: changes the customer must hear about
In the fab's customer quest, the customer's contact asks: they've heard a process step is moving to a new tool and the chemical supplier is changing too, and engineering says nothing changes for the customer because the spec is the same. When will they find out?
- The spec is the same, so nothing changes for the customer and no notice is needed: Poor
- Apply it to a few lots first and see whether the customer notices: Poor
- Run it in production first, and notify the customer once you've confirmed nothing changed: Risky
- Check the change notification criteria agreed with the customer and, if they apply, send a PCN in advance with verification data and a timeline: Excellent
Even with the same spec, a new tool or material can show up as small differences in the customer's product, which is why many customers require advance notice. Notifying afterwards takes away the customer's chance to evaluate and choose, and quietly applying it to a few lots turns the customer into a test subject without their knowledge. A product change notice (PCN) is both a request for agreement and a way of giving the customer time to protect their own product.
Design changes on site: a phone call is not an approval
This is the construction site's contracts engineer quest. In a third-floor community facility, the architectural and structural drawings show a wall opening in different places. The owner's rep said by phone to follow the architectural drawing, and an idle formwork crew wants to start today.
- There was a phone instruction, so start to the architectural drawing and sort out the paperwork before completion: Poor
- The contract drawings are fixed, so tell the owner no change can be accepted: Poor
- Start on the walls that look unaffected, take photos and sort it out later: Risky
- Confirm the discrepancy formally through an RFI, get structural review and cost and schedule impact, and issue the work order after supervision and the owner approve; meanwhile, move the formwork crew to another area: Excellent
Moving an opening without structural review can leave out reinforcement, and a verbal instruction gives no basis for claiming cost or time. The last sentence of the Excellent answer matters too: while waiting for approval, the idle crew was moved to another area to limit the schedule loss. Following change control is not the same as stopping the site.
In the same map's supervision quest, rebar is found placed to an earlier drawing revision. Hurriedly redrawing the shop drawing to match what was built and submitting it with today's date is Poor. Fitting the drawing to the site skips the design review.
Changing people: when a qualification expires
The last of the 4Ms is people. In the fab's customer audit quest, two operators on a critical process are found with expired training certifications. Excellent accepts the finding and contains it at once, taking those operators off the process until they're recertified, then checks for the same gap elsewhere and replies with causes and actions on a timeline. Having the team fill in the missing records before the closing meeting is Poor: creating records after the fact is falsification.
Change requests at an IT company work the same way
The IT company map's PMO quests carry the same principle. When a client asks for a big new feature near the deadline, the right answer is to log a change request, assess its impact and agree before applying it. Accepting and cramming it in is Risky; flatly refusing is Poor. Before applying an approved change, update the schedule and scope baselines and tell the team; telling people only verbally, or just starting to code, is Risky.
The basic order of change management
The Excellent answers across the maps line up into an order that holds in any industry.
- Recognize a change as a change: a short version, a pilot or a workaround is still a change.
- Gather the evidence: the data and the reason for changing.
- Assess the impact: other products, downstream steps, cost, schedule, customers.
- Plan the verification: split lots, retests, structural review.
- Get approval: from the defined approver, not a verbal OK.
- Tell people: check customer notification criteria, and update and share the baseline with the site and the team.
- Find what you can do while you wait: move people, start work that can run in parallel.
Checklist for management of change training
- Is applying a well-meant change right away explained as a wrong answer?
- Do the quests cover that narrowing scope or a verbal OK doesn't replace approval?
- Do they cover that an unofficial short version of a procedure is a change?
- Do they cover that customer notice may be needed even when the spec is the same?
- Is there a quest that separates a verbal instruction from formal approval?
- Is fitting drawings or records to the facts afterwards graded Poor?
- Does the correct answer include a way to keep the site moving while approval is pending?
For design rules shared across industries, read Onboarding scenarios for industries beyond IT. When a change leads to a problem, the analysis is covered in Root cause analysis beyond 'operator error'.
Try workplace scenarios as onboarding quests
Pick the process engineer on the semiconductor fab map to play the MOC quest yourself. Play the Onboarding