Certification-plan review before authority engagement

When this review is needed

• A plan is about to be submitted and the team wants it read before the authority sets expectations against it.
• The program scope changed and the plan no longer matches the work that will actually be done.
• The lifecycle plans the standards require are being assembled and need checking for completeness.
• An authority has questioned the plan and the team needs to know what to revise before responding.

The problem

A certification plan is a commitment, and the authority holds the program to it. Plans get written to look complete rather than to match the work, committing to methods the program will later want to change and naming lifecycle data the team does not intend to produce at the level claimed. The plan and the program drift apart, and every divergence becomes a discussion once the authority is reading from the plan it was given.

What gets reviewed

• Coverage of the certification basis by the plan's compliance approach
• The methods the plan commits to and whether the program can deliver them
• The software and hardware lifecycle plans required at the assigned levels
• The schedule and roles against the work and the delegation the program holds
• Consistency between the plan, the means-of-compliance plan, and the requirements
• Where the plan over-commits, under-specifies, or diverges from the program

What gets validated

• The plan covers every part of the certification basis with a stated approach
• Committed methods are ones the program can actually perform
• Software and hardware lifecycle plans exist and match the assigned levels
• The schedule and roles are consistent with the work and the delegation held
• The plan agrees with the means-of-compliance plan and the requirements set
• Commitments the program does not intend to honor are identified before submittal

Evidence normally required

• The draft certification plan and its compliance approach
• The software accomplishment and hardware design plans
• The means-of-compliance plan and the requirements set
• The program schedule, roles, and any delegation the team holds
• Authority questions on the plan if engagement has begun

Common discrepancies

• A plan that commits to methods the program does not intend to use
• Lifecycle plans that claim a level the program will not produce data for
• Coverage gaps where the basis is not addressed by the plan
• Schedule and roles inconsistent with the work or the delegation held
• Divergence between the plan and the means-of-compliance plan it should match

What is at stake

A plan that over-commits forces the program to either do work it did not intend or renegotiate commitments mid-stream, both of which cost time. A plan that under-specifies invites the authority to fill the gaps with expectations the program did not anticipate. Either way the plan stops being an asset and becomes a source of friction.

How the work runs

What the buyer receives

• Findings on where the plan over-commits, under-specifies, or diverges from the program
• A coverage view of the plan against the certification basis
• A consistency check between the plan, the means-of-compliance plan, and requirements
• A prioritized revision list ordered by the friction each gap will cause

Who uses the output

• Certification leads finalizing the plan before submittal
• Engineering teams aligning the lifecycle plans with the work
• Program management reconciling schedule, roles, and delegation

How the work fits into the transaction or program

The review checks the plan before the authority does, so the commitments the program will be held to match the work it can deliver. It draws on the basis and means-of-compliance mapping that the plan should reflect.

Regulatory limits

The review checks the applicant's plan for completeness and consistency. It does not accept the plan on the authority's behalf, agree the methods, or guarantee the authority will concur with the approach.

What this review does not cover

• Accepting or agreeing the plan on the authority's behalf
• Making compliance findings or assigning assurance levels
• Authoring the plan as the applicant's submission

Specific to this review

• A certification plan is a binding commitment in the eyes of the authority, so an over-built plan that promises more than the program intends creates obligations the program then has to honor or renegotiate.
• The lifecycle plans the standards require, such as the software accomplishment plan and the hardware design plan, are part of what the authority reviews, and a level claimed in the plan sets the objectives the later data must meet.
• Plan-to-program divergence is the failure mode a pre-engagement read catches, because the authority reads from the plan it was given, not from what the program actually did.

Sources

Frequently asked questions

Relevant glossary terms

Related pages

Where this fits