SEN: Project Configuration Management

SEN: Project Configuration Management

Aoddy System Engineer
Line
  • Project specificities
    • Project management activities
      • Preparation activities
        • Project Breakdown Structure
        • Project Organization
        • Project Phasing and Planning
      • Project control
        • Configuration & Data management
        • Risk management
        • Cost control
        • Schedule management
      • Support activities
        • Product Assurance Management
        • Integrated Logistic Support
        • Engineering management

  • The contractual constrains
    • Phases A&B as dedicated contract(สัญญา)
      • Feasibility analysis
      • Prototypes
      • System parameters
    • Then the C/D phase contract
      • Validated Customer’s requirements
      • Secured development plan
      • Risks control
    • A contractual contains
      • Commercial terms
      • Applicable documents (AD, appendices of the contract)
        • Input documents for the project team
        • Set of requirements
          • Technical requirements
          • Programmatic requirements – Programmatic คือเอกสารพวก Statement of works
      • Technical requirements
        • User’s requirements
        • External interfaces requirements
        • Design requirements (thermal, mechanical, availability, radiations, qualification, environment)
      • Programmatic requirements
        • Management
        • Deliveries (Documentations and products)
        • Development (Prototypes, qualification, models)
        • Quality
        • Configuration management
        • ILS (Integrated Logistic Support)
      • Functional Configuration Baseline = Set of customer’s requirements at the beginning of the contract
        • Change product >> impact>> programmatic baseline.
        • Change programmatic >>impact>> technical baseline.
          ** The configuration management principles apply to the programmatic data.
      • Link between technical and programmatic data
      • Baseline establishment / review process.
        • The documentation is formally sent to a review team : The review data package
        • The comments are formalized by using RIDs (Review Item Discrepancy(ความไม่ลงรอยกัน,ความไม่ตรงกัน,ความขัดแย้ง))
        • During the review process, the RIDs are accepted or rejected.
        • After the review, the documentation is updated by including the accepted RIDs.
        • The baseline is established and formally approved: review close-out meeting.
  • The Change Management
    • Level of responsibility of change
      • Cannot decide alone to apply a change if there is an impact on the customer’s requirements.
      • The customer has the authority for taking the decision, and will notify his decision to contractor.
    • Class of a change
      • Class 1: Change that affects approved technical specifications, including interfaces of the same level, and associated terms of the business agreement between a customer and his supplier.
        ** Needs of customer’s approval before any implementation.
      • Class 2: Change that does not fulfill class 1 change criteria
        ** Nevertheless, a class 2 change is sent for information to the customer which can decide to reclassify the change.
    • Class / Category
      • Class is related to the need to have an approval of the change by the customer.
      • Category is related to the interchangeability of the product.
    • Means
      • The Change Request (CR): Collects the information that formally defines a proposed project change versus the existing requirements.
      • The Change Proposal (CP): Is the vehicle for proposing a change to an approved baseline data or the business agreement.
      • The Change Notice (CN): Authorization by the customer to implement a change proposal (no specific format)
        ** For the change request and the change proposal, dedicated notices are used.
      • The Change File (CF): The change file gathers (ชุมนุม, รวมความคิด) all the information related to a change at the level of a product team.
    • The Change Request
      • Formalizes a modification of the baseline requirement:
        • Reformulation the impacted requirement
        • The new requirements are written.
        • A description and a justification of the change may be added.
      • A change Request is identified by its own reference.
      • The Change Request is emitted
        (ปล่อยออกมา) by a customer toward a subcontractor.
    • The Change Proposal
      • Describes the impact of a change on a product
      • Is formally approved
      • It is emitted by a subcontractor.
        • In response to a change request.
        • In a non solicited (เรียกร้อง) manner.
  • The Request For Deviation
    (ความคลาดเคลื่อน, ความเบี่ยงเบน) (RFD)
    is the vehicle for requiring and agreeing the departure from a customer’s requirement that is part of an approved configuration baseline.
    • Content
      • Identification of the impacted document and requirement.
      • Its affectivity
      • The new wording of the requirement.
      • The justification of the deviation.
    • A RFD is identified by its own reference.
    • It is submitted to the customer’s approval.
    • The customer has several means for raising a request for deviation:
      • By submitting a request for deviation to the next upper level.
      • By using the design margins.
      • By having a compensation
        (การชดเชย) solution at his level.
    • The RFD/RFW process is done with respect to the product tree.
  • The Request For Waiver is the vehicle for requiring and agreeing to the use or the delivery of a product that does not conform to its approved product configuration baseline.
    • Content
      • Identification of the related product item(s).
      • Affectivity of the waiver.
      • Identification of the impacted document.
      • Justification of the waiver.
    • A RFW is identified by its own reference.
    • It is submitted to the customer’s approval.
    • RFW processing
      • Similar to the RFD processing.
      • Waivers shall be limited to a number of items or a period of time.
      • The waiver will often need to identify a compensation solution on the system design.
  • Contract impact on change management
    • The customer waits for the end of the test phase for taking a decision on submitted RFD.
    • A supplier’s change proposal is contractual and has a limit of validity. If the customer is not enough fast for notifying a change, the project team shall ask a new change proposal to the supplier.
    • Some suppliers require to be paid for reading a new version of a document.
      • We avoid to submitting new issues.
      • Several issue of a document is valid at a given time.
  • Configuration Documents
    • For a given product, they are several types of documents:
      • Programmatic documents
      • Justification documents.
      • Configuration documents.
      • Other technical documents: Technical notes, test reports.
      • Project management documents.
      • Notices: CR, CP, RFD, RFW, NCR (Non Con-formance Report), RID.
    • Configuration documents according to the ECSS-M-40
Post Views: 1,895
Line

Wife lover.