Design requirement and change management system
The team records the customer's requirements and their changes. The designers see which solutions need to be reviewed and what is already aligned with the customer.
The customer's decision or technical condition does not have a clear validity, approved content and relationship with the designer responsible for implementation. Different disciplines decide on different assumptions, and the lack becomes apparent when the project is already reviewed.
How the solution works
- The source, responsible validation and implementation criteria are determined for the requirement.
- It is linked to the designer's solution, calculation assumption, or agreed proof of verification.
- The proposed change raises the affected disciplines and the required impact assessment.
- The mandated decision confirms the new grounds for the claim and further steps.
- The update of the solutions and their verification are completed separately, while maintaining the state of the volume not yet performed.
Key challenges
- Customer requirements not managed in a structured manner
- The effects of the changes are not assessed systematically
Solution capabilities
Source and content of claim
The customer's decision or technical condition has a clear meaning, validity and responsible participant.
Implementation link
The requirement is associated with a specific solution, premise, or review criterion; the mere reference to a large document may not be sufficient.
Impact assessment of the amendment
Affected participants indicate the work required, the term and the known dependence before the updated basis is approved.
Decision and Exception
Confirmation, rejection or permitted exception preserves the reason and the right to accept it; contractual preference does not in itself cancel a mandatory technical condition.
Implementation verification
After the change, the necessary proof of the updated solution is collected, and incomplete revisions remain visible.
Business context
- Customer requirements not managed in a structured manner
- The customer's decision or technical condition does not have a clear validity, approved content and relationship with the designer responsible for implementation. Different disciplines decide on different assumptions, and the lack becomes apparent when the project is already reviewed.
- The effects of the changes are not assessed systematically
- The modified requirement is not linked to the affected assumptions, disciplines and required re-checking. Only the visible part of the solution is updated and the related documents and calculations remain unmatched.
- The consequences of the change are explained before it is approved
- The customer's request can affect several parts of the project, the scope and term of the work. The requirements associated allow to show what will need to be reviewed. The customer can make an informed decision, and the designer has reason to reconcile the additional works and their cost.
Core features
- Source and content of claim
- Implementation link
- Impact assessment of the amendment
- Decision and Exception
- Implementation verification
Key integrations
- Source of Customer's Decisions
- The condition approved, its amendment and the response of the authorised participant.
- Project Document and Model Environment
- A version of the specific solution and proof of the review performed.
- Discipline Work Plan
- Impact assessment of the change, assignment of the document update task and outcome.
Potential impact (%)
The ranges indicate an illustrative relative change in the metric under the stated assumptions. Results depend on the starting position and actual use of the solution. Percentages for different metrics must not be added together.
Additional work caused by the unobserved effect of the requirement
12–36%Decreasing
This illustrative scenario assumes that 30-60% of manual data entry and handover work can be addressed. That share is assumed to fall by 40-60%. Company data is needed to verify both the addressable workload and the resulting change.
Repair hours are measured, the reason for which was a late identification of an already known addiction.
Critical conditions without a reliable implementation link
5–25%Decreasing
This illustrative scenario assumes that 20-50% of missed actions can be identified through task and deadline tracking. That share is assumed to fall by 25-50%. Company data is needed to verify both the addressable share and the resulting change.
The selected set of critical conditions calculates unexplained gaps while checking the connection's contents.
Part of negative feedback on design change alignment
5–20%Decreasing
Indicative assumption: 20-40% of negative reviews involve unclearly aligned design changes. The solution could reduce this proportion by 25-50%. This is a scenario of potential; assumptions need to be verified by feedback collected by the company.
When a company starts collecting feedback, negative reviews about combining design changes are counted from all assessments received on the topic. The same method of assessment is applied before and after installation and similar customer groups are compared. Without initial data, the actual change is not determined.
Conditional calculation scenarios. The assumptions have not been validated against client measurements.
When this solution is relevant
- The change of the customer clause updates the drawing, but the calculation associated with it remains according to the previous assumption.
- The new requirement appears to have already been implemented in the report, although the designers' reviews are not yet complete.
Implementation requirements
The requirements for management are linked by the terms of the developer, the reasons for their changes, and the disciplines affected. Responsibility for impact assessment is combined with review of specific solutions; the existing project register is assessed on the basis of maintaining these links.
Further development options
- Adding recurring requirements to other projects with their terms of application
- Transmission of formalized information requirements for automated data verification