The CAMO–Part-145 interface: who owns the forecast your man-hour plan depends on
Every man-hour plan under AMC1 145.A.30(d) starts with a number the maintenance organisation doesn't produce: the utilisation forecast. Flight hours per aircraft per month, check due dates, calendar items — all of it lives with the CAMO. When that forecast is stale, your staffing plan is wrong before the first wrench turns, and nobody notices until the deviation report forces the conversation.
01The handoff nobody writes down
In most organisations the interface looks like this: the CAMO emails a spreadsheet in December, planning builds the annual man-hour plan on it, and the file is never revisited. Meanwhile the CAMO revises its forecast every quarter as utilisation shifts. The two documents drift apart silently. The failure modes are always the same three:
- No version control. The plan doesn't record which forecast revision it was built on, so at audit time nobody can show why the numbers changed.
- No trigger threshold. Nothing defines how far actual utilisation may drift from the forecast before the man-hour plan must be re-run.
- No named owner. The CAMO thinks planning tracks utilisation; planning thinks the CAMO flags changes. The gap is where the 25% deviation breach lives.
02The worked example: 60 becomes 75
Five AW139s, each forecast at 60 FH/month. The CAMO's December forecast feeds a man-hour plan built in January. By March, a new contract lifts actual utilisation to 75 FH/month — the CAMO knows, planning doesn't. Watch what happens to the 600 FH checks:
| Aircraft | Check planned (60 FH/mo) | Check actual (75 FH/mo) | Pull-forward |
|---|---|---|---|
| AW139 #1 | Sep | Jul | −2 mo |
| AW139 #2 | Nov | Sep | −2 mo |
| AW139 #3 | Jan (next yr) | Oct | −3 mo |
| AW139 #4 | Mar (next yr) | Dec | −3 mo |
| AW139 #5 | May (next yr) | Feb (next yr) | −3 mo |
At 60 FH/month a 600-hour interval is a 10-month rhythm — five checks, two of which fall just outside the plan year. At 75 FH/month the interval closes in 8 months, and two checks migrate into the current year. At ~1,500 man-hours per check package:
actual load = 5 in-year checks × 1,500 MH = 7,500 MH
deviation = +67% — three times the 25% trigger
The plan didn't fail because the maths was wrong. It failed because its input went stale in March and no rule forced a re-run until the Q3 review showed a breach.
03Three interface rules that actually work
- Version-stamp the plan. Every man-hour plan states the forecast revision it was built on: "CAMO forecast v2025-Q4, utilisation 60 FH/mo." When the forecast changes, the plan is visibly out of date — no archaeology required.
- Set a numeric re-plan trigger. A practical threshold: re-run the man-hour plan when cumulative actual utilisation deviates ±10% from the forecast for two consecutive months, or when any check moves more than 30 days. At 10% utilisation drift, check timing shifts roughly a month over a year — enough to move real man-hours between quarters.
- Fix a monthly data handover. One page from the CAMO, same day each month: actual FH per aircraft, updated due dates, deferred defects with man-hour estimates. Fifteen minutes of arithmetic against the plan beats a quarterly surprise.
04What the auditor asks
The Part-145 surveyor's question is deceptively simple: "Show me the forecast this plan was based on, and show me you noticed when it changed." The organisations that pass this cleanly have three artefacts: the version-stamped plan, the monthly CAMO handover log, and the quarterly planned-vs-actual review showing deviations caught before the 25% line, with the corrective re-plan attached. None of this requires software — but it does require that someone, by name, owns the interface. Write that name into the MOE exposition, or accept that the answer is "nobody."
Re-run your plan against the latest CAMO forecast in minutes: update the utilisation per aircraft, watch the check dates and man-hour demand shift, and export the revision for your review log.
Re-check your plan →