Configuration Management Flashcards
1
Q
Testing
A
2
Q
Rescopes
A
Customer or stakeholder request for additional work or change focus/decision at a later date due to new findings and other
considerations
3
Q
Design Change
A
4
Q
Rework
A
Refers to the process of revising, modifying, or correcting a product, component, or document due to defects, errors, or changes that prevent it from meeting initial specifications or quality standards
Two possible sources:
1) Design Related (Late Development Cycle Changes)
2) Build Related (Recurring Manufacturing Defects, Substandard Quality)
5
Q
Baseline
A
[more]
Establish baselines at key milestones rather than continuously, to limit the frequency of full-scale audits and reviews. By managing CIs through stable baseline releases, you avoid unnecessary revisions and reduce the need for frequent audits, focusing instead on maintaining key version control points.
6
Q
“Change Traffic”
A
The flow or volume of change requests or modifications within a project or engineering team (informal term, not widely used)
7
Q
Realities of Design Changes
A
1) Bad requirements are more likely to change than good requirements
2) The longer a system’s development cycle, the greater the likelihood of a change in one or more requirements, which will in turn increase the length of the development cycle
3) Design changes become more expensive the later they occur in the development cycle
4) Excessive changes lead to cost growth and schedule slippage in a project
5) Change requests may cascade into other areas
6) Insufficient communication increases the likelihood of design errors
7) High change traffic can lead to decision fatigue and delays
8) Regulatory and compliance considerations may complicate design changes
9) Design changes are often driven by external factors beyond team control
10) Frequent design changes can impact team morale
11) Having a policy of being realistic is one of best ways to prevent unnecessary design changes
12) It’s super important that YOU control the changes rather than let the changes control the project
8
Q
Internally Driven Design Changes
A
Come from miscommunication or inconsistent assumptions between personnel or inadequate margins.
- These are caused by systemic problems within the team
- They are entirely preventable
9
Q
Externally Driven Design Changes
A
Come from an evolution in the stakeholders’ need(s) or a new (better) technology
- These are not within control of the team
- These are inevitable and cannot be prevented (best you can do is mitigate them by making the development cycle as short as possible)
10
Q
“Baseline Coherence”
A
11
Q
Importance of SPEEDY design and manufacture in the context of change control
A
Both the technological opportunities AND the customer needs are dynamic; they can be expected to change throughout the development cycle
- This means that the longer it takes you to design and build something, the more times you will have to implement some big change
12
Q
Biggest causes of design changes in the middle of the design process
A
1) Evolving customer requirements
2) Ill-considered design changes
3) New regulation/compliance requirements
4) Technological Advancements
5) Pressure to lower costs
6) Supply Chain Issues
7) Undesirable Testing Results
8) New customer feedback from earlier designs
13
Q
Role of Interfaces in Design changes
A
Interfaces are a core source of design changes
Good, well thought out interfaces and experienced interface management are one of the keys to preventing design changes later in the lifecycle
14
Q
Role of Requirements in Design Changes
A
Requirements are extremely dynamic, they are constantly throughout the design cycle.
- Evolving customer needs
- New Regulatory/Compliance issues
Keeping track of these changes means constant communication with the customers.
Historical Example: In the 1970s, the automotive industry faced new emissions regulations due to the U.S. Clean Air Act, which led to significant design changes in car engines and exhaust systems to reduce pollutants like carbon monoxide and nitrogen oxides
Contemporary Example: The European Union’s REACH (Registration, Evaluation, Authorisation, and Restriction of Chemicals) regulation has impacted industries ranging from electronics to textiles, prompting design changes to reduce hazardous substances like lead and cadmium in products
15
Q
How budget changes affect design changes
A
There will always be pressure to reduce costs and sometimes that pressure will necessitate design changes.
Historical Example: During World War II, cost-cutting initiatives in aircraft manufacturing led to design changes that used cheaper materials and simplified construction techniques, allowing faster production without severely compromising performance
Contemporary Example: In the consumer electronics industry, companies like Apple and Samsung continuously alter product designs to reduce production costs, such as by consolidating components on smaller circuit boards or using more economical manufacturing processes for mass production
16
Q
Role of Technology in design changes
A
SIGNIFICANT breakthroughs in technology that are made during the design process will need to be incorporated in the design (especially in electronics)
Historical Example: The adoption of transistors in electronics in the 1950s led to significant design changes, enabling devices like radios and computers to become smaller, more reliable, and more efficient compared to earlier vacuum tube designs.
Contemporary Example: The rise of 5G technology has driven changes in smartphone design to incorporate new antennas and chipsets, enabling faster data processing and better connectivity, which impacts everything from size to power consumption
17
Q
Role of Supply Chains in design changes
A
When a part or material you wanted to use suddenly becomes less available, you will have to change the design.
Historical Example: During World War II, rubber shortages due to restricted imports forced the automotive and military industries to design vehicles with synthetic rubber components, affecting tire and sealant designs
Contemporary Example: The global semiconductor shortage that began in 2020 led many automotive manufacturers to redesign systems to reduce dependency on certain chips or find alternative components, impacting car design and production timelines
18
Q
Role of Testing in design changes
A
Any time your test results reveal an undesirable behavior, you will have to initiate a design change
Historical Example: The Apollo 1 fire in 1967, which tragically killed three astronauts, led NASA to redesign spacecraft materials and electrical systems to be more fire-resistant, enhancing safety for subsequent missions
Contemporary Example: Tesla and other electric vehicle manufacturers have made design changes following battery fire incidents in testing, leading to improved battery casings, cooling systems, and emergency shutoff mechanisms to enhance safety
19
Q
Role of new customer feedback on design changes
A
Two modes:
1) Beta Testing (before production): Actually letting end-users use the product early so that you can find opportunities to improve it before it goes into production
2) Market Research (after production): Once the hardware is already in production/use, the engineering team will need to talk with ALL customers (not just the end-users) to figure out how to better meet their needs on the next version (the design for which should already be in progress)
Historical Example: In the early 20th century, Henry Ford’s assembly line production was modified multiple times to improve assembly speed, product quality, and worker efficiency, leading to better performance and usability of the Model T
Contemporary Example: Apple’s ongoing refinement of its iPhone models incorporates feedback on user experience, such as changes in screen size, camera placement, and button functionality, to improve usability and ergonomics
20
Q
Skills that an engineering team would need to efficiently develop a product despite several design changes
A
- Configuration Management
- Requirements Analysis and Management
- Systems Thinking
- Rapid Prototyping
- Cross-Domain Collaboration
- Agile Project Management
- Risk Assessment and Mitigation
- Data-Driven Decision-Making
- Version Control and Configuration Management
- Effective Communication
- Effective Time Management and Prioritization
- Automation and Tool Proficiency
- Being Realistic
21
Q
Role of being realistic in efficiently developing a product despite several design changes
A
1) Being realistic means that you can develop better (more realistic) requirements. The requirements need to reflect actual component/material availability and technological precedent
2) You can expect significant design changes if the original schedule is overly optimistic and unrealistic, due to inaccurate estimates or political decisions.
3) Just like the schedule, you can expect significant design changes if the original budget is overly optimistic and unrealistic -especially when it comes to man-years. If you need more talent/labor than you expected, that will affect how much money you have for hardware & AI&T (which means the team needs a clear understanding of the scope)
4) Need to be realistic about what work should be within the scope, might be added to the scope later, and should definitely not be in the scope. That way you are not surprised by scope creep later in the development cycle
5) Should include
22
Q
Scope Creep
A
Refers to the gradual expansion of a project’s original objectives, requirements, or deliverables beyond what was initially agreed upon, often without adjustments to resources, timelines, or budgets. This phenomenon typically occurs when new features, tasks, or requests are added incrementally, leading to project delays, increased costs, and, potentially, reduced quality.
23
Q
Uncontrolled Changes
A
Modifications to a project’s scope, requirements, or deliverables that are implemented without proper review, approval, or documentation. In project management, these changes can significantly impact timelines, costs, and quality because they bypass formal processes designed to assess feasibility, resource allocation, and alignment with project goals.
24
Q
Importance of CM documentation
A
Uncontrolled changes typically aren’t documented in project logs or tracked within the project’s baseline. This lack of documentation means the team may lose visibility into why certain changes were made, making future project reviews and audits difficult.
25
Importance of formal approval in CM
Since uncontrolled changes often arise from informal discussions or ad-hoc requests, they bypass the formal change control process. This means that key decision-makers or stakeholders may not be aware of the changes, leading to potential conflicts or misalignments in expectations.
26
Impact Assessment
An impact assessment is a systematic evaluation of how a proposed change, event, or decision may affect a project, system, organization, or stakeholders. This process helps teams and decision-makers understand the potential risks, benefits, costs, and scope of the change, enabling informed decisions on whether or how to proceed.
For example, if your team considers a software update, an impact assessment would explore costs, downtime, resource availability, potential improvement in functionality, and user training needs. Quantifying each of these factors (e.g., estimated downtime of 2 hours, additional training for 5 team members) helps you make an informed decision about the update’s feasibility and timing.
Conducting a thorough impact assessment ensures that changes are well-considered, risks are managed, and resources are used effectively, making it a valuable tool for project management and strategic decision-making.
27
Steps involved in doing an Impact Assessment
1) Define the Scope of the Change:
Clearly identify what the proposed change entails, including its purpose and scope. Document the details, such as the specific components or areas affected, who requested the change, and the objectives behind it.
2) Identify Stakeholders and Affected Areas:
Determine which teams, stakeholders, and systems will be impacted. This might include clients, project teams, end-users, or external entities. Map out direct and indirect areas of impact (e.g., affected departments, workflows, customer service).
3) Analyze Impacts on Key Areas:
Assess how the change will affect critical areas like time, cost, resources, quality, and risks. For each area, determine whether the impact is positive, neutral, or negative and estimate the extent:
- Cost: Estimate additional budget or savings resulting from the change.
- Timeline: Consider if and how the change will affect project schedules.
- Resources: Assess the need for additional personnel, tools, or materials.
- Quality: Determine if the change could improve or degrade system quality.
- Risks: Identify potential risks introduced by the change, such as operational, technical, or compliance risks.
4) Quantify Impacts Where Possible:
Use metrics and data to quantify impacts, such as increased costs, resource hours, and extended timelines. Quantifiable data makes it easier to compare benefits and drawbacks and make objective decisions.
5) Consider Alternatives:
Evaluate alternative options or ways to implement the change that might reduce negative impacts. For instance, could the change be phased in or approached in a way that minimizes disruptions?
6) Consult with Experts and Gather Feedback:
Seek input from subject matter experts, stakeholders, and impacted teams to validate assumptions and gather insights on potential impacts you may not have considered.
7) Document Findings and Recommend Actions:
Summarize the assessment in a report or impact statement. Include the analyzed impacts, quantified data, stakeholder input, and any identified risks. Recommend whether to proceed with the change, modify it, or reject it based on the assessment’s findings.
8) Review and Approve:
Present the assessment to the relevant decision-making authority, such as a Change Control Board (CCB) or project sponsor, for approval. Ensure all stakeholders understand the findings and agree on the next steps.
28
Importance of impact assessment in CM
Without proper evaluation, these changes may introduce unforeseen risks, dependencies, or resource needs. For instance, adding new features to a software product might impact system performance or require additional testing time, but these impacts remain unchecked when changes are made informally.
29
Role of change control in efficiently developing a product despite several design changes
Skill: Ability to assess, document, and implement changes systematically.
Benefit: Ensures that every design modification is evaluated for its impact on timelines, resources, and overall product objectives. Proficiency in change management tools (like Jira or SAP) is also helpful.
Application: Engineers use structured processes to prioritize changes and minimize disruption while ensuring all team members are aligned
30
Role of requirements analysis in efficiently developing a product despite several design changes
Skill: Breaking down customer and stakeholder requirements to understand their impact on product design.
Benefit: Helps the team make informed decisions about which changes are essential and align these with evolving requirements.
Application: Using tools like IBM DOORS or Jama Connect to trace requirements and maintain alignment between requirements and design
31
Role of systems thinking in efficiently developing a product despite several design changes
Skill: Viewing the product as an integrated whole rather than as isolated parts.
Benefit: Enables engineers to consider how changes in one subsystem affect others, essential for managing complex interactions in products like vehicles, medical devices, or electronic systems.
Application: Teams apply systems thinking to anticipate the ripple effects of design changes, ensuring modifications are compatible with the whole system
32
Role of rapid prototyping in efficiently developing a product despite several design changes
Skill: Proficiency in quickly building and testing prototypes or simulation models.
Benefit: Allows the team to test and validate design changes efficiently, reducing the risk of costly errors late in the process.
Application: Using tools like CAD software, 3D printing, or simulation software (e.g., MATLAB) to create rapid prototypes and test new design iterations
33
Role of cross-domain collaboration in efficiently developing a product despite several design changes
Skill: Working effectively with other teams, such as product management, manufacturing, and quality assurance.
Benefit: Ensures that changes are feasible from manufacturing and quality perspectives, helping to avoid delays and rework.
Application: Regular communication through tools like Slack or Microsoft Teams, as well as project management platforms like Asana or Monday.com, keeps all stakeholders in the loop
34
Role of Agile project management in efficiently developing a product despite several design changes
Skill: Proficiency in Agile, Scrum, or other project management approaches.
Benefit: Agile methodologies support iterative development, allowing teams to adapt to changes more flexibly and improve responsiveness to new requirements.
Application: Using frameworks like Scrum enables engineers to incorporate design changes incrementally and prioritize tasks based on impact
35
Role of Risk Assessment in efficiently developing a product despite several design changes
Skill: Identifying potential risks associated with design changes and developing strategies to mitigate them.
Benefit: Helps the team anticipate and reduce the impact of risks such as increased costs, delays, or performance issues.
Application: Applying tools like Failure Mode and Effects Analysis (FMEA) or risk matrices to evaluate and manage risks related to changes
36
Role of Data-Drive Decision Making in efficiently developing a product despite several design changes
Skill: Ability to use data analytics to assess the effects of design changes on performance, cost, and timelines.
Benefit: Provides objective insights that guide decision-making, ensuring that changes align with performance goals and project constraints.
Application: Leveraging software tools and analytics (e.g., Excel, Python, or R for data analysis) to evaluate historical data and predict outcomes of changes
37
Role of version control/configuration management in efficiently developing a product despite several design changes
Skill: Expertise in managing multiple versions of designs and configurations.
Benefit: Ensures that all team members are working on the latest version, reducing errors and conflicts from outdated information.
Application: Using version control tools like Git for software or PLM (Product Lifecycle Management) systems for hardware to track changes and maintain a single source of truth
38
Role of effective communication in efficiently developing a product despite several design changes
Skill: Clear and concise communication, both within the team and with external stakeholders.
Benefit: Prevents misunderstandings regarding changes, allowing for smooth implementation and alignment across functions.
Application: Communication skills are essential during review meetings, change board discussions, and documentation updates to keep everyone informed and aligned on decisions
39
Role of Effective Time Management and Prioritization in efficiently developing a product despite several design
Skill: Ability to prioritize high-impact tasks and delegate effectively to maintain focus on critical milestones.
Benefit: Keeps the team working on tasks that move the project forward, reducing time wasted on low-impact activities. Getting the design/build/delivery of a product done as quickly as possible means there will be fewer design changes to implement
Application: Techniques like the Eisenhower Matrix or Kanban boards help prioritize tasks based on urgency and impact, helping the team focus on essential tasks first
40
Role of Automation and Tool Proficiency in efficiently developing a product despite several design
Skill: Leveraging automated tools for repetitive tasks, such as automated testing, data analysis, or code generation.
Benefit: Automation can drastically reduce the time needed for routine testing, data collection, or configuration, freeing up time for critical problem-solving and design work. Getting the design/build/delivery of a product done as quickly as possible means there will be fewer design changes to implement.
Application: Familiarity with tools like Jenkins for automated testing, Ansible for configuration management, or LabVIEW for automated hardware testing can streamline testing and deployment
41
Qualities of a design that make it flexible and adaptable to design changes
1. Modularity
2. Standardization and Use of Interchangeable Parts
3. Scalability
4. Clear and Consistent Documentation
5. Layered Architecture
6. Loose Coupling
7. Use of Configurable Parameters
8. Redundancy and Fail-Safes
9. Forward and Backward Compatibility
10. Use of Simulation and Testing Environments
42
Role of modularity in efficiently developing a product despite several design changes
Description: Modularity allows a system to be divided into independent components or modules that can be modified, replaced, or upgraded without impacting other parts of the design.
Benefits: Modular designs make it easier to isolate specific parts for updates or improvements, enabling faster and more cost-effective changes. This approach is widely used in fields like software, electronics, and manufacturing, where different modules (e.g., memory or processors in computers) can be replaced as technology advances
43
Role of standardized components in efficiently developing a product despite several design changes
Description: Using standardized components and connectors across the design allows for easy interchangeability. This includes adhering to industry standards or creating standardized interfaces within the product.
Benefits: Interchangeable parts reduce the cost and complexity of implementing changes since replacements or upgrades can use readily available components. For example, the automotive industry often uses standardized parts, which makes upgrading or repairing systems more straightforward
44
Role of scalability in efficiently developing a product despite several design changes
Description: A scalable design can be expanded or reduced in scope without requiring significant redesign. Scalability is often built into the system architecture, allowing capacity adjustments in response to changing requirements.
Benefits: Scalable designs adapt well to increases or decreases in load, performance demands, or new functionalities. This quality is crucial in fields like data centers, where server capacity needs to scale with demand
45
Role of documentation in efficiently developing a product despite several design changes
Description: Detailed, well-organized documentation ensures that design changes can be made with a full understanding of the system’s components, interfaces, and dependencies.
Benefits: Consistent documentation facilitates collaboration across teams, reduces errors during design changes, and helps maintain a shared understanding of design intentions. It is essential for complex systems like aircraft or large software platforms where multiple teams may work on interconnected components
46
Role of documentation in efficiently developing a product despite several design changes
Description: Layered architectures separate functionalities into distinct layers (e.g., data, application, and presentation layers in software), enabling changes to be made in one layer with minimal impact on others.
Benefits: This design approach is common in both hardware and software and supports flexibility by allowing isolated changes within specific layers. For instance, in web applications, the front end can be redesigned without altering the back-end logic
47
Role of layered architecture in efficiently developing a product despite several design changes
Description: Layered architectures separate functionalities into distinct layers (e.g., data, application, and presentation layers in software), enabling changes to be made in one layer with minimal impact on others.
Benefits: This design approach is common in both hardware and software and supports flexibility by allowing isolated changes within specific layers. For instance, in web applications, the front end can be redesigned without altering the back-end logic
48
Role of "loose coupling" in efficiently developing a product despite several design changes
Description: Loose coupling means components interact with each other in minimal and well-defined ways, reducing dependencies between them.
Benefits: Loose coupling makes it easier to replace or modify a component without affecting the rest of the system, a concept widely used in microservices architectures and electronic systems where components communicate via interfaces rather than direct integration
49
Role of "configurable parameters" in efficiently developing a product despite several design changes
Description: Configurable parameters allow parts of the design to be adjusted through settings rather than physical or structural changes. These parameters can be modified to meet new requirements or adapt to different environments.
Benefits: Configurability adds flexibility by enabling changes through software or parameter adjustments, which is valuable in embedded systems and software-defined hardware
50
Role of "redundancy" in efficiently developing a product despite several design changes
Description: Designing with redundancy ensures that backup components are available to maintain system functionality if primary parts fail or need replacement.
Benefits: Redundancy supports flexibility by enabling components to be swapped out without affecting the overall system’s operation, a strategy commonly used in mission-critical systems like spacecraft and medical devices
51
Role of forward and backward compatibility in efficiently developing a product despite several design changes
Description: Forward compatibility allows designs to accommodate future updates, while backward compatibility ensures that new versions work with older components.
Benefits: Both types of compatibility make it easier to introduce design changes, whether by adding new functionality or supporting legacy components. This approach is common in consumer electronics, where software updates need to work on both older and newer models
52
Role of simulation in efficiently developing a product despite several design changes
Description: Simulation environments and test platforms enable designers to test potential changes virtually before implementing them in the physical design.
Benefits: This approach allows for flexibility by identifying the impacts of proposed changes early in the design phase, making it easier to iterate and optimize without costly physical adjustments. Simulation is widely used in automotive and aerospace industries to test designs under various conditions
53
Relationship between time and design changes
54
Baseline in Systems Engineering Design
At any point in the system’s life cycle, a
baseline divides the completed work from the
work in progress and planned future work.
This evolves through the development cycle
The system baseline actually grows in much smaller quanta than those depicted below.
55
Initial Capabilities Document (ICD)
56
57
Acquisition Decision Memorandum (ADM)
58
Clinger-Cohen Act Compliance
A historical example of design changes due to regulatory requirements involving Clinger-Cohen Act compliance can be seen in the transformation of federal IT systems in the late 1990s and early 2000s. The Clinger-Cohen Act of 1996, initially called the Information Technology Management Reform Act, was introduced to improve the efficiency of federal IT investments and promote accountability in IT project management.
Federal agencies were required to adopt an Enterprise Architecture (EA) framework to manage IT investments strategically. This requirement led to significant changes in IT system designs, as agencies standardized their architectures to align with federal EA principles and Clinger-Cohen Act mandates. These frameworks encouraged modular, interoperable designs to avoid redundant systems and enable data sharing across agencies.
The Clinger-Cohen Act enforced stricter project oversight and life-cycle cost management. Federal IT departments had to design systems with features supporting performance measurement and investment control, ensuring that each system component met specific return-on-investment (ROI) criteria. This resulted in changes like enhanced monitoring tools, dashboard implementations, and integration of performance evaluation metrics into IT system designs.
The act also mandated risk assessment as part of IT project design, promoting a structured approach to managing risks throughout the development lifecycle. This led to new design requirements focused on security, especially as systems were integrated across agencies with varying security protocols, impacting everything from access control systems to encryption methods.
59
Analysis of Alternatives (AoA) Plan
60
Material Development Decision (MDD)
61
Effects of Design Change on Schedule
62
Effects of Design Change on Budget
63
Canadian Firearms Registry Case Study
64
Systems Engineering Attitude Toward 'Design Change'
65
Engineering Change Request
An Engineering Change Request (ECR) is a formal document submitted to Configuration Management (CM) requesting and specifying a corrective action to a Developmental Configuration Baseline document that contains a latent defect such as an error, inaccuracy, deficiency, design flaw, etc.
* ECRs typically:
– Initiated to resolve an encountered issue or problem
– Dispositioned by a Change Control Board (CCB), typically chaired by the Project Manager
– Receive a Go/Hold/Kill/Recycle decision from CCB
– Tracked through decision process and, if approved, through implementation by CM
66
McMahon's Five Modes of Design Change
* Changes to the baseline and result in iterations between phases –backtracking.
* Excessive changes lead to cost growth and schedule slippage in a project
67
System Engineering attitude towards iteration and recursion
Iteration is possible in ALL phases of the design
68
Desirable v. Undesirable Behaviors
*Any undesirable behavior will trigger an engineering change (which may impact schedule and/or budget)
Undesirable behaviors fall into two categories:
1) Predicted - Means that you thought that might happen and (hopefully) have plans to mitigate it later on (causes a small change in budget and/or schedule)
2) Unpredicted - Can be mitigated, but usually requires significant design changes. Often results in major impacts to the schedule and/or budget
69
Predicted v. Unpredicted Behaviors
Good Predicted Behaviors are reflected in the spec for the project
Bad Predicted behaviors are RISKS (you need to identify those risks early on so that you can plan on how to mitigate them)
70
"UU Behaviors"
Unexpected Undesireable
- These are BAD surprises that are revealed during testing. If you cannot prevent or mitigate these issues, you will need to start over
- Sometimes called "Drgaons". Having to deal with these problems is sometimes called "being in the Dragon's Lair"
71
Design change predicted/desirable table
72
"Change Control" Definition
Definition: Change control is a specific process within configuration management that manages modifications to baseline requirements, components, documents, or processes. It ensures that any changes are evaluated, approved, and documented before implementation to avoid unintentional disruptions or errors. These policies and procedures are communicated to customers, contractors, suppliers, and everyone in the core project team
Purpose: The primary goal of change control is to ensure that each proposed change is systematically reviewed, with impacts on cost, timeline, and system integrity fully assessed. Change control minimizes risks associated with unplanned modifications by requiring formal authorization.
Scope: Focuses specifically on managing and implementing individual changes, typically by involving a Change Control Board (CCB) to review and approve or reject changes based on predefined criteria
73
Change Control Process
A baseline change is formally proposed as an Engineering Change Request, which provides a comprehensive impact assessment of the change (e.g. how far it ripples through the system baseline) and the justifying rationale
74
Configuration Management (CM) Definition
Definition: Configuration management is a broad discipline that tracks and manages all components and attributes of a system throughout its lifecycle. CM ensures that the system remains consistent with its requirements, design, and operational information, and encompasses change control as one of its processes.
Purpose: The purpose of configuration management is to maintain system integrity by recording, controlling, and tracking configurations, ensuring that every component is identified, documented, and can be replicated as needed.
Scope: Includes not only change control but also configuration identification, configuration status accounting, and configuration audits. It manages the entire system baseline, including hardware, software, and documentation configurations across the lifecycle
75
Version Control
Definition: Version control (subset within configuration management) is the practice of managing and tracking changes to digital files, primarily focusing on source code. This is also applicable to other digital artifacts like documents, configurations, or multimedia files. This process allows multiple versions of a file to be preserved over time, enabling teams to view the evolution of a document, identify specific changes, and revert to previous versions if necessary
Purpose: The main purpose of version control is to:
1) Enable Collaboration: Version control allows multiple team members to work on the same file or codebase simultaneously without overwriting each other's contributions. Through branching and merging, team members can independently develop features or fix bugs and then integrate changes smoothly.
2) Preserve Change History: It maintains a detailed log of modifications, including information on who made the change, what was altered, and when. This history supports traceability, auditability, and accountability.
3) Facilitate Rollbacks and Recovery: In cases of errors or unintended changes, version control allows users to revert to previous, stable versions of files, enhancing system resilience and reducing downtime.
4) Streamline Release Management: Version control organizes code or document changes across different release versions, providing a structured approach to manage updates and deploy new releases with clarity on what changes each version includes
Scope: The scope of version control includes:
1) File-Level Tracking: It tracks and manages individual files and documents, allowing detailed version management for each file or code module within a project.
2) Branching and Merging: Teams can create branches to develop features or experiment without affecting the main file version. Merging allows integration of these branches back into the primary version, facilitating collaborative workflows.
3) Multi-Version Management: Supports multiple versions of a project or file, maintaining consistency across releases and allowing concurrent development of new features and bug fixes on separate branches.
4) Distributed and Centralized Models: Version control can be implemented using centralized systems (e.g., Subversion) with a single authoritative repository or distributed systems (e.g., Git), where each user has a full copy of the repository, enhancing collaboration flexibility
76
"Change Control" v. "Configuration Management"
Configuration management provides the framework within which change control operates. Change control ensures that each alteration to the system is tracked and authorized, while configuration management oversees the overall stability and integrity of the system, encompassing and integrating all changes to maintain consistency
77
"Version Control" v. "Configuration Management"
78
Scoping
Purpose: Scoping, on the other hand, is an early-phase activity aimed at defining the overall project boundaries, objectives, and requirements. The scoping phase sets the foundation for the project by determining what will and will not be included, aligning stakeholder expectations, and identifying high-level goals and constraints.
Activities: Scoping involves gathering requirements, establishing project objectives, identifying constraints, and defining deliverables. This process produces documents like the project charter, scope statement, and requirements list, which serve as references for project planning and execution.
Timing: Scoping takes place at the beginning of the project lifecycle, typically during the initiation or concept phase. Once the scope is defined and approved, the project proceeds to detailed planning, design, and execution.
Focus: The focus in scoping is on establishing project goals and deliverables rather than tracking individual components. Scoping sets the "big picture" framework that the project will follow, ensuring alignment with client and organizational objectives
79
Configuration Identification
Second step in the CM process (after Configuration Management Planning)
Purpose: Configuration identification is a process within configuration management that involves defining and documenting the characteristics of each component within a system or product. This includes tracking all hardware, software, documentation, and other relevant items that make up the system. Configuration identification provides a baseline for managing, tracking, and controlling changes to these items throughout the project.
Activities:
1) Product Structure Definition: Break down the product into manageable CIs.
2) Selection of Configuration Items: Identify items critical to performance, safety, and compliance.
3) Configuration Documentation: Establish documentation for each CI, including specifications and drawings.
4) Baseline Establishment: Set reference points (baselines) for CIs at various stages (e.g., functional, allocated, product baselines).
Timing: Configuration identification typically occurs once the project has entered the development phase and specific components or subsystems have been defined. It continues as the project evolves, with updates occurring as items change or new items are added.
Focus: The primary focus is on organizing and managing the individual parts that make up the system to facilitate traceability and control throughout development and maintenance
Outcome: A clear identification system that uniquely labels each CI and establishes baselines for control.
80
Scoping v. Configuration Identification
Configuration identification focuses on organizing and tracking specific system components during development and beyond, while scoping is an initial planning activity that establishes project boundaries and objectives. Together, these activities support project organization and alignment, but they operate at different levels of detail and at different times in the project lifecycle
81
Configuration Items (CIs)
An entity within a configuration that satisfies an end-use function and can be uniquely identified at a given reference point.
Each configuration item is tracked, controlled, and documented to manage changes effectively, supporting project consistency and traceability across its lifecycle.
Characteristics of Configuration Items
1) Unique Identification: Each configuration item is assigned a unique identifier (such as a part number or name) to differentiate it from other items. This allows for clear tracking and management.
2) Version Control: Configuration items are often version-controlled to track changes over time. This means any updates or modifications are documented as a new version, preserving historical versions for reference.
3) Baseline Control: Configuration items are part of project baselines, which capture a snapshot of the project at a specific point. This baseline serves as a reference point for future changes and comparisons.
4) Documentation and Traceability: Each CI includes documentation that describes its characteristics, dependencies, and requirements. This documentation supports traceability, ensuring that each item’s changes are tracked and linked back to specific project requirements.
Examples of Configuration Items
1) Software Components: Code modules, scripts, or application libraries are considered configuration items in software development, as each module may have specific version requirements and dependencies.
2) Hardware Components: Physical parts, like circuit boards, processors, or power supplies, are CIs in hardware systems, as each part’s specifications must align with overall system requirements.
3) Documentation: Design documents, user manuals, test plans, and other essential project documents are also configuration items, as they provide critical reference information and context for system operation and maintenance.
4) Data Files: Files that store important data, such as configuration settings, databases, or control parameters, are tracked as CIs to ensure consistent data management and integrity.
82
CI Tiers
Typically the top tier of CIs directly relate to the line items of a contract and the work breakdown structure. The determination of the need to designate them as CIs is normally simple and straight forward. However, there are many cases in which other lower-level items should also be selected based on the management needs of the program.
83
Configuration Control Processes
Configuration Control Processes are systematic procedures within configuration management used to manage and approve changes to a project’s configuration items (CIs) and ensure the integrity and traceability of those changes throughout the lifecycle. These processes are essential in preventing unauthorized modifications, maintaining project consistency, and ensuring that changes align with project objectives and requirements.
84
ISO 10007
Quality Management—Guidelines for Configuration Management
Provide guidelines for implementing robust configuration control processes. Many organizations also use specialized tools like Jira, Git (for software), and PLM systems like Siemens Teamcenter to facilitate these processes, ensuring traceability and consistency across all configuration changes.
By following a structured configuration control process, organizations can safeguard project quality, consistency, and alignment with requirements throughout the development cycle.
ISO 10007 identifies six step process:
1) Configuration Management Planning
2) Configuration Identification
3) Configuration Control
4) Configuration Status Accounting
5) Configuration Audit
6) Configuration Management in the Product Life Cycle
ISO 10007 provides a structured approach to configuration management, emphasizing the importance of planning, identification, control, status accounting, and auditing. By following these guidelines, organizations can effectively manage product configurations, ensure quality, and achieve consistency throughout the product life cycle. The standard serves as a valuable tool for integrating CM into quality management systems, ultimately contributing to improved product performance and customer satisfaction.
85
Configuration Management Planning
First step in the CM process
Objective: Establish a CM policy and define objectives aligning with organizational goals.
Activities:
1) Develop a documented Configuration Management Plan (CMP).
2) Define roles, responsibilities, and authorities for CM activities.
3) Identify required resources, schedules, and training needs.
4) Determine methods, procedures, and tools for CM implementation.
Outcome: A comprehensive CMP that serves as a roadmap for CM activities throughout the product life cycle.
86
"Configuration Management Plan"
Purpose: Serve as a formal document outlining how CM will be conducted.
Contents:
1) Scope and Objectives: Define what the CMP covers and aims to achieve.
2) CM Activities: Detail procedures for planning, identification, control, status accounting, and audit.
3) Interfaces: Describe interactions with other organizational processes and external parties.
4) Resources and Schedule: Outline required resources and timelines for CM activities.
Maintenance: Regularly review and update the CMP to reflect changes in the project or organization.
87
Configuration Control
Third step in the CM process (after Configuration Identification)
Configuration control is the discipline of baseline management, including change control. Manage changes to CIs to maintain product integrity and traceability.
Activities:
1) Change Control Procedures: Implement processes for proposing, evaluating, approving, and documenting changes.
2) Impact Assessment: Analyze the effects of proposed changes on cost, schedule, performance, and compliance.
3) Change Implementation: Ensure approved changes are correctly implemented and communicated.
Outcome: Controlled and documented changes that maintain the product's consistency with its requirements.
88
Change Control Board
89
Configuration Status Accounting
Fourth step in the CM process (after Configuration Control)
Objective: Record and report information necessary for effective CM.
Activities:
1) Data Recording: Capture the status of CIs, change requests, and implementation activities.
2) Reporting: Provide accurate and timely reports on configuration information to stakeholders.
Outcome: An accessible repository of configuration data supporting decision-making and compliance.
90
Configuration Audit
Fourth step in the CM process (after Configuration Status Accounting)
Objective: Verify that CIs conform to specified requirements and that documentation accurately reflects the product.
Activities:
1) Functional Configuration Audit (FCA): Confirm that the functional characteristics meet the requirements.
2) Physical Configuration Audit (PCA): Verify that the physical attributes match the design documentation.
Outcome: Assurance that the product meets its specifications and that documentation is complete and accurate.
91
Configuration Management in the Product Life Cycle
Final step in the CM process (after Configuration Audit)
Objective: Apply CM activities appropriately throughout different phases of the product life cycle.
Activities:
1) Concept Phase: Define initial CIs and establish preliminary baselines.
2) Design and Development Phase: Intensify CM activities to handle increased complexity.
3) Production Phase: Control changes affecting manufacturing and quality.
4) Operation and Maintenance Phase: Manage modifications, upgrades, and maintenance records.
5) Disposal Phase: Ensure proper documentation and handling of product retirement.
Outcome: Consistent application of CM ensuring product integrity from inception to disposal.
92
Tailoring Configuration Management Strategy
Adjust CM processes based on:
1) Product Complexity: Scale CM activities to match product intricacies.
2) Project Size: Adapt the depth of CM practices to project magnitude.
3) Life Cycle Phase: Modify CM focus areas depending on the stage (e.g., more control during production).
4) Risk Factors: Enhance CM rigor for high-risk products or industries.
Implementation: Apply only the necessary CM components to avoid overcomplicating processes
93
Benefits of Effective Configuration Management
Product Integrity: Maintain consistency between design requirements and the actual product.
Regulatory Compliance: Ensure adherence to industry standards and legal obligations.
Enhanced Communication: Facilitate clear information flow among stakeholders.
Risk Mitigation: Reduce errors and defects through controlled changes.
Customer Satisfaction: Deliver products that meet or exceed customer expectations.
94
Change Requests (CRs)
Two Classes
Class 1: approved by the supplier
Class 2: approved by the customer
95
3 types of documented design changes
1) Modifications
2) Waivers
3) Deviations
96
"Modifications"
Modifications refer to deliberate changes made to a product or CI after its initial configuration has been baselined. These changes can be due to design improvements, corrections of defects, adaptations to new requirements, or technological advancements.
Guidance on Modifications from ISO 10007:
Configuration Control Procedures:
1) Change Requests: Modifications begin with a formal change request or proposal, documenting the nature and reason for the change.
2) Impact Analysis: Assess the potential effects on performance, reliability, safety, cost, schedule, and compliance with requirements.
3) Approval Process: A designated authority, such as a Configuration Control Board (CCB), reviews and approves or rejects the proposed modification.
4) Documentation Updates: Upon approval, update all relevant configuration documentation, including drawings, specifications, and user manuals.
5) Implementation Planning: Develop a plan outlining how the modification will be implemented, including resources, timelines, and responsibilities.
6) Verification and Validation: Ensure the modification meets the intended purpose without introducing new issues through testing and evaluation.
Configuration Status Accounting:
1) Maintain records of all modifications, including their current status and history.
2) Provide accessible reports to stakeholders detailing modifications and their impacts.
Communication: Inform all affected parties, such as engineering, production, quality assurance, suppliers, and customers, about the modification.
Outcome: Controlled Change Management: Ensures that all modifications are systematically evaluated, approved, and documented, maintaining product integrity and alignment with quality objectives.
97
"Waivers"
Waivers are official authorizations to accept a product or CI that does not fully conform to specified requirements but is deemed fit for use as-is or after limited rework. Waivers are typically granted for existing nonconformities discovered during inspection or testing.
ISO10007 Guidance on Waivers:
1) Nonconformance Identification: Detect deviations from specified requirements during quality checks, audits, or testing. Document the nonconformance, detailing the nature and extent of the deviation.
2) Waiver Request Process: Submit a waiver request outlining the nonconformance, its impact on performance and safety, and justification for acceptance. Include any proposed corrective actions or limitations associated with accepting the nonconforming item.
3) Evaluation and Approval: Conduct an impact assessment to evaluate risks and implications. The CCB or authorized personnel review the waiver request. Obtain necessary approvals from relevant stakeholders, which may include customers or regulatory bodies.
4) Documentation and Record-Keeping: Document the waiver approval, including conditions or limitations imposed. Update configuration documentation to reflect the waiver and any changes to the product baseline.
5) Implementation: Communicate the waiver and its conditions to all affected parties. Ensure that the nonconforming item is used or delivered in accordance with the waiver's terms.
Outcome: Informed Acceptance: Allows for the controlled acceptance of nonconforming items when it is practical and does not compromise essential requirements, maintaining transparency and traceability.
98
"Deviations"
Deviations are authorized departures from specified requirements granted before the product or CI is produced. They are temporary and typically apply to a specific quantity of products or a defined time period due to anticipated issues in meeting requirements.
ISO 10007 Guidance on Deviations:
1) Deviation Request Process:
- Identify the need for a deviation based on foreseeable challenges in meeting specifications (e.g., material shortages, process limitations).
- Submit a deviation request detailing the specific requirements to be deviated from, reasons, and the scope (e.g., specific lots or time frames).
2) Evaluation and Approval:
Assess the potential impact on product performance, safety, compliance, and customer satisfaction. Review by the CCB or authorized personnel, including engineering, quality assurance, and possibly the customer. Approval is contingent upon ensuring that the deviation will not adversely affect critical aspects of the product.
3) Documentation and Communication:
Document the approved deviation, including any conditions or mitigation measures.
Update configuration management records and baseline documentation accordingly. Communicate the deviation to all relevant departments and stakeholders.
4) Implementation and Monitoring:
Implement the deviation as per the approved plan. Monitor the products manufactured under the deviation for any unforeseen issues.
5) Closure and Review: Once the deviation period ends or the issues are resolved, revert to standard specifications. Review the deviation process to identify any lessons learned or improvements.
Outcome: Controlled Flexibility: Enables organizations to adapt to unforeseen circumstances without halting production while ensuring that any departures from specifications are authorized, temporary, and monitored.
99
Expense of CM
1. Maintaining accurate, detailed records is resource-intensive, often involving specialized software tools like Product Lifecycle Management (PLM) systems or version control platforms, which come with both purchase and maintenance costs
2. CM requires skilled personnel who are knowledgeable in CM standards, such as ISO 10007, and familiar with CM tools and processes, as well as regular training
3. Aerospace, defense, and large software projects can involve thousands of configuration items across hardware, software, and documentation, each needing identification, control, and traceability.
4. CM includes formal change control procedures, where each proposed change is carefully evaluated, approved, and documented. These processes involve multiple stakeholders, reviews, and impact assessments, all of which increase time and labor costs.
5. Regular configuration audits are necessary to verify that all items conform to their specifications and that documentation accurately reflects the current state of the system. Audits, along with compliance with industry standards and regulations, involve considerable time and effort
6. Effective CM relies on software tools to manage configuration items, track changes, and maintain historical data. Tools such as PLM systems, Jira, or Git, require significant initial investments and ongoing licensing fees
7. As projects evolve, CM systems require continuous updates to reflect new changes, versions, and baselines. Ongoing maintenance of CM systems and databases adds operational costs, especially for projects with long lifecycles.
100
Seven ways to distinguish between needed changes and un-needed changes
1. Alignment with Project Goals and Requirements
Ask: Does this change directly support the project’s primary objectives, requirements, or deliverables?
Needed Change: If the change ensures that the product or system meets critical requirements or goals, it is more likely to be necessary.
Unneeded Change: If the change doesn’t support core objectives and primarily adds optional features, it might be unneeded unless it significantly enhances value or usability.
2. Impact on Quality and Performance Standards
Ask: Will this change improve the quality, performance, or reliability of the system in a meaningful way?
Needed Change: Changes that address quality or performance issues that could affect functionality, safety, or user satisfaction are typically essential.
Unneeded Change: Cosmetic changes or enhancements with minimal impact on performance or reliability are less likely to be necessary unless they directly impact the user experience or satisfaction.
3. Risk and Compliance Considerations
Ask: Is this change required for regulatory compliance or to mitigate a high-risk issue?
Needed Change: If a change is required to meet regulatory standards or to address a critical risk (like a safety concern), it is necessary.
Unneeded Change: Changes that don’t affect compliance or reduce significant risks are often less urgent, though they may add value if aligned with other goals.
4. Resource Requirements and Feasibility
Ask: Do we have the budget, time, and resources to implement this change without compromising other project elements?
Needed Change: Essential changes typically justify the reallocation of resources, especially if they’re crucial for meeting baseline functionality or addressing critical issues.
Unneeded Change: If implementing the change would stretch resources or lead to significant delays without clear benefits, it might not be worth pursuing.
5. Cost-Benefit Analysis
Ask: Does the anticipated benefit of the change outweigh its cost in terms of time, money, and resources?
Needed Change: Changes that add clear value relative to their cost are worth considering.
Unneeded Change: If the cost far outweighs the benefits, the change is likely unnecessary and should be reconsidered.
6. Impact on Project Schedule
Ask: Will this change disrupt the project timeline or create bottlenecks for other tasks?
Needed Change: If the change can be implemented with minimal impact on the timeline, or if it prevents future delays, it’s worth considering.
Unneeded Change: If the change introduces significant delays or shifts priorities away from core objectives, it’s less likely to be necessary.
7. Stakeholder and User Impact
Ask: Will the change improve the experience or satisfaction of key stakeholders or end-users?
Needed Change: If the change resolves a major user pain point or addresses key stakeholder concerns, it may be necessary.
Unneeded Change: Changes that don’t significantly impact user experience or stakeholder satisfaction may not justify the effort.
101
CI Hierarchy
Need to group/rank the CIs based on how critical they are to the design. Those involving safety, performance, and compliance should get more CM attention than lower item CIs
102
Importance of Automation in CM
Automation in areas like version control, change tracking, and documentation updates can reduce manual workload and minimize human error.
103
Role of risk assessment in CM
The approval process for ECRs can be flexible and based on risk assessment. Fast-track approval processes for low-risk changes and require formal reviews only for high-impact changes. This approach reduces bottlenecks and keeps the focus on significant changes that warrant full review and documentation
104
Role of continuous training in CM
Ensure that team members understand the importance of CM and how to manage configuration items without excessive oversight. Training in best practices, such as logging changes accurately and avoiding duplicate documentation, helps streamline CM processes and reduces waste from unnecessary rework or miscommunication
105
Role of Efficiency Audits in CM
Periodic reviews of CM processes help identify inefficiencies and opportunities for improvement. Use feedback from these audits to refine processes, focusing on removing redundant steps, unnecessary documentation, or overly stringent controls that don’t add value.
106
Role of consolidation/'unity of location' in CM
This improves accessibility, reduces physical storage needs, and prevents time wasted on locating files. Cloud-based solutions or shared platforms (like SharePoint or Confluence) also support easy access and collaboration across teams
