Level of detail is both a science and an artform. Its a continual struggle for all planners getting level of detail right where we are tracking granaular tasks, but at the same time respecting an overall workflow and CPM logic. For example, with a compressor installation, you don't schedule the fifty fittings, the gasket sets, or the small-bore tie-ins that come with it - but you still have to deliver them, and somebody is tracking them in a spreadsheet. The detailed ITRs and punchlist items are also not good "schedule" activities. Deciding where that line sits is one of the least documented and most consequential judgements a planner makes. Often times, schedules are impacted by little things that don't exist in the schedule. Little things have their place, and should always have clarity in what LEVEL they exist within and how data flows between levels.
Schedules fail in both directions. Too coarse, and the schedule cannot answer the questions the project asks of it - nobody can see what is actually holding up the tie-in, because it hides inside a 90-day activity called Install Compression Train. Too fine, and the schedule becomes a data-entry obligation: 40,000 activities, nobody statuses them honestly, and the critical path becomes an artefact of logic nobody has read in six months.
The real world sits in between, and it is messier than any textbook case. An immense level of detail legitimately lives outside the schedule: material take-offs, spool and weld registers, vendor document registers, ITR and punch lists, interface registers, and the offline trackers that a discipline lead maintains because it is faster than a change request to the planner. Rarely is work done, hammer in hand, with a schedule.
The mistake is treating that as a failure of discipline. It usually is not. Some systems are better at holding that detail than a CPM tool is. The failure is when those systems are not connected back to the schedule - no rolled-up count, no owning activity, no date that reconciles. And don't get confused with connected. There are endless ways we can connect outside detail into a schedule
In the schedule: vendor PO, certified vendor data, fabrication, FAT, ship, arrive site, set on foundation, mechanical completion, pre-comm, commissioning.
Not in the schedule: the 50 fittings, gaskets, bolt sets, instrument tubing, and cable glands.
Where they live: the material register and the vendor's shipping list, with a required-on-site date derived from the schedule's install activity.
The connection: one activity - bulks and fittings on site for compression - with a status that reads straight off the register. One bar in the schedule, 50 lines in the register, one shared date.
AACE RP 37R-06 is the industry's most direct answer: schedules exist at levels, each with a purpose and an audience. It gives you a vocabulary and a rough duration band - which is genuinely useful - but it will not tell you whether a specific fitting belongs at Level 4 or in a register. That part stays a judgement call.
Phases and gate dates. Read by the board.
Area and discipline summaries, major contracts, key interfaces.
The baseline of record. Resource loaded, Control Accounts and WBS, Updated with actuals/forecast for analysis.
Contractor working detail per system, package or work scope.
Look-aheads, ITR/punchlist trackers, spool and weld tracking. Usually not a schedule.
The practical rule most owner teams land on: the Level 3 schedule is the contractual overall project tracking tool with progress resources and often cost data too, Level 4 belongs to whoever executes the work, and Level 5 lives in trackers and short-interval plans that never enter the CPM tool. Similarly the concept of "resource" also change in each schedule level. The resource you track in the Level 3 schedule, can be much different than the resource that is tracked in the Level 4 schedule and again different to what is actually required to complete the tasks. Defining what information lives in each schedule Level is a critical aspect in the setup of any good project.
Run a candidate scope item through these. If it fails most of them, it belongs in a register or a look-ahead - not in the baseline.
Upper bound: DCMA flags activities over 44 working days. Anything longer hides progress and cannot be statused meaningfully. This is ultimately a loose ill defined measure, but does highlight the concept - can we progress it, and how are we progressing it? If longer duration activities are still easily progressed and updated with valid forecast dates, the longer duration is not an issue.
Lower bound: if an activity is shorter than your update cycle, it is either done or not done every period - it carries no progress information at Level 3. This is also critical. Its so nice to see perfectly defined schedule activities that can be simply tagged as "complete" as the duration is smaller than the update cycle. However, this leads to the question of "does tracking this small thing add value?". Always go back to the WHY.
The 8/80 rule: work packages between roughly 8 and 80 hours at the execution level. Useful for detail schedules, far too fine for a control schedule. Again, tracking these tasks is still vital as someone still need to do something at an allocated time. Think about this more like tracking the detail stops in an amazon delivery truck daily routing. Your CPM schedule is not about tracking and planning each delivery.
Practical target: 2–4 weeks per activity on a Level 3 control schedule, one to two update cycles. Personally, I constantly use longer duration activities under the assumption I have Level 4 and Level 5 detail behind it.
One activity, one control account. An activity that spans two control accounts cannot be time-phased or earned cleanly. This also queries how you have setup your control accounts. As obviously rules are made to be broken. I've managed countless schedule activities with resources from multiple control accounts. But the idea is sound, if this happens, perhaps the way in which you have defined your control accounts should be reviewed too.
One activity, one responsible party. Shared ownership is the most reliable sign you have merged two activities. When you get input to a revised forecast date, you need to ensure that input is owned by a specific resource and done in a consistent manner. Its good to define this at the baseline setup in your basis of schedule and also include notes about the entire process of defining activity ownership in your schedule management plan too.
Rolling wave. Detail the next two to three months; hold the rest as planning packages and detail them as scope matures. This is often a confusing topic. We also need to retain alignment with our baseline, but at the same time should always be actively adding/modifying activities to fit what we know today. If you do have a process to update your level of detail, make sure that process is defined in your schedule management plans.
Write it down. Your level-of-detail rules belong in the Schedule Basis Memorandum, so the next planner inherits the logic rather than reinventing it. Your basis of schedule should also be a constantly upated document that reflects contemporaneous changes that filter into the schedule.
The goal is not to eliminate trackers. It is to make each one a recognised system of record with a defined seam back to the schedule.
Engineering deliverables - deliverable register with gate weightings (Chapter 07).
Vendor data - VDR, with only the critical certified-data dates promoted to the schedule.
Bulk materials, spools, welds - material and fabrication registers, rolled up as quantity curves.
Interfaces - interface register, each entry mapped to a schedule milestone (Chapter 02).
ITRs and punch - completions system, by system and subsystem.
Contract development steps - CPDS, as a standard string per package (Chapter 03).
Give it an owning activity. Every register maps to at least one schedule activity that carries its aggregate dates.
Derive the register's dates from the schedule, never the reverse - required-on-site dates come off the install activity.
Roll progress up, not detail down. The schedule takes a percentage or a count; it does not take the rows.
Reconcile every period. If the register says 60% and the activity says 90%, that gap is the finding.
Name the owner. An untethered tracker with no named owner is the one that surprises you at handover.
There is no single standard that resolves level of detail. What exists is a set of documents that each bound part of the problem - read together, they get you most of the way there.
The closest thing the industry has to a standard on this exact question. Defines the Level 1–5 hierarchy and what each level is for.
Criteria for what qualifies as an activity: discrete scope, single responsibility, measurable, and assignable to one control account.
If you cannot state the logic honestly, the activity is probably at the wrong level.
Ties schedule maturity to project phase, and requires you to write down your level-of-detail rules as part of the schedule basis.
Source of the widely quoted 8/80 rule and the principle that decomposition stops at the point of reliable estimating and control.
Requires that all effort be captured - but explicitly allows detail to be held in subsidiary plans provided it is traceable and integrated.
The practical ceiling: activities longer than 44 working days get flagged. A useful upper bound on how coarse a control schedule may be.
Near-term scope in detailed work packages; far-term scope in planning packages, progressively detailed. This is rolling-wave planning written as a compliance rule.
Level of detail is a design decision about the schedule as a control and communication instrument, not a completeness exercise. The question is never "have we captured every nut and bolt" - it is "can this schedule answer the questions the project will ask, and can the team sustain it every period".
Where detail sits outside the schedule, that is fine - provided it sits in a named register, with a named owner, with dates derived from the schedule and progress rolled back into it. The unmanaged Excel file on somebody's desktop is the actual risk; the register is not.