Four things have to be true before a task analysis is worth reading: the task exists for a stated reason, it is decomposed far enough to be estimated, its numbers mean what their names say, and its resources are real objects rather than adjectives.
The task, and the taxonomy above it
A task is not the smallest unit of the analysis and it is not the largest. The logistic support analysis tradition fixes a hierarchy that most of the industry still uses, formally or by habit:
mission → scenario → function → job → duty → task → subtask → task element
with each task described as a verb, an object and a qualifier: replace the flow control valve at the flight line. The convention is not decoration. A task named as a noun ("valve maintenance") cannot be timed, cannot be assigned to a level and cannot be told apart from the three other things somebody might do to the same valve.
Two properties get decided at the same time as the name:
| Property | Meaning |
|---|---|
| Duty-position specific or collective | Performed principally by one person, or by two or more as a crew |
| Maintenance level | Where it is performed, which comes from the support plan and from the level of repair analysis |
Decomposition, and why the total is never estimated directly
The analysis works at subtask level and rolls up. A subtask carries its own elapsed time and its own personnel; a task's numbers are the sum of its subtasks', not an independent judgement about the whole job.
The data standard is explicit about the arithmetic, and it is worth stating in its own terms because it is the part most often done by eye:
mean man-hours = Σ (mean man-minutes per person, over the subtasks) ÷ 60
mean elapsed time = Σ (mean elapsed minutes, over the subtasks) ÷ 60
Those two sums are over different things, which is exactly why they are different numbers. One adds up people-time across everybody involved; the other adds up clock-time across the sequence. A subtask worked by three people for ten minutes contributes thirty man-minutes and ten elapsed minutes, and no ratio recovers one from the other once the crew profile is thrown away.
The step-level record is expected to carry more than a duration: the narrative sequence, the standards and tolerances, measurement ranges, inspection criteria, cautions and safety precautions, power and air requirements, and the communication and coordination needed where more than one person is involved.
Where a step estimate comes from
A duration is only as good as the basis behind it, which is why the basis is a recorded field and not a private assumption. Three of them account for the estimates anybody will defend, and they are not equally strong:
| Basis | What it is | When it holds up |
|---|---|---|
| Measurement | The step timed on the article, or on a mock-up, with the trade that will actually do it | Always the strongest, and the one a demonstration is least likely to move |
| Predetermined time system | A time synthesised from a published library of elemental motions, MTM and MOST being the familiar ones | Short, repetitive, manual work on a layout that already exists |
| Comparative estimate | The time from a like step on a like machine, adjusted for what differs | Where a genuine analogue exists and the differences can be named rather than waved at |
Engineering judgement is the fourth, and it is what fills the record when none of the other three is available. That is not disgraceful; it is the entry the validation event should visit first, which is the whole reason the basis is written down. What none of the four handles well is access: a motion library prices the movement rather than the reach, and the reach is where office estimates go wrong in a predictable direction.
Elapsed time, man-hours, and the third number
| Number | Question it answers | Who reads it |
|---|---|---|
| Elapsed time | How long is the equipment unavailable? | Availability, turnaround, the operator |
| Man-hours | What does the task cost in labour? | Crew size, shift planning, the support contract |
| MMH per operating hour | What manpower does the fleet demand? | The establishment, and the support cost model |
The trade between the first two is a real engineering decision rather than a scheduling one, and which way it runs depends on the step. Where the work genuinely divides, a second technician shortens the elapsed time and leaves the man-hours where they were. Where the second pair of hands is there to hold something, the clock does not move at all and the man-hours rise, which is exactly what the validation walk in the worked example found on the access panels. A design that lets one technician reach the item changes both numbers. Neither number is derivable from the other, and the crew profile that connects them belongs in the record.
Frequency is what turns a time into a workload
A task time is a fact about a procedure. A workload is a fact about a fleet, and it needs the frequency:
corrective task frequency ← failure rate × mode ratio × annual operating requirement
preventive task frequency ← the interval, and the annual operating requirement
The data standard prescribes exactly that derivation for corrective tasks, from the failure rate and failure mode ratio, the induced and no-defect maintenance rates, a conversion factor and the annual operating requirement, and it adds the rule that matters most in practice: any change in those variables triggers an update of the task frequency. A task analysis whose frequencies were computed once, against a failure rate that has since been revised twice, is a workload estimate for a machine that no longer exists.
The resource columns are the point
The time columns get the attention. The resource columns are what the rest of the programme is built from, and each one names a downstream consequence:
| Resource | What it becomes |
|---|---|
| Personnel, by trade and skill level | The manpower establishment, and new-skill justifications |
| Support and test equipment | A procurement list, per site, and the tie between task analysis and support equipment engineering |
| Special tools and fixtures | Items that exist only because a task needs them, quantified per location |
| Spares and repair parts | A demand per task, linking the task directly to provisioning |
| Consumables and materials | Seals, lubricants, lockwire: cheap, forgotten, and the reason jobs stop |
| Facilities | Bays, benches, power, lifting, clean areas, justified by the tasks that need them |
| Hazardous materials and waste | An environmental consequence the later editions of the standards ask for explicitly |
In the data standards those are not free text. Facilities are described and justified as a result of the maintenance task analysis; new or modified personnel skills are justified the same way; the support equipment table is described as the tie-in between task analysis and the support equipment area; and the provisioned-item table links the task directly to provisioning. The analysis is the origin of those requirements, and if it does not name them nothing downstream will invent them.
Validation is part of the method, not a review of it
The specifications treat walking the task on hardware as normative rather than as good practice. MIL-STD-1388-1A requires validating the analysis by performing the operations and maintenance tasks on prototype equipment, using the procedures and resources the analysis identified, updating the records where they turn out to be wrong, and coordinating the event with the maintainability demonstration and the reliability and durability testing. A separate task covers the support package that has to be assembled for a logistic demonstration.
Two reasons this is in the standard rather than in a handbook. Office estimates are optimistic in a predictable direction, so the corrections are systematic rather than random. And the errors that matter are not in the times: they are the connector that cannot be reached with the fixture fitted, the panel that needs two people, and the special tool nobody has designed.
Where the boundaries are
| Neighbour | What belongs to it |
|---|---|
| Preventive maintenance analysis and RCM | Whether a scheduled task should exist, and its interval |
| FMECA | Which failure modes exist, and therefore which corrective tasks |
| Testability | How the fault is isolated, and the ambiguity that lengthens the isolate step |
| Maintainability prediction | The rate-weighted distribution of repair time, and MTTR |
| Level of repair analysis | Where the task is performed, and whether the item is repaired at all |
Each of those consumes or supplies task data, and none of them replaces the task analysis, because none of them produces a step-by-step account of one job with its resources attached.