Maintenance Task Analysis · Chapter 6

Common Pitfalls

The mistakes seen in practice and the guards against them.

Task analysis fails by being plausible. Every row has a time in it, the times are not obviously wrong, and nothing in the document says which of them anybody has ever seen performed.

PitfallWhat it looks likeThe guard
Times estimated by the designerEvery task rounded to the half hourEstimate by step, from an elemental basis, then validate on the article
Never walked on the hardwareAn analysis completed before the first article existsPlan the validation event; the findings pay for it
Elapsed time and man-hours conflatedOne column called "time"Two columns, plus the crew profile that connects them
Crew size averaged1.67 technicians for three hoursCrew per step; the average belongs to no step and no plan
Frequency missingTask times with no rate against themEvery task carries a frequency, from the failure rate or the interval
Access and preparation excludedThe task starts at the item and ends at the itemStart at the aircraft as found and end with it serviceable
Fault isolation assumed instantDiagnosis time absent, or the same for every taskTake it from the testability model, ambiguity groups included
Support equipment inventedA task that needs a rig nobody has costedEvery tool named, quantified per site, and priced
Special tools missedA task validated with a substitute that damages the itemThe validation is where these surface, and the reason to hold it
Consumables ignoredSeals, lockwire and lubricant absent from provisioningThey are demands per task, and they are what stops a job at 2 a.m.
Skill level left blankA task any technician can do, on paperTrade and skill per step; a task nobody at that base can do is not a task
Hazards recorded as a warning"Caution: hot surfaces" and no cooling timeIf it changes the task time or the crew, it belongs in the steps
Prerequisites unrecordedThree tasks planned in parallel on one bleed systemConcurrency constraints are part of the analysis, not of scheduling
Preventive tasks left outOnly corrective work analysedOn this example preventive work is 69 per cent of the man-hours
Ranked by durationThe longest task treated as the biggest problemRank by frequency × duration; a short frequent task usually wins
One level analysedOnly the flight-line task, no workshop or depot taskLevel of repair cannot be decided without the other levels
The analysis never updatedTimes from the prototype, in service five years laterField data corrects task times exactly as it corrects failure rates
Written as proseA paragraph per task, no dataStructured fields, or none of the downstream products can be built

Four are worth expanding.

Not walking the task is the pitfall that produces all the others. Times estimated in an office are optimistic in a predictable direction, and the errors are not random: access is worse than the drawing suggests, connectors are unreachable with the fixture fitted, and the special tool that makes the job feasible has not been designed. A validation event on the first article finds these in an afternoon, and every one of them is a change to a document somebody else is already building from.

Elapsed time and man-hours answer different questions. The aircraft cares about the first, the manpower plan about the second, and the support cost model about man-hours per operating hour. A single column called "time" silently answers one of the three and misleads the other two, and there is no way to recover the missing information afterwards without redoing the analysis.

The frequency column is what makes it engineering. A task time is a fact about a procedure; a workload is a fact about a fleet. On the worked example the biggest single consumer of manpower is a 1.2 man-hour filter servicing, because it happens 86 times a year, and it outranks every failure in the system. No amount of attention to the long tasks would have found that.

Preventive work is usually the majority and is usually analysed last. It is scheduled, so it feels like planning rather than engineering, and it lands in the analysis after the corrective tasks are done and the budget is spent. On this example it is 69 per cent of the man-hours, and the interval that drives it is a number somebody chose, which means it is a number somebody can revisit.


Want to see this on a live system model? Request a walkthrough.