When you're working as the integrator on a large project, it can be very difficult to maintain a unified project baseline cross the prime and subcontractors. When the prime and subcontractors implement changes at different rhythms they each begin to work to a different set of documents. The baseline loses consistency. How can we mitigate this result?
A baseline is used to ensure all parties have a single source of truth to make decisions and progress work. It ensures the prime, integrator and subcontractors all move in the same direction and keep all interfaces aligned. Our goal is to ensure we provide that single source of truth at the lowest possible cost and risk.
It would be ideal to have a single project baseline and this happens at major milestones. We publish consistent baselines at every design review (PDR, CDR, etc.). These published baselines are essential to ensure everyone is aligned before proceeding to the next phase.
A baseline is used to ensure all parties have a single source of truth to make decisions and progress work. It ensures the prime, integrator and subcontractors all move in the same direction and keep all interfaces aligned. Our goal is to ensure we provide that single source of truth at the lowest possible cost and risk.
It would be ideal to have a single project baseline and this happens at major milestones. We publish consistent baselines at every design review (PDR, CDR, etc.). These published baselines are essential to ensure everyone is aligned before proceeding to the next phase.
Between milestones it's much harder to maintain a single baseline. To ensure subcontractors can proceed with work you need to provide them a firm baseline. Every change request made needs to be flowed out to all affected subcontractors, but not all subcontractors will accept or respond to changes at the same rate. As time goes on each subcontractor begins to march to their own drummer. If not closely managed, the design loses consistency. System interfaces become misaligned. Functions that depend on those interfaces fail to work as expected.
You can ensure design coherence by not authorizing any changes until all subcontractors and the prime approve. Essentially, you're creating a milestone baseline at each and every change. However, this will slow down the rate of change considerably. If you're still in a fluid phase of design, you'll quickly be overwhelmed by a backlog of needed changes. If not managed carefully you'll build a technical debt that will be very difficult to clear prior to the next major review milestone. This can lead to schedule delays and cost over runs.
You can ensure design coherence by not authorizing any changes until all subcontractors and the prime approve. Essentially, you're creating a milestone baseline at each and every change. However, this will slow down the rate of change considerably. If you're still in a fluid phase of design, you'll quickly be overwhelmed by a backlog of needed changes. If not managed carefully you'll build a technical debt that will be very difficult to clear prior to the next major review milestone. This can lead to schedule delays and cost over runs.
Which approach is best for your project depends on the phase of the project and how well structured it is. Early in a project its easier to use a single baseline that you can later split as you firm up the interfaces to the subcontractors. A well structured project, one with very orthogonal requirements allocated to subcontractors, can be managed with a single baseline. Projects where subcontractor's work heavily overlap are more easily managed as separate baselines.
-Michael Sepa, P.Eng
23 Sept 2014
INCOSE Canada publishes an article of technical interest to engineers each week. You can read them all by clicking here.
-Michael Sepa, P.Eng
23 Sept 2014
INCOSE Canada publishes an article of technical interest to engineers each week. You can read them all by clicking here.