A senior planner's walkthrough of building a military shipbuilding schedule: WBS, IMP/IMS, EVMS baseline, risk and execution, with a worked example.
A military shipbuilding schedule does not start with a list of production activities.
It starts with a contract, a technical baseline, a set of contractual deliverables, a work breakdown structure, an acquisition strategy, and a collection of events that define when the government and contractor will agree that the program has reached a meaningful state of maturity.
The scheduler's job is to turn all of that into an executable model.
That sounds straightforward until the first real program meeting. Engineering is talking about requirements maturity. Production is talking about material availability and design release. Procurement is talking about long-lead equipment. Quality is talking about inspection points. Test is talking about certification and trials. Contracts is talking about deliverables and changes. Finance is talking about the performance measurement baseline. Program management wants one answer to the question: "Are we still going to deliver the ship on the contractual date?"
The schedule has to connect all of those conversations.
For this article, one fictional program will be used throughout: the Harbor Sentinel-class Offshore Patrol Vessel program, a hypothetical newbuild program for a fictional government customer. Assume the contractor is building the first ship in a new class, followed by additional vessels using the same baseline design. The program is entirely illustrative: the dates, quantities, production rates, milestones and planning assumptions below are invented for demonstrating scheduling mechanics and are not associated with a real program. The example will be referred to simply as Harbor Sentinel.
The point of using a fictional program is not to simulate a particular real acquisition program. It is to demonstrate how a planner builds the planning architecture from contract award through delivery, and then maintains it during execution.
Start With the Contract, Not the Schedule
The first mistake inexperienced planners make is opening Primavera P6 or Microsoft Project and immediately creating activities. That is backwards. Before creating an activity, you need to know what the contractor has actually promised to deliver. The first planning package should therefore be a contract-review package, not a scheduling database.
At contract award, the planning team normally starts by assembling the contractual and programmatic source documents. Depending on the acquisition and the contract, these can include the Statement of Work or Performance Work Statement, Contract Data Requirements List, specifications, Contract Work Breakdown Structure, applicable Integrated Master Plan requirements, Integrated Master Schedule requirements, Earned Value Management System requirements, reporting requirements, milestone definitions, test requirements, configuration-management requirements, government-furnished equipment information, interface requirements and contractual delivery dates.
The precise collection varies from contract to contract. DoD's current IMP/IMS guidance explicitly emphasizes that the IMP and IMS should be tailored to the project and contract, rather than treated as a universal template.
For the planner, the important question is: what does the contract say must happen, and what evidence will demonstrate that it happened? That question drives almost everything that follows.
The first contract-review pass
The initial review is normally divided into several passes. The first pass is contractual. Extract the contractual start date; required delivery dates; options and potential future production; contractual milestones; government-furnished equipment; contractor-furnished equipment; CDRLs and due dates; required reviews; test obligations; reporting obligations; EVMS requirements; schedule reporting requirements; configuration-control requirements; change-control mechanisms; subcontracting requirements; and security and information-handling restrictions.
The second pass is technical: build a list of the major products that must exist at the end of the contract. For Harbor Sentinel, that might initially look like the complete vessel, an approved design baseline, propulsion system, electrical generation and distribution, navigation and communications systems, auxiliary systems, mission equipment, shipboard software, test documentation, trials results, technical publications, training material, spares and support equipment, and configuration records. This list becomes the first bridge between the contract and the WBS.
The third pass is schedule-related. Do not simply copy contractual milestone dates into the schedule: determine what each date actually means. "Delivery" might mean physical transfer of the vessel, or it might mean acceptance, or it might occur only after completion of specific documentation, trials, deficiencies and configuration records. If the contract defines acceptance separately from physical completion, the schedule needs to represent that distinction.
The first 30 days
During the first month, the planner's objective is not to produce the perfect detailed schedule. It is to establish the planning architecture. For Harbor Sentinel, the first month should produce at least: a contract requirements matrix; a preliminary CWBS; a preliminary OBS/RAM mapping; a milestone dictionary; a preliminary IMP; a schedule coding structure; a preliminary integrated milestone schedule; a major supplier and long-lead-item register; an assumptions and constraints register; a schedule-development basis; an initial risk-linked schedule; and a preliminary responsibility matrix.
For a broader walkthrough of this early contract-to-keel-laying sequence outside the military-specific contracting layer discussed here, see our article on Planning a New Shipbuilding Project: From Contract to Keel Laying.
At this point, the goal is to know whether the major contractual obligations can actually be represented in the planning system. If a CDRL exists but nobody has an activity responsible for producing it, that is a planning defect. If a contractual milestone exists but there is no network of work leading to it, that is a planning defect. If a long-lead propulsion component has a required onboard date but procurement is sitting outside the integrated schedule, that is a planning defect.
Days 30 to 60
The second month is about decomposition. Engineering, production, procurement, quality, test, logistics and program-management representatives need to begin breaking the major outcomes into executable work. This is where the schedule starts becoming recognizable as a shipbuilding schedule.
For Harbor Sentinel, "Hull Structure" is not a useful production activity. It becomes something more like structural design release, material requisition, plate receipt, plate preparation, panel fabrication, subassembly, block assembly, block inspection, block coating, block outfitting, block dimensional inspection, block transfer, erection, weld inspection, tank testing, and structural completion. The exact breakdown depends on the shipyard's production system: the scheduler should not impose a generic shipyard process on the production organization. The production organization needs to explain how the ship is actually built. (For a detailed look at sequencing this kind of block-level production schedule, see Building the Hull Block Construction Schedule.)
Days 60 to 90
By the third month, the goal is integration. The design schedule needs to connect to procurement. Procurement needs to connect to production. Production needs to connect to test. Test needs to connect to acceptance. Configuration management needs to connect to all of them.
At this stage, a planner should be able to select any major contractual milestone and work backwards through the network to identify the major technical and production conditions that must be satisfied. That is the beginning of an integrated schedule rather than a collection of departmental schedules.
Build the Contract Work Breakdown Structure Around the Product
The WBS is one of the most important planning decisions because it becomes the structural backbone connecting scope, cost, schedule, responsibility and performance measurement.
MIL-STD-881E provides the DoD framework for developing and presenting WBS structures for defense materiel. Its purpose is broader than simply creating a cost-reporting tree: it is intended to support planning, responsibility assignment, cost and schedule management, performance measurement and technical management. For ship programs, the relevant section is Appendix E, Sea Systems.
This matters because the sea-system structure is product-oriented, not simply a list of departments. Across MIL-STD-881's ship-related work and the closely associated Navy Ship Work Breakdown Structure convention, a ship is commonly organized into nine major top-level groups: Hull Structure, Propulsion Plant, Electric Plant, Command and Surveillance (communications and combat/navigation systems), Auxiliary Systems, Outfit and Furnishings, Armament, Integration and Engineering, and Assembly/Support Services. It also identifies common program elements such as Systems Engineering, Program Management, System Test and Evaluation, Training, Data, support equipment and other common elements that apply across defense programs generally, not just ships.
(For a step-by-step walkthrough of building a shipyard WBS in practice, see our lesson on Building the Newbuild Work Breakdown Structure (WBS).) There is an important qualification here: do not treat this top-level list as the detailed production WBS for a modern shipyard. The standard itself points users toward the Navy's Expanded Ship Work Breakdown Structure (ESWBS) for further lower-level detail where required. Current NAVSEA shipbuilding guidance likewise identifies MIL-STD-881E as the basis for the preliminary WBS and ESWBS as the ship-specific expansion where deeper reporting detail is needed.
Program WBS versus Contract WBS
The Program WBS can contain government and contractor effort. The Contract WBS represents the work being performed under the contractor's contract. MIL-STD-881E specifically describes this distinction and shows how a contract WBS can be extended below the government's reporting structure to manage subcontracted effort. It also states that the WBS should not be driven by the contractor's organizational structure.
That last point is fundamental. If an organization has a Hull Department, a Pipe Department, an Electrical Department and an Engineering Department, that does not mean the WBS should simply mirror those department names. Those are organizational structures. A product WBS should answer what are we delivering? The OBS answers who is responsible for delivering it? The intersection of those structures is where the control-account architecture develops.
Tailoring the WBS for Harbor Sentinel
For the fictional Harbor Sentinel program, a planner might initially develop something conceptually like this, under a top-level "1.0 Harbor Sentinel Ship System, 1.1 Ship": Hull Structure, Propulsion Plant, Electric Plant, Command, Communications and Surveillance, Auxiliary Systems, Outfit and Furnishings, Armament/Mission Equipment, Total Ship Integration/Engineering, and Ship Assembly and Support Services: then apply the common WBS elements (Systems Engineering, Program Management, System Test and Evaluation, Training, Data, Support Equipment, Logistics/Spares) at the appropriate level.
The actual contractual WBS may look different. The contract may prescribe certain reporting levels, and the contractor may then extend those levels for internal management: MIL-STD-881E explicitly permits contractor extension of the CWBS below the required reporting level, provided the extensions remain meaningful and product/management oriented.
Do not over-decompose the WBS
A common planning mistake is to make the WBS excessively detailed because the scheduler wants more information. That is not the purpose of the WBS, which should provide a stable scope structure: the detailed work should normally be represented in the schedule beneath that structure, not by extending the WBS itself down to the level of an individual pipe spool unless there is a compelling contractual or management reason.
This becomes especially important when the ship design changes. A well-designed WBS can survive changes in production sequencing. A poorly designed WBS becomes a reflection of whatever organizational chart happened to exist when the schedule was created.
Turn the WBS Into an Integrated Master Plan
The IMP is where many commercial planners initially get confused. It is not simply a high-level Gantt chart: it is event-based. The current DoD IMP/IMS Preparation and Use Guide describes the IMP as a hierarchy of Events, Accomplishments and Criteria. The IMS then adds a fourth level, Tasks, with time-phased schedule information. The hierarchy runs: Event → Accomplishment → Criteria → IMS Tasks.
An Event is a significant program assessment point. An Accomplishment represents a meaningful result that supports that event. Criteria define the objective evidence required to demonstrate that the accomplishment has been achieved, and that last part is where good IMP development differs from writing vague management statements.
A poor IMP criterion reads: "Design is mature." That is not testable. A better criterion reads: "All drawings required for the preliminary production release have completed the applicable internal technical review and are approved for the next design maturity stage." Now the team can determine whether it is complete. DoD guidance specifically emphasizes objective, measurable criteria and traceability from the IMP into the detailed schedule.
Worked example: design maturity
Event: Preliminary Design Completed.
Accomplishment 1: Major system requirements allocated. Criteria: ship-level requirements have been allocated to the applicable system elements; system interfaces have been identified; requirements without an identified verification method have been dispositioned; major technical assumptions have been documented; configuration baseline documentation has been released through the approved configuration process.
Accomplishment 2: Preliminary design package completed. Criteria: hull form and principal arrangement documentation has completed required review; major machinery arrangement is established; major electrical architecture is established; major system interfaces have been identified; weight and stability information has been updated to the required design maturity; open design actions have been dispositioned or formally accepted as residual actions.
Notice what is happening here: the Event is not itself a task. It is a maturity point. The IMS will contain hundreds or thousands of tasks required to satisfy the criteria.
Worked example: Critical Design Review
Event: Critical Design Review Completed.
Accomplishment 1: Detailed design maturity demonstrated. Criteria: production-level drawings for the defined design scope have reached the required approval status; design interfaces have been reviewed; major equipment specifications are released; configuration items have identified baselines; verification methods are defined; unresolved technical issues have approved disposition plans.
Accomplishment 2: Production readiness established. Criteria: production planning packages exist for the defined construction scope; material requirements have been identified; long-lead procurement packages have been released; manufacturing processes requiring qualification have identified qualification status; production engineering has accepted the released design for planned work.
Again, the important thing is evidence.
Worked example: keel laying
Event: Keel Laying Completed.
Accomplishment 1: Initial structural assembly established. Criteria: keel/block assembly has been positioned at the approved reference location; applicable dimensional inspection has been completed; required weld inspections have been accepted; applicable structural documentation has been completed; required configuration records identify the installed structure.
Accomplishment 2: Construction baseline established. Criteria: the shipbuilding construction configuration is formally identified; applicable material traceability records are complete; construction deviations have been dispositioned; production status has been reconciled against the approved schedule baseline.
The exact definition of "keel laying" is program-specific. A planner should never assume that a ceremonial event is identical to a technical completion milestone.
Worked example: launch
Event: Vessel Launched.
Accomplishment 1: Launch readiness established. Criteria: launch-critical structural work is complete; stability and weight condition is verified for launch; temporary arrangements required for launch are installed and inspected; launch system readiness is confirmed; safety and operational readiness reviews are complete.
Accomplishment 2: Launch executed. Criteria: vessel has safely transferred to the water; post-launch inspection is complete; critical temporary systems are established; vessel configuration is reconciled following launch.
Worked example: trials and delivery
Event: Acceptance Trials Completed. Accomplishment 1 (machinery and systems demonstrated) requires completed dockside testing, accepted propulsion and electrical tests, completed navigation/communications tests, and required safety-system demonstrations. Accomplishment 2 (trial deficiencies resolved) requires documented deficiencies, correction or formal disposition of anything affecting acceptance, completed retesting where required, and a final configuration that reflects the tested ship.
Event: Vessel Delivered. Accomplishment 1 (contractual acceptance package completed) requires complete contractual acceptance documentation, delivered technical data, complete configuration records, accepted training deliverables, accounted-for spares and support equipment, and any outstanding items falling within the contractual acceptance provisions.
DoD guidance recommends that Events represent significant program assessment points and that Accomplishments and Criteria provide the evidence supporting them. A good IMP therefore becomes a statement of what "done" actually means.
Build the IMS From the IMP, Not Beside It
Once the IMP is mature enough, the detailed schedule can be built. The DoD guide describes the IMS as the time-based schedule that adds Tasks beneath the IMP hierarchy, and emphasizes traceability among the IMP, IMS, WBS, SOW/PWS, EVMS and risk management system. This is where the planner starts doing what schedulers traditionally think of as scheduling, but the order matters.
Start with the required outcome
Suppose the Harbor Sentinel launch date is Month 24. Do not begin by entering "Launch Vessel, 0 days, Month 24." That produces a milestone but not a plan. Start by asking what must be true before launch can occur, then decompose those conditions into work: launch readiness review complete; stability condition established; launch-critical tanks prepared; hull integrity complete; launch cradle prepared; temporary systems installed; launch systems inspected; required documentation accepted; safety readiness confirmed. Then break those into actual work.
Define activities at the level of control
A schedule activity should be detailed enough that someone can answer who owns it, what it produces, when it starts and finishes, what it depends on, how progress will be measured, and what happens if it slips. "Complete electrical system" fails that test. "Install main switchboard section A" may pass, but if it takes 45 working days and has five distinct internal stages, it may still be too large. The right level depends on management need.
A worked logic network
Take a small fictional example for Harbor Sentinel's launch preparation, an eight-activity network:
- A: Complete launch-critical structural work. 15 days. No predecessor.
- B: Complete tank integrity testing. 8 days. Predecessor: A.
- C, Prepare launch cradle. 10 days. No predecessor.
- D, Install temporary launch services. 6 days. Predecessor: C.
- E: Complete launch stability calculation. 5 days. Predecessor: A.
- F: Conduct launch readiness inspection. 3 days. Predecessors: B, D, E.
- G: Conduct launch readiness review. 2 days. Predecessor: F.
- H: Launch vessel. 1 day. Predecessor: G.
The logic is simple: A feeds B, C feeds D, A also feeds E, and B/D/E all feed F, which feeds G, which feeds H. There are two principal upstream paths: A→B→F→G→H totals 15+8+3+2+1 = 29 days, while C→D→F→G→H totals 10+6+3+2+1 = 22 days. The first path controls the finish in this simplified network.
But E also matters. E has five days and depends on A, and its finish is earlier than B's, so it currently has some relative float. That does not mean E is unimportant: if E slips by enough, it becomes part of the controlling path. This is how a scheduler should think about criticality: a critical path is not a list of activities that management happens to consider important. It is a consequence of the schedule network and the selected calculation method and constraints.
Prefer logic over artificial dates
If an activity cannot start before an engineering release, link it to the engineering release: do not simply type the desired start date into the activity. If procurement cannot release an equipment purchase order until the approved specification exists, represent that relationship. If installation cannot begin until the supplier completes factory acceptance testing and the equipment is received, represent those conditions. A schedule that says "Install pump: 1 June" without representing why the pump can only be installed after design approval, procurement, manufacturing, inspection and delivery is not an integrated schedule. It is a date list.
Critical Path Is Only Useful When the Network Is Credible
The phrase "critical path" is frequently abused in shipbuilding. A planner should not tell management that "the critical path is hull fabrication" without being able to show the network. The path can move: today the controlling path might run through structural fabrication, three months later it might move into a long-lead propulsion system, and later still it might be driven by combat-system integration, software maturity or trials. This is particularly important in first-of-class construction.
The schedule should therefore be analyzed at several levels: the contractual milestone path, the ship-level critical path, major system paths, production-area paths, supplier paths, and test/acceptance paths. A procurement activity can have significant schedule influence without being globally critical. Likewise, an activity can have zero total float but not be the only path management should watch if there are multiple near-critical paths: activities with less than a selected float threshold can be grouped for management review, with the threshold itself established by the program rather than invented by the scheduler.
Resource Loading Turns the Schedule Into an Execution Model
A schedule without resources can tell you when work is theoretically possible. A resource-loaded schedule begins to answer whether the organization can actually perform it. For shipbuilding, this means more than simply adding "engineering hours": it means understanding the physical production constraints.
Consider a block fabrication area. The schedule may show panel fabrication, panel assembly, block erection, welding, inspection, coating and outfitting, but the production manager may explain that only two large blocks can occupy a particular bay simultaneously. That is a capacity constraint the schedule needs to reflect. Similarly: welding teams have limited capacity, certified welders may be limited, cranes have availability windows, blasting/painting facilities have capacity limits, electrical test teams are shared, commissioning engineers are shared, dock space is limited, launch windows can be limited, and specialist inspectors may be shared across several ships. The resource-loaded schedule becomes a production model.
The scheduler's conversation with production
Do not ask a production manager "how long does block fabrication take?": that question is too broad. Ask instead: for a block of this approximate size and configuration, what are the work steps, what is the normal crew composition, what is the expected direct labor, what capacity constraint controls throughput, and what must be complete before the block enters the next station? The goal is to extract the production model.
The same principle applies to engineering. Do not ask "how long does the machinery design take?" Ask how many drawings, what disciplines, what review cycles, what percentage can proceed before interface information is mature, which calculations control release, which external inputs are required, which approval is required before production can start, and how much rework is historically associated with this design stage. Those answers create better activities and better estimates.
Establish the Performance Measurement Baseline
Once the schedule is developed, the next question is how the organization will measure performance against it: that is where the Performance Measurement Baseline (PMB) enters. For programs subject to EVMS requirements, the baseline connects authorized scope, schedule and budget. The basic architecture runs: contract scope → WBS → control accounts → work packages/planning packages → budget → time-phased baseline → earned value.
The DoD EVMS framework uses the ANSI/EIA-748 EVMS guidelines as its industry-standard foundation, with the current DoD EVMS Interpretation Guide used to assess compliance. (For a worked walkthrough of applying EVM mechanics on a shipyard project, see our lesson on Earned Value Management on a Shipyard Project.)
Control accounts
A control account is the management-control point where defined scope, organizational responsibility, schedule, budget and performance measurement meet: MIL-STD-881E describes this as the intersection between the product-oriented WBS and the organizational structure. Suppose Harbor Sentinel has WBS element "Propulsion Plant," and the propulsion engineering organization is responsible for a defined portion of that scope: the program may establish one or more control accounts under that WBS/organization intersection. The Control Account Manager (CAM) then becomes accountable for scope, schedule, budget, performance, risk, forecast and corrective action, though the CAM does not necessarily personally manage every schedule activity: the CAM owns the control account's performance.
Work packages
A work package is where the detailed executable work is planned and performance is measured. For example, a control account for "Propulsion Plant / Main Propulsion Installation" might contain a work package to install main propulsion equipment in Machinery Space 1, with 2,400 labor hours, a material budget, start/finish dates, defined predecessors and successors, a progress-measurement method, and a responsible organization.
The budget is time-phased: the baseline does not simply say "2,400 hours," it says when those hours are planned to occur. A simple illustrative profile might spread that work as roughly 200 hours in month one, rising to 500 and then 900 in the peak month, before tapering to 600 and then 200 hours as the installation completes. That time-phased profile is what allows planned value to be compared with actual performance.
Planning packages
Future work cannot always be defined at work-package level. If detailed design for a later ship phase is not yet sufficiently mature, the remaining budget may be held in planning packages within the control account until it can be converted into executable work packages: commonly associated with rolling-wave planning. The important discipline is that planning packages are not a hiding place for poorly understood work; the organization should progressively convert them into detailed work packages as the work approaches.
The PMB is not the schedule baseline alone
A schedule baseline tells you what work is planned and when. The PMB combines the time-phased budget associated with authorized work and the performance-measurement structure. It is possible to have a technically attractive schedule that is still poorly integrated with EVMS: for example, if the schedule says 10,000 hours, the budget system says 8,000, the CAM says 12,000, procurement budget exists separately, subcontract budget sits outside the schedule, and the earned-value technique is undefined. That is not a functioning baseline. The planner, CAM and control-account organization have to reconcile these numbers.
Build the Basis of Estimate With the People Who Do the Work
The schedule duration should not be invented independently of the estimate. A Basis of Estimate (BOE) explains how labor, material, duration and other resource assumptions were developed. For shipbuilding, several estimating approaches are useful.
Analogous estimating uses a previous, comparable vessel as a starting point, but the scheduler must adjust for differences in vessel size, complexity, design maturity, production facilities, automation, workforce experience, material availability, supplier base, and repeat-production position. Simply saying "the previous vessel took six months, so this one takes six months" is not an estimate, it is an analogy; the value comes from explaining the adjustment.
Parametric estimating relates some activities to measurable drivers, such as structural fabrication hours per ton, pipe fabrication hours per spool, cable installation hours per meter, coating hours per square meter, engineering hours per drawing, or inspection hours per weld volume. The actual factor should come from the organization's validated estimating basis: production rates are highly dependent on shipyard process, product definition, facility, workforce and vessel configuration, so a universal shipbuilding productivity factor should never be invented.
Bottom-up estimating is often more defensible for new or unusual work: break it into preparation, fabrication, assembly, inspection, a justified rework allowance, testing and documentation, then estimate labor and duration for each. The scheduler should challenge the estimate without pretending to be the production superintendent: the right question is "what assumption would have to be true for this duration to work?" That question exposes hidden constraints.
Learning Curves Matter in Repeat Shipbuilding
Repeat production is different from first-of-class production, a well-established planning concept in industrial manufacturing and shipbuilding. When workers repeatedly perform comparable tasks, labor productivity can improve because processes become familiar, tooling improves, work instructions become clearer, material flow improves, engineering errors are reduced, production sequencing stabilizes, and workforce composition becomes more efficient.
But a learning curve should not be applied mechanically to every ship in a class: a later vessel may have design changes, the yard may lose experienced workers, the production line may change, a new supplier may be introduced, or a major equipment change may create a new learning cycle. Suppose Ship 2 of Harbor Sentinel uses essentially the same structural design as Ship 1 but incorporates several electrical-system changes. The scheduler should not automatically reduce every Ship 2 duration by the same percentage: structural block fabrication may benefit significantly from repeat production, while the modified electrical installation package may not. This is why schedule architecture matters: if the schedule contains a single activity called "Build Ship 2," learning cannot be modeled intelligently.
Procurement Belongs Inside the Ship Schedule
(For the procurement-side mechanics of getting major shipboard equipment onto contract in the first place, see our article on Procurement and Supply Chain for Major Ship Equipment.) One of the most common weaknesses in shipbuilding schedules is treating procurement as an external process. It is not: for major equipment, procurement is part of the ship's production path. Take a fictional main propulsion gearbox: the integrated schedule might contain defining the equipment requirement, approving the specification, issuing an RFQ, evaluating bids, approving the supplier, issuing the purchase order, approving supplier drawings, completing design review, manufacturing, factory testing, inspection, preservation, shipping, receipt at the yard, incoming inspection, installation, alignment, connection, testing and commissioning. Not every procurement package requires that exact sequence, but the scheduler needs to understand the supplier's actual manufacturing and approval cycle.
Supplier schedule integration
For significant subcontractors, the prime contractor may receive supplier schedules: the planner should not simply import dates. If a supplier says "equipment complete: 15 August," the prime scheduler needs to know whether that means manufacturing complete, factory acceptance complete, packed, shipped, delivered, accepted, or ready for installation. Those are different dates, and the integrated schedule should use the one that matters to the shipbuilding process.
Schedule Risk Is Not the Same Thing as Schedule Delay
A mature schedule distinguishes between a risk and an existing problem. If a supplier has already missed a contractual manufacturing milestone, that is an issue. If the supplier has not missed it but there is a meaningful probability that the date will slip, that is a risk. The distinction matters because the response is different.
For Harbor Sentinel, major schedule risks might include immature design at production release, long-lead propulsion equipment, insufficient skilled welding capacity, supplier qualification delay, late government-furnished equipment, interface instability, test-facility availability, software integration maturity, first-of-class production learning, and rework resulting from design changes.
Schedule risk analysis
A deterministic schedule says "Launch: 15 May." A schedule-risk analysis asks: given uncertainty in durations, logic, resources and identified risks, what is the range of possible launch dates? Monte Carlo-based Schedule Risk Analysis is commonly used for this purpose: the scheduler assigns probability distributions or uncertainty ranges to selected schedule elements and runs repeated simulations, producing outputs like the probability of meeting the contractual date, P50/P70/P80 completion estimates, the major schedule drivers, and the sensitivity of the finish date to individual activities or risks.
A useful schedule-risk analysis is not about producing a beautiful probability chart. It is about identifying what is actually driving uncertainty. If the simulation says the launch date is highly sensitive to three supplier activities, management should know that. If the uncertainty is dominated by an internal engineering process, management should know that instead. The DoD's 2023 IMP/IMS guide contains a dedicated section on Schedule Risk Analysis and Schedule Health, reflecting the role of risk analysis in integrated planning.
Schedule margin
Margin is often misunderstood: it should not simply be added to every activity. If every task receives arbitrary float, the schedule becomes padded rather than realistic. Margin should be managed at the appropriate program level and its use should be visible. Suppose Harbor Sentinel has a contractual delivery date in Month 42, and the internal management target is earlier: the difference between the internal target and the contractual requirement can provide management margin. That margin should not be confused with activity float: float belongs to the network, margin is a management reserve against uncertainty in the overall plan. The exact terminology and contractual treatment should follow the program's approved management system rather than an individual scheduler's preference.
First-of-Class Risk Changes the Schedule Fundamentally
A first ship is not simply Ship 1. It is also the place where the production system learns what the design really requires. A first-of-class schedule therefore carries several layers of uncertainty: design uncertainty (drawings are still evolving), manufacturing uncertainty (the production organization has not yet demonstrated the complete process), integration uncertainty (systems designed separately have to operate together), testing uncertainty (the first vessel may expose interface problems), and configuration uncertainty (as-built conditions can diverge from the initial design assumptions).
For repeat vessels, many of these uncertainties reduce, and the schedule should reflect that difference. This is one reason a master schedule should preserve enough structure to distinguish first-of-class work from repeat production: if the planner uses exactly the same activity structure for every vessel without identifying what is actually repeatable, lessons learned cannot easily be incorporated.
The Integrated Baseline Review Is Where the Plan Gets Challenged
The Integrated Baseline Review (IBR) is not a ceremony where the contractor presents slides and the government says "looks good." Its purpose is to examine whether the baseline is realistic, complete, logically scheduled, adequately resourced and sufficiently understood by both sides. DoD defines the IBR as a joint government-contractor assessment of the contractor's baseline, including achievability, authorized scope, logical scheduling, resourcing and inherent risk. Current DoD EVM guidance calls for the IBR to occur within six months after contract award for contracts requiring EVMS (a threshold generally applying to cost or incentive contracts valued at or above $20 million), with later IBRs potentially associated with major baseline events or modifications. The exact contractual requirement should always be checked against the current contract and applicable DFARS provisions.
What the planner takes into an IBR
Expect to need the approved CWBS, WBS dictionary, OBS/RAM, IMP, IMS, baseline schedule, schedule basis, logic report, critical-path analysis, total-float analysis, resource-loading report, major milestone report, subcontractor schedule status, long-lead-item register, schedule risk analysis, schedule assumptions, constraints, calendar definitions, baseline change process, and progress-measurement methodology.
The schedule needs to be explainable. If the government asks "why does this activity have a 120-day duration?" the answer should not be "that's what engineering gave us." The answer should be something like: "Engineering estimated 3,200 labor hours across four design disciplines. The planned staffing profile is 8 to 10 engineers. The duration also includes the two required review cycles. The predecessor is the approved requirements baseline, and the successor is production release." Now the duration has a basis.
Typical IBR questions
Expect questions such as: does the schedule cover all contractual scope? Can every major WBS element be traced into the schedule? Are subcontractor activities integrated? Are milestones supported by executable work? Are there excessive constraints or open-ended activities? Are durations reasonable? Is resource loading consistent with staffing plans? Are budgets consistent with planned work? Are work packages measurable? Are planning packages being used appropriately? Is the critical path credible? What assumptions drive the completion date? What are the major risks? Where is schedule margin? How will progress be measured? What happens if the baseline changes? The planner needs to know the answer to all of these before entering the review.
Schedule Execution Starts When the Baseline Is Frozen
A baseline schedule is not supposed to remain unchanged because the project team discovers reality: reality is exactly why the baseline exists. During execution, the planner maintains two different things: the current schedule (what the project now expects to happen) and the baseline schedule (what the approved plan said would happen). Do not overwrite the baseline every month, or the ability to measure variance is lost.
Weekly status
A practical shipbuilding status cycle might involve a progress-data cut-off, physical progress collection, engineering status, procurement status, production status, supplier updates, actual dates, remaining durations, forecast dates, constraint updates, risk updates, schedule-quality checks, and a critical-path review. The scheduler should challenge status: if a foreman reports "90% complete," ask what objectively remains. If the remaining work is substantial, the 90% figure may not be useful: particularly for long-duration activities.
Progress measurement
For a fabrication activity, progress may be measured using physical quantities, installed units, weighted milestones, earned hours, or objective completion rules. For engineering, it may be approved drawings, completed design packages, completed reviews, or released documents. For procurement: purchase order issuance, supplier drawing approval, manufacturing completion, factory acceptance testing, and delivery. For testing: test procedure approval, test conducted, test accepted, and deficiency closure. The progress method should be defined before the activity begins if it participates in formal performance measurement.
SPI and CPI Tell Different Stories
Earned Value Management provides several performance indicators built from Planned Value (PV), Earned Value (EV) and Actual Cost (AC): Schedule Performance Index (SPI) = EV / PV, and Cost Performance Index (CPI) = EV / AC. An SPI below 1.0 indicates that earned value is behind planned value in the chosen measurement basis. A CPI below 1.0 indicates that earned value is being achieved at a cost greater than planned.
These indicators are useful but should not be interpreted mechanically. A schedule can show an SPI problem because a major milestone has slipped, while another program can show acceptable SPI while a major future risk remains invisible because the work has not yet entered the performance-measurement period. Likewise, EVM does not replace critical-path analysis: a program can have reasonable cumulative cost performance while its contractual delivery path is deteriorating. That is why the scheduler and EVMS analyst need to work together; comparing actual spending with planned spending can be misleading without an independent measure of physical progress.
Variance Analysis Should Lead to a Management Action
A variance report that says "activity delayed by 15 days" is not enough. A useful schedule variance analysis explains what happened (the supplier's equipment drawing was returned with comments), why it happened (the interface specification was incomplete), the schedule impact (production release moves 12 working days), which path is affected (equipment installation becomes a driver of the commissioning sequence), the downstream impact (dockside testing moves unless another installation sequence is accelerated), the proposed action (split the installation package and release unaffected work earlier), and the decision required (engineering must approve an interim interface configuration by a defined date). That is schedule management: the schedule is not the final product, it is the model used to identify decisions.
Corrective action plans should change the network
Suppose Harbor Sentinel's electrical installation is 20 days behind. A weak recovery plan simply says "add manpower." A planner should model the proposed recovery: maybe the actual problem is not labor capacity but late cable-routing drawings, in which case adding electricians does nothing. A real recovery plan might instead accelerate drawing review, release approved areas progressively, split installation zones, add a second installation crew, extend working hours, prioritize commissioning-critical circuits, and resequence non-critical cable work. Then the planner models the effect. If the recovery activity has no measurable impact on the completion path, it is not a recovery plan: it is an intention.
Engineering Change Proposals Must Enter the Schedule Through Change Control
Shipbuilding programs change. Design changes can come from customer requirements, technical findings, regulatory requirements, obsolescence, supplier changes, weight management, integration problems, test results or safety issues. An Engineering Change Proposal (ECP) is one formal mechanism for proposing and evaluating such changes: the exact process and terminology vary by contract and configuration-management system. The scheduler's job is to determine the schedule consequences.
Suppose the fictional customer requests a revised communications system. The planner needs to identify the affected WBS elements, drawings, suppliers, procurement, production work, testing, documentation, training and configuration records, then identify the schedule impact. Do not immediately move the affected activity dates: first make the change visible. If the existing baseline shows communications equipment installation in Months 26-28, and the proposed change requires revised design, a new supplier, additional factory testing, modified foundations, additional cabling, revised software configuration and additional integration test, the planner can construct the change network from that list. Only after the change is authorized should the approved baseline be modified according to the program's change-control process.
This is essential for EVMS. If every engineering change is silently inserted into the current schedule without formal baseline control, the organization loses the ability to distinguish original performance, authorized scope change, contractor performance problems, and customer-directed change.
Baseline change versus forecast change
This distinction is fundamental. If the contractor is late because it performed the existing work poorly, moving the baseline to the new late date is not a legitimate way to erase the variance. If the customer adds authorized scope, the baseline may legitimately need to change. The change-control process establishes which situation exists. MIL-STD-881E specifically emphasizes maintaining traceability when WBS changes occur, and controlling changes once work begins to preserve the cost baseline.
Schedule Quality Needs Its Own Discipline
A schedule can contain thousands of activities and still be a poor schedule. A few basic quality checks matter throughout execution:
- Missing logic: every executable activity should generally have appropriate predecessors and successors; unexplained open ends should be investigated.
- Excessive constraints: hundreds of "Must Finish On" constraints usually mean the network isn't doing enough work; constraints can be legitimate but should not substitute for logic.
- Excessive lags: a lag can represent a real physical or contractual condition, but a hidden 60-day lag cannot be assigned, resourced, statused, risk-assessed or accelerated the way a real activity can.
- Long-duration activities: an activity like "complete propulsion installation" at 180 days may be too large for management to see problems early; break it down if visibility is needed.
- Out-of-sequence progress: if an activity starts before its predecessor is complete, determine why rather than simply accepting the status; the logic may be wrong, there may be a valid parallel path, or the work may genuinely be out of sequence.
- Resource overload: a schedule that requires 18 engineers against a staffing plan of 10 is not executable; resolve it through resequencing, additional staffing, subcontracting, overtime, duration adjustment, scope decomposition or a management decision, rather than hiding it.
Integrating the Schedule With the Shipyard Production System
A military shipbuilding master schedule should not operate as a separate planning universe. It should connect to the production-control system, which may hold detailed production schedules at the block, zone, compartment, system, work package or work order level. The master scheduler does not need to duplicate every production-control activity: the hierarchy needs to be connected. The master schedule answers "are we going to complete the block when required?" The production schedule answers "what work has to happen this week to make that possible?" Both are necessary.
The Planner's Relationship With Engineering
In a defense shipbuilding program, engineering is one of the most important schedule interfaces. The planner should track design maturity, not simply design activity duration. A useful engineering sequence might include requirements allocation, system architecture, preliminary design, detailed design, interface definition, equipment selection, design review, drawing approval, production release, and as-built update.
The important point is that production needs a usable design, not merely a completed engineering task. "Electrical Design 100% Complete" does not necessarily mean cable installation can begin: the relevant production criterion might instead be "cable installation drawings for Zone 3 released for production." That is a better schedule interface.
The Planner's Relationship With Quality
Quality is also frequently treated as an external function: that is a mistake. Quality activities should be integrated into the network where they control progression: material receiving inspection, weld inspection, nondestructive testing, dimensional inspection, pressure testing, coating inspection, equipment factory acceptance testing, installation inspection, system testing, and configuration verification. If production cannot proceed until an inspection is accepted, the schedule should represent that relationship: otherwise the schedule will show production progress that cannot actually advance the ship.
Testing Should Be Planned From the Acceptance Requirement Backward
Test planning is one of the areas where inexperienced schedulers often start too late. Testing should be considered while developing the design and production plan. For a system, the chain typically runs: requirement → design → verification method → test procedure → equipment readiness → installation → pre-test inspection → test → deficiency correction → retest → acceptance evidence. This chain is much stronger than a single activity called "conduct system test."
Testing also creates a feedback loop into engineering: a failed test may trigger an engineering investigation, a design modification, replacement material, reinstallation, a software change, and a retest. The schedule needs enough structure to represent that loop.
Configuration Management Belongs in the Schedule Architecture
A ship under construction is not simply a physical object: it is a controlled configuration. The design baseline, equipment configuration, software version, drawings, test results and as-built condition all need to remain consistent. For the planner, this matters because schedule completion should not be declared merely because something was physically installed. If an equipment item is installed but the approved drawing is missing, the equipment revision is incorrect, an interface document is unresolved, or the test procedure does not match the installed configuration, physical installation may be complete while the system is not contractually complete. This distinction becomes especially important near delivery: a ship can look finished while substantial configuration and documentation work remains, and the schedule needs to make that work visible.
Use the IMP as the Management Language
One of the strongest advantages of the IMP is that it gives the program a common language. Instead of "engineering is 85% complete," management can ask which design maturity accomplishments required for the next event have been achieved, and which criteria remain open: a much more useful question. The DoD guide explicitly describes the IMP and IMS as integrated management tools used to monitor progress, critical paths, program maturity, risk activities and technical performance.
For Harbor Sentinel, reviewing the next event (say, Launch Readiness) becomes a structured conversation, which accomplishments are complete, which criteria remain open, which open criteria have schedule-driving tasks, which are risk-related, which supplier deliveries support them, what the critical path looks like, and what recovery options exist. That is far more informative than a single percent-complete number.
A Practical Planning Hierarchy
By the time Harbor Sentinel is executing, several connected planning levels should exist. The program level holds contract milestones, IMP Events, major accomplishments and delivery commitments. The master schedule covers engineering, procurement, production, integration, test and delivery. The control-account level holds budget, work packages, planning packages, CAM responsibility and earned-value methods. The detailed execution schedule holds individual production tasks, work orders, supplier activities, engineering packages, inspections and tests. Short-term production control covers weekly work, daily priorities, constraints, manpower, material and work-front availability.
The mistake is trying to make one schedule perform all five jobs equally well. The master schedule should integrate the levels: it should not necessarily duplicate them.
What the First Baseline Should Look Like
When reviewing a new shipbuilding baseline, whether the Gantt chart looks impressive matters less than whether the underlying model can answer basic questions. Can you select the contractual delivery milestone and trace backward through design maturity, procurement, fabrication, installation, integration, testing and acceptance? Can you select a major equipment item and see its design release, purchase order, supplier engineering, manufacturing, factory acceptance testing, delivery, installation and commissioning? Can you select a control account and see its scope, responsible manager, budget, work packages, schedule, progress method, risk and forecast? Can you select a risk and identify the schedule activities that represent its mitigation?
If the answer to these questions is yes, the schedule is becoming an integrated management system. If the answer is no, more activities may not solve the problem: the architecture needs work.
The First 90 Days in Practical Terms
For a planner assigned to Harbor Sentinel on day one, a practical sequence looks something like this.
First two weeks: read the contract. Do not start by building activities: build the contract requirements matrix. Understand the contractual dates, CDRLs, milestones, specifications, EVMS requirements and data requirements. Identify what is explicitly required and what is merely assumed.
Weeks three and four: build the preliminary WBS, map major contract scope to it, identify the organizational owners, create the first Responsibility Assignment Matrix, identify missing scope, and start the milestone dictionary.
Month two: run working sessions with engineering, procurement, production, quality, test, logistics, configuration management and program management. Build the IMP. For every major event, ask what must be true for it to be complete, define accomplishments, then define objective criteria.
Month three: build the detailed IMS, starting with the criteria. Convert criteria into tasks, develop logic, add resources, load major procurement, integrate supplier schedules, connect engineering release to production, connect production to test, then perform schedule-risk analysis.
End of the first baseline cycle: conduct schedule-quality checks for open ends, excessive constraints, excessive lags, negative float, high float, resource overload, and missing procurement, test, documentation or risk-mitigation tasks. Then reconcile the schedule with the EVMS baseline. Only after that should the team treat the baseline as ready for serious performance measurement.
What Makes Military Shipbuilding Planning Different
Commercial shipbuilding can be extremely complicated. The difference is not that commercial ships are simple and military ships are difficult: the difference is the number of management systems that must remain synchronized with the technical and production work. A defense shipbuilding program may have a contractual WBS, IMP, IMS, EVMS, CDRL structure, configuration-management system, technical-review process, formal government oversight, security restrictions, cybersecurity requirements, test and evaluation architecture and formal baseline-change process operating simultaneously, and the schedule has to connect all of them. (For how a subcontractor experiences this same environment from the supply side, see our article on How Subcontractors Work on US Military Shipbuilding Programs.)
Government milestone discipline
The government is not simply buying a physical ship: it is managing an acquisition program with defined technical, contractual and programmatic decision points. That means maturity matters: a design review is not merely a meeting, a test event is not merely a calendar date, and a delivery milestone is not necessarily equivalent to physical construction completion. The planner has to understand the evidence behind each milestone. (Regulatory and classification-society milestones add a further layer to this: see our lesson on Managing Classification and Regulatory Milestones.)
EVMS creates another layer of discipline
In an ordinary commercial project, management might be satisfied with planned hours versus actual hours. In a formal EVMS environment, management needs a structured relationship among authorized scope, planned value, earned value, actual cost and forecast. That creates administrative overhead, but it also creates a stronger performance-management framework when implemented correctly: the baseline cannot simply be moved every time performance deteriorates, which forces the organization to distinguish genuine scope changes from execution problems.
Security changes the way information moves
Military shipbuilding can involve controlled technical information, classified information, export-controlled information and cybersecurity requirements, so the planning system itself operates within information-handling rules. The scheduler may not have access to every piece of technical information: that does not remove the need for schedule integration, but it means the schedule often needs to represent controlled work at an appropriate level without unnecessarily reproducing protected technical information. This is a different planning environment from a commercial shipyard where the complete technical package may be accessible to the project team.
First-of-class technical risk is substantial
A first-of-class vessel combines design maturity, supplier maturity, manufacturing learning, integration and testing risk, so the schedule has to model more than production duration: it has to model maturation. That is why an activity like "Complete Combat System" is usually inadequate. A mature planning model separates design, equipment procurement, supplier engineering, installation, software, interfaces, integration, testing, deficiency correction, retesting and configuration closure. The more technically complex the ship, the more important this becomes.
The planner is managing interfaces, not just dates
The strongest military shipbuilding schedulers think primarily in terms of conditions, not dates. A date is the visible output; the conditions underneath it are what make the date credible. For a production activity to start, the design must be mature enough. For procurement to proceed, the specification must be released. For installation to proceed, the equipment must arrive. For testing to proceed, the installation must be complete and inspected. For acceptance to proceed, deficiencies must be resolved and configuration must be controlled. The schedule is essentially a model of those dependencies.
That is why building a military shipbuilding plan is much more than learning a scheduling software package. The software can calculate dates. It cannot tell you whether the dates represent the way the ship will actually be designed, purchased, built, integrated, tested and accepted. That knowledge comes from understanding the contract, the WBS, the IMP, the production process, the engineering process, the supplier network, the EVMS structure and the risks that connect them.
A good master schedule is therefore not the longest schedule in the project office. It is the schedule in which a knowledgeable person can trace a contractual promise all the way down to the physical work that makes that promise possible, and then trace the resulting performance back upward into program management. That is the real job of the master scheduler.
The reason a program needs this much scheduling and EVMS machinery in the first place traces back to its contract type - see our article on Why the US Navy Doesn't Use Fixed-Price Contracts the Way Commercial Shipowners Do for why cost-reimbursement contracts require so much more visibility than a commercial fixed-price build.
