- 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 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.
- 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