FOA CFOS/DAS common mistakes
FOA CFOS/DAS · Understand the traps and how to avoid them.
Computing a link's optical power budget by adding every connector and splice loss at typical values and stopping there, without subtracting the aging/maintenance margin or checking the result against the receiver's minimum sensitivity over the full wavelength and temperature range.
Candidates memorize the loss-per-connector and loss-per-splice figures from training and treat the budget as a simple sum, forgetting that the design must survive years of moves, adds, and temperature drift. The exam phrases this as a design scenario rather than a formula prompt, so the missing margin is not obvious.
What to do instead
Work every budget problem as a two-sided check: worst-case transmitter output minus worst-case receiver sensitivity gives the available budget; total worst-case link loss plus a stated maintenance margin plus repair splices must stay below it. Always state the margin explicitly and verify against the sensitivity at the longest wavelength used, since that is usually the binding case.
Choosing multimode fiber and a transceiver pair by category alone (for example "OM3 with 10GBASE-SR") without verifying the reach against the actual modal bandwidth and the standard's channel-loss allowance for the installed length.
The common shorthand tables pair fiber classes with Ethernet types, and candidates assume any OM3 run supports 10G to the full nominal distance. The distance limits in the standards are set by bandwidth and loss together, so a long run with several mated connections can fail even when the fiber class looks correct.
What to do instead
For each multimode link, look up the standard's specified reach for that fiber class and data rate, then confirm the installed length is inside it and the connector/splice count fits the channel insertion-loss allowance. Where the run approaches the limit, evaluate single-mode or an extended-reach option rather than assuming the class guarantees the distance.
Designing a pathway or cable route that ignores the physical constraints: bend radius under tension and at rest, conduit fill, tray loading, and separation from power conductors, then discovering at installation that the cable cannot be pulled or the route is not permitted.
Design questions often present a route in abstract terms, and candidates focus on optical performance while treating the physical installation as someone else's problem. Bend radius and fill limits are numerical and easy to overlook when the question emphasizes loss or bandwidth.
What to do instead
Treat the route as a design constraint equal to the optical one: check minimum bend radius during pull and after installation, compute conduit or tray fill against the applicable limit, and confirm separation or innerduct requirements from power cabling. Where a route cannot meet these, redesign the pathway rather than accepting a marginal pull.
Presenting a design with no redundancy or restoration path and no stated basis for choosing it, when the requirement calls for availability or diverse routing.
Candidates default to the shortest, cheapest topology and never revisit it against the stated service requirement. Diversity is also easy to claim without checking that the two paths do not share a conduit, vault, or entrance facility.
What to do instead
Start from the availability or restoration requirement, then select topology and routing to satisfy it. When diversity is required, trace both paths end to end and confirm they are physically separate at every shared point, and document the rationale so the design can be defended.
Building a bill of materials or cost estimate that omits the supporting items: patch panels, enclosures, splices, pigtails, test equipment time, permits, and contingency, leaving the estimate short of the real project cost.
Candidates estimate from the headline items (cable, transceivers) because those are what the design discussion names. The supporting hardware and labor are diffuse and easy to forget, and contingency feels optional when a number is demanded.
What to do instead
Estimate from a structured checklist by work area: cable, pathway, hardware, termination and splicing, test and commissioning, labor with productivity rates, permits, and a stated contingency percentage. Reconcile the estimate against the design drawings so every component on the route appears in the materials list.
Producing a schedule that shows only task durations in sequence, with no dependencies, no resource loading, and no critical path, so any slip silently moves the completion date.
A list of tasks with durations looks like a schedule and satisfies the format of the question, so candidates stop there. Dependencies and the critical path require an extra reasoning step that the prompt does not explicitly demand.
What to do instead
Build the schedule as a network: list tasks, assign predecessors, identify the critical path, and note float on non-critical work. Load labor and test resources against the calendar so conflicts surface, and show how a slip on a critical task propagates to the completion date.
Writing a project plan with no defined scope boundary, acceptance criteria, or change-control process, then treating every client request during the build as in-scope work.
Candidates equate the plan with the technical design and the task list, leaving out the management artifacts. Scope creep is invisible in a single-question scenario until the candidate is asked what happens when the customer adds a building to the route.
What to do instead
State scope explicitly as inclusions and exclusions, tie completion to measurable acceptance criteria such as test results and as-built documentation, and describe the change-control step that any added work must pass through before it affects schedule or cost.
Planning commissioning and acceptance testing as a single line item at the end, with no test plan, no pass/fail thresholds, and no allowance for rework when links fail.
Testing is perceived as a formality after installation, so it gets one line and no duration. Candidates also skip the thresholds because they assume the tester's default settings define acceptance.
What to do instead
Write a test plan that names the tests (insertion loss, length, polarity, and OTDR where required), the standard and thresholds that apply, the sampling or full-link coverage, and the documentation to be delivered. Budget time for troubleshooting and retermination, since failed links are normal on first test.
Ignoring the human and organizational side of planning: no stakeholder roles, no communication or escalation path, no permit and access lead times, and no risk register.
Technical candidates gravitate to the physical design and treat coordination as background. Lead times for permits, building access, and utility coordination are invisible in a task list that starts at cable installation.
What to do instead
Add a responsibilities matrix naming who approves, installs, tests, and accepts; list permits and access approvals as scheduled tasks with their real lead times; and keep a short risk register with owners and mitigations. Show these on the schedule so their duration is visible.
Failing to carry design decisions into the project documents: the as-built records, test results, and labeling scheme are left unspecified, so the delivered system cannot be maintained or traced to its design basis.
Candidates treat documentation as a deliverable to be produced later, not as a design and planning requirement. The link between the design's loss budget, the installed labeling, and the acceptance records is rarely made explicit in study.
What to do instead
Define the documentation set at design time: labeling convention, cable and fiber schedules, as-built drawings, and test reports tied to each link identifier. Make delivery of that set part of the acceptance criteria so commissioning cannot close without it.