Ten steps. The first two are bookkeeping that decides everything afterwards, and the last one is the one programmes skip.
1. Take the task inventory, do not invent it
Tasks arrive from four places, and every task in the analysis should be traceable to one of them:
| Source | Produces |
|---|---|
| The FMECA | Corrective task requirements, one per mode that needs an action |
| Preventive maintenance analysis, RCM style | Scheduled task requirements, each with an interval |
| Damage, battle damage and special events | Tasks that exist for an event rather than a failure |
| Operational and functional review | Servicing, turnaround, transport, handling, calibration |
A task with no traceable requirement is either a missing entry in an upstream analysis or a task nobody needs, and both are worth finding out before it is priced.
2. Name the task properly, and fix its level
Verb, object, qualifier. Then record whether it is performed by one person or by a crew, and at which maintenance level it is being analysed. Where the level is not yet decided, the task is analysed at each candidate level, because that is precisely the input the level of repair analysis needs and it cannot be reconstructed afterwards.
3. Decompose to subtasks, then to steps
Down to the level where a step has one purpose, one crew and a duration somebody can defend. The test is whether the step could be timed with a stopwatch by an observer who has never seen the equipment.
Start the sequence where the equipment is as found and end it where the equipment is serviceable and signed for. Preparation, safety, access, closure, functional check and documentation are steps in the task, not overhead around it, and leaving them out is the single largest source of optimistic task times.
4. Estimate each step, from a basis you can name
For each step: duration, crew size, and the trade and skill level of each person. Estimates come from an elemental time basis, from a comparable task on a comparable machine, or from a measurement. Whichever it is, record which, because a validation event needs to know where to look first.
Two step types deserve their own attention. Fault isolation takes its time from the testability model, including the swap-and-retry that an ambiguity group implies, rather than from a comfortable guess. Access is measured against the actual layout, and where the layout does not exist yet, the assumption is written down as an assumption.
5. Roll up, and keep both totals
man-hours = Σ (step duration × crew) and elapsed = Σ (step duration along the sequence)
Where steps genuinely run in parallel, the elapsed sum follows the critical path rather than the list order, and the record has to say which steps overlap.
6. Name every resource, as an object
Support equipment, special tools, spares, consumables, facilities, and the quantity of each per task. A resource named as a category, appropriate test equipment being the usual offender, cannot be bought, costed or trained on. Every entry gets a part number or a specification, and support equipment gets a quantity per site, because that is the number the repair level analysis multiplies by the number of sites.
7. The conditions that change the task
Hazards and the precautions they force, protective equipment, cooling or depressurisation waits, access constraints and postures, environmental limits, hazardous materials consumed and hazardous waste generated, prerequisites, and concurrency restrictions with other tasks on the same machine. Anything in this list that changes the duration or the crew belongs in the steps rather than in a warning at the top.
8. Attach the frequency
From the failure rate and the mode ratio for corrective tasks, from the interval for scheduled ones, both against the annual operating requirement. Without this column the analysis cannot produce a workload, and a workload is what most of its consumers actually want.
9. Roll up to the system, and read the ranking
annual man-hours = Σ (frequency × man-hours) and MMH per operating hour = annual man-hours ÷ annual operating hours
Read the ranking by contribution rather than by duration, and read the same tasks a second time in elapsed hours, because the two rankings answer different questions and the second one is what the availability model wants.
10. Walk it on the hardware, and correct the record
The validation event is where the analysis becomes true. Perform the tasks on the article with the procedures and the resources the analysis names, with the trades the analysis assumed, and record what actually happened. Coordinate it with the maintainability demonstration and with reliability testing, because the same event can serve all three, and the aircraft or the vehicle is only available once.
Then update the records, including the ones already sent downstream. A validation that finds three problems and corrects the analysis but not the publication, the provisioning list and the support equipment buy has found three problems and fixed none of them.