Delivering change by looking down

Change as an initiator

Taking that an engineering process should be known, change is an initiator. We’ve seen in other articles that can be internal to an enterprise but external to its component parts. Internal to a department in a business function. Thus, setting the context is important and knowing that change is normal. Change needs to be managed and most importantly, communicated. There is a formally known process within Systems Engineering called Engineering Change Management.

Engineering Change Management

Engineering change management (ECM) is an authoritative, command and control, top down, mechanism for controlling and monitoring change within an Engineering department. These normally consist of:

• an Engineering Change Board (ECB)
• Engineering Change Requests (ECRs)
• Engineering Change Orders (ECOs)
• Engineering Change Notifications (ECNs)

Engineering Change Board (ECB)

The business culture generally dictates the nature of the ECB. These do not need to be formal in nature and often contain Engineering team leads. This can be made up of any employees, is normally used to agree, usually by consensus, that changes shall be made or not from requests. The board is there to make decisions on change within the context of Engineering which are captured in some way, usually called an Engineering Change Order. The ECB is guided by strategy, implements tactics and responds to operations, particularly with improvements.

Engineering Change Request (ECR) 

An ECR documents the origination of a request to change an artefact under the control of Engineering. Anyone internal to the company should be able to make an ECR. This may include suggested ways to address or fix the problem, what systems would have to change to fix it, signoffs to say the suggestions are approved and to move forward dependent on certain metrics applied by an ECB through the ECO process or direct to ECN.

3rd line support, maintenance which are smaller, uncomplicated pieces of corrective, adaptive, preventative and/or perfective maintenance generally pass straight through to the team responsible for the subsystem. Bigger or complex pieces being flagged at the ECB for approval.

Engineering Change Order (ECO) 

An ECO documents the items that may need to change as a result of one ECR, many ECRs (drawings, technical specs, SOPs, etc) or other work as the ECB sees fit. The level of decomposition should not go below system-level for implementation of these changes but ensure everything is in place for delivery to be a success. Not all ECOs are required to originate from an ECR and the ECO processes may be an independent process.

Engineering Change Notification (ECN) 

An ECN documents a notification to the appropriate or interested parties when the associated artefact change(s) are complete.

Quality

Taking a generic view, as part of a business engineering function to set as the problem domain. Within which are processes which fulfil a business need, perhaps to build or engineer a thing, whatever that might be. These generally have a start and an end or an initiator and a terminator. These may be delegated responsibilities to manufacturing, support, etc. Data in and out can also modelled. 

As an engineering organisation, these should be valid (engineering the right thing) also verified (engineering the thing right). The engineered things should be: valid against a known standard (which may be considered “to standard”; as well as developed against a process or verified. In principle, everything is then auditable by validation and verification activities. Meaning products are to standard and can guarantee products to customers, due to V&V activities. Thus, of a known quality!

Moving towards improvement

Change may be under control with the ECM but what about making things better? Improvement efforts require a model of how your organization works, which functions they need, and how those functions interact. A model gives you an understanding of organizational elements and assists in discussions of how and what can and should be improved.

A model offers the following benefits:

• Provides a common framework and language to help communicate
• Leverages years of experience
• Helps users consider the large picture while focusing on improvement
• Is often supported by trainers and consultants
• Can help solve disagreements by providing agreed-upon standards

Further, in engineering terms, closing the feedback loop enables informed control.