AUDIENCE
The primary audience and gatekeeper for the proposal is Albert Smith, CMO (Change
Management Office) Manager within Systems Engineering for AD Engineering. It is his
responsibility to monitor the CMO processes including ECs. He is not heavily involved in the
daily EC process; he primarily serves as a liaison with the customer in case there is an issue or debate with a particular EC. Furthermore, he supervises all of the other employees within the EC workflow so he would be responsible for implementing any changes to the workflow. During my time at AD Engineering, I worked closely with Mr. Smith because I was responsible for monitoring EC progress through the workflow and communicating with the customer BAC.
The secondary audience is Lynn Johnson, Chief Systems Engineer of AD Engineering.
The proposal is relevant to her because she is responsible for all aspects of
Systems Engineering. Moreover, she works closely with Albert (CMO) to monitor ECs due to
their importance to the testing process and schedule. Also, Lynn works closely with the
customer’s program leads, which would allow her to provide insight about the customer’s
feelings about certain improvements. Lynn was not directly involved with the EC process but
would check with me on the statues of program critical EC’s when necessary.
The tertiary audience would be the AD Engineering IPT (Integrated Product Team) leads
because they are a part of the EC process from the very beginning of the design all the way until customer approval and implementation. The IPT leads include Doug Blackmon for Airframe, John Martin for Engines and Fuel, and Steve Spusnik for Dynamics. The IPT leads are generally the ones that generate the original ECR and work the EC through the entire process. Therefore, they would provide the best evaluation of the effectiveness of the new process. I did not work very closely with them but have interacted with them a few times
Student Name
1234 Knox Road
College Park, MD, 20740
3 May 2016
Dear Mr. Smith,
I am an undergraduate at University of Maryland that had worked for AD Engineering last year in the CMO office on the Trinity Program. While working there, I noticed that the current Engineering Change (EC) process takes a significant amount of time to work through and has caused delays in the test program. I have prepared a proposal, based on extensive research, that describes different approaches to mitigating the EC processing time problem.
This report outlines the EC processing time problem then examines the different causes of this problem and provides solutions designed to eliminate or reduce the impact those causes have on EC processing time. The solutions were then analyzed based on relative cost, implementation time, and whether the workload is on engineers or CMO. These criteria were used because these were the greatest areas of concern when discussing the solutions with Michelle Hauff.
This proposal will enable you, Systems Engineering and the IPT’s to design a better EC management process that will allow for faster processing time. The faster processing time will ease the design and testing programs to push the Trinity Program forward. Thank you for taking the time to consider my recommendations. If you have any questions about my research, please feel free to contact me at student@terpmail.umd.edu. I hope that this document was valuable and I wish the best for you and the future of the Trinity Program.
Sincerely,
Student Name
Proposal for Engineering Change Management at AD Engineering
Student Name
May 3, 2016
Prepared for Al Smith, Change Management Office Manager for the Trinity Program at AD Engineering
Table of Contents
Introduction. 1
Background. 1
Purpose. 3
Methodology. 4
Cost. 4
Implementation Time. 4
Workload. 4
Analysis. 5
Findings. 5
Interview.. 5
Survey. 8
Results and Evaluation. 9
EC Definition. 10
Cost. 10
Implementation Time. 11
Workload. 11
Standard Document. 11
Cost. 11
Implementation Time. 12
Workload. 12
Integration Solution. 12
Cost. 12
Implementation Time. 13
Workload. 13
Recommendation. 14
Reasoning. 14
Variations. 14
Conclusion. 15
Works Consulted. 17
Introduction and Context
The change approval process is used by almost every architectural, manufacturing and engineering company in the world. During the design process, the customer provides a list of objectives the product needs to fulfill, that are organized into needs and wants. The engineers then design the product to fit these needs and wants as closely as possible without compromising on other vital characteristics, such as safety. Throughout both the design and lifetime of the product, changes will be required because of either changing customer needs or an issue was found that needs to be addressed. This required change initiates the Engineering Change Approval process, which encompasses all of the steps between redesign, customer approval and implementation. The Engineering Change process is vital to a company because it greatly influences a project’s time and cost (Reddi and Moon 1225).
The change approval process at AD Engineering has 4 key parts: Engineering Change Request (ECR), Change Approval Board (CAB), Engineering Change (EC) design process and Implementation. The ECR consists of a form submitted to the CAB describing the issue that requires a design change or the reasoning on why a design change is necessary. An ECR can consist of any change from simple forging difference of one part to an entirely different assembly of a system. The initiating engineer will present this ECR to the CAB, who will decide whether or not this is a change that should be pursued. The EC design process itself has 5 steps that must be followed to have the EC approved by both the customer Bachman Aircraft Corporation (BAC) and AD Engineering. These steps include: Design, Design Review, CMO Review, Customer Review and Release (see figure 1). An important characteristic of AD Engineering’s EC design process is the Customer Approval step, which is when BAC’s engineers and Change Management Team (CMT) review the EC data package. This review is comprehensive and includes an in-depth review, by BAC engineers, that the engineering design for flaws or potential issues as well as a paperwork review by CMT. BAC’s review will result in one of three different outcomes: Accepted, Conditionally Approved or Rejected. Accepted means that the design change was approved by BAC, and AD Engineering can proceed with the design change. Conditionally Approved means that the design change was approved for testing purposes but BAC will need to review the test data before final approval. Rejected means that BAC found an issue either in the engineering design or in the paperwork that needs to be addressed before AD Engineering can proceed with the design change. A rejection causes the EC to go back to the first step of Design and work back through the process. Due to the implications and intensity of the Customer Review step, this step greatly affects the processing time of EC’s within the system. In turn, the long EC processing time causes the testing program to slow while engineers wait for the EC to be approved. This delay in the testing process has serious financial implications for AD Engineering. AD Engineering is contracted to fulfill all of BAC’s testing requirements in a certain time frame and under a certain budget. The testing time delays caused by EC processing costs money and once the budget dries up AD Engineering will be footing the testing bill by itself. Therefore, EC processing time problem has serious monetary implications for AD Engineering and the Trinity Program.
Models and Analysis
In order to provide a set of solutions that were financially practical, I developed a set of evaluation criteria to assess the potential EC process changes. The primary criteria that was used to assess the potential solutions were: cost, implementation time, and workload.
Cost
Cost is the most important factor to consider when evaluating these solutions because it is integrated into everything. EC’s themselves represent 20-50% of total costs for the program (Tavčar and Duhovnik 205). Therefore, EC’s account for a major portion of the Trinity program’s budget so the cost for the solutions cannot be too high that it counteracts the gains by changing the process. So this criterion will examine the implementation cost of the change as well as the potential savings gained from the change.
Implementation Time
Implementation time is an important factor when evaluating these solutions because it accounts for the relative time that EC’s will be held up in the process while the system gets renovated. The evaluation of this delay is crucial because it shows the effect the solution will have on the testing process. If the solution has a long implementation time, then the subsequent delay of the testing process will result in future revenue losses. This determines whether or not the solution is viable in the long-term. Ergo, implementation is a crucial factor when evaluating solutions because it evaluates the viability and cost of the solution from the long-term perspective rather than the short term perspective gained from the cost criteria.
Workload
The workload criterion is designed to assess where the solution will add a new workload. Based on the details of the solution and its implementation, it will create a new workload for one or more of the following groups: AD engineers, AD CMO, BAC engineers or BAC CMT. The increase in workload for these groups could be slight or considerable, depending on the specific solution. However, these criteria will provide insight into how it affects each of these groups in order to determine the overall effect on EC processing time.
Analysis
Due to the privacy policy of AD Engineering and the secure nature of the Trinity Program, the analysis of these criteria will be a qualitative comparison to the other potential solutions. Therefore, the criteria will not be assessed per criterion but in an overall pro and con format to ease the comparison between the different solutions. This format will not only allow the criteria to be discussed qualitatively but also make the comparison between solutions easier. My final recommendation will be based on the best overall combination of the pros and cons of these criteria.
EC Definition
Cost
The EC definition change involves creating an EC that corresponds to an individual part rather than creating an EC that corresponds to one problem. The greatest pro for the EC definition change is it causes less processing time per EC (Pikosz and Malmqvist 9). This is because it allows each part to be approved and released independent of each other. Furthermore, this means that EC will not slow the entire process down because the parts will all be processed alone. However, this depends on whether the approved part is dependent upon a part still waiting for approval. For instance, the installation of a fire hydrant EC is dependent on the EC for the holding bracket. So if the fire hydrant EC gets approved first it still has to wait upon the approval for the new holding bracket before it can get installed. This would cause a delay that would be the same time if the parts were included in the EC together. Since the majority of parts are dependent on one another (Appendix B), the processing time gained would be small.
Another pro is it will create shorter approval time per EC (Appendix B). The BAC engineers and CMO will have less paperwork to look through and understand, which will allow them to process the ECs quicker if there are no problems. The shortening of the individual processing and approval time will decrease the cost of the ECs because they are spending less time in the system. Moreover, they are requiring less man hours to review because there is less material than if they were multi-part ECs. Conversely, ECs being generated per part would create a massive amount of ECs within the system. This means that the CMO on both ends would have a significant amount of ECs to process and would have to find a way to rank them by importance. Both of these scenarios would slow down the EC processing time and wouldn’t make the cost worth it.
Implementation Time
This EC process change has a middle implementation time when compared to the other two solutions. It would have to be decided at a program level how to deal with the ECs currently in the system. Most likely ECs before a certain CMO review will be sent back to be changed to the new EC definition while those after CMO review will be approved by the old system. While those past CMO review will get processed rather quickly, the others will have a significant wait time in the system until they are changed into the new form. If instead they decide to keep all ECs currently in the system moving forward and only change the new ECs. They are just delaying the process for months while they wait for all the old ECs to move through the system. Furthermore, this might cause some overlap in the new ECs and old ECs which could cause some confusion for both CMO and CMT.
Workload
Although the ECs will be easier to review and approve individually, the sheer amount of ECs that will be generated if it is changed to one EC per part will create a tremendous amount of work for AD engineers. With the change, the engineers will be required to create a different EC for every part that is involved in a specific change. This means that they will have to fill in the same background information into the ECN reports for each EC. This leads to redundancies in the ECs and ends up being more work than it is worth for the engineers (Appendix B).
Standard Document
Cost
The main pro of the Standardized document change is the low initial cost of this solution. AD Engineering already sends BAC a EC summary report (ECN) with the data package. This solution requires AD CMO to have a meeting with BAC CMT to determine the format for the document that would make their approval easier. Then AD CMO would incorporate these changes into a mandatory format engineers have to follow when creating the ECN report. However, the long term savings of this change would be the increase in ease of BAC CMT and Engineer approval. The standardized document would facilitate the understanding of the change which would lead to faster approval time. The main contributing cost would be the increased time engineers are spending on creating the new ECN report and the time it takes for AD CMO to ensure that they followed the format correctly.
Implementation Time
This change possesses the shortest implementation time out of all the changes because AD Engineering already gives BAC a summary document. The only difference is that the document would have a new standardized format. It would take some time to figure out the most effective format with BAC CMT but after those meetings the implementation time would be over. The only possible hold up in this implementation time would be coordinating a meeting with BAC CMT and having them respond promptly with their desired format.
Workload
The workload would fall upon AD Engineers and AD CMO for this solution. While there might be some initial work on BAC CMT, the majority of the new workload will fall on AD Engineers and CMO. AD CMO will be responsible for creating the new format and ensuring that the engineers fill it out correctly during the CMO review step in the process. AD Engineers will be responsible for filling out the new document correctly to make sure that they follow the agreed upon format.
Integration Solution
Cost
The main pro for this solution is that has a low short term cost. The work for the respective groups would stay the same but would be conducted in a different order than previously. The short term cost would be caused by the need to train the AD engineers on the correct documents to send to BAC so there are no confidentiality issues (Appendix B). However, this short term cost would be offset by the savings generated by the quicker EC processing time. This solution would streamline and hasten the BAC approval process by easing the workload on both the AD and BAC CMT teams. This solution would force the two teams of engineers to confer earlier in the process and comprise early on the EC. This would also serve to decrease the amount of rejected ECs from BAC because that will be sorted out between the engineering teams earlier in the process. On the other hand, the increase in communication between BAC and AD engineers could cause an increase in EC recalls due to design differences (Appendix B). This possible increase in EC recall would result in a cost flux; however, it would be offset by the decrease in EC rejections.
Implementation Time
This solution would have the longest implementation time out of all of the ECs because every EC needs to be approved by BAC CMT and engineers. Therefore, every EC at and before the Customer Review step will have to be recalled to Design Review and wait there until the BAC engineers have approved the EC. This will cause a hold up in the EC process while BAC engineers conduct their review on the ECs currently at that level. However, this could be addressed by continuing the process normally for the ECs after Design Review, which means that BAC engineers would still approve at Customer Review. Then for any new ECs, AD engineers could send them the data package once it hits Design Review according to the new system. While this overlapping process could shorten implementation time, it could possible cause confusion on the BAC side.
Workload
The workload for this solution will fall upon AD and BAC engineers. AD and BAC engineers will be responsible for coordinating and sending each other documents until they agree upon the correct design for the EC. The majority of the review work will also fall on BAC engineers in this case versus the previous system where it fell on BAC CMT. Furthermore, both groups relied on their respective CMO’s to coordinate the review process but now they will be required to do it directly.
Proposed Solution
My final proposal for the the EC processing time problem is the integration solution. One of the integral reasons why is that the majority of engineers already collaborate with their counterpart at BAC, which would be the same individual responsible for the review of the EC. The biggest hindrance on the EC process is Customer Review and the rejection letters that force ECs to be sent all the way back to Design. This solution will decrease the amount of rejection letters from BAC because the BAC engineers will need to approve the design change in the EC before it ever gets to their CMO. Therefore, by the time the EC has reached BAC CMT for their final review all the engineering details will have been finalized and the paperwork will have been reviewed by three separate parties. While the other two solutions either had a smaller initial cost or short implementation time, they both had relatively smaller impacts on the EC process. Therefore, the other solution’s ability to address the problem of EC processing time was smaller. Conversely, the integration solution will have a larger impact on the EC process and will reduce cost in the future at a greater rate than the other two solutions.
Variations
There are multiple variations of this solution that can be implemented in order to address some of the concerns raised by Michelle Hauff. The first variation would be to not add BAC to the Matrix system. The Matrix system houses all of the engineering documents from every AD Engineering program, both past and present. This variation would negate that concern because BAC would not have access to the system. This means that the BAC engineering approval step would be treated the same way as the current Customer Review step. When AD engineers finalize the design, they will send a document package to BAC engineers. Once BAC engineers approve the package, they will send an approval letter which the AD engineers will attach to the EC in Matrix as documentation. This variation will make cooperation slightly more difficult for the engineers because they will have to email documents back and forth to one another until they settle on a design.
The other variation of this solution would be to add BAC to the Matrix system. This means that the document privacy issue would be present unless there is a way to limit BAC users’ readability rights. This should be possible but I am unsure on the limitations of the software. However, adding the BAC CMT and engineers to the Matrix system would greatly increase the ease of cooperation. This would allow the two engineering teams to share documents easier and quicker by uploading and downloading to Matrix. This would also streamline the approval process for both BAC engineers and CMT because they would have direct access to Matrix rather than having to email a formal letter.
Conclusion
The change approval process is an important part of every engineering company’s design process. The most integral part of that process is the Engineering Change process, which incorporates all the steps between design, approval and implementation. AD Engineering has developed a long processing time for its ECs, which has stemmed from the intensive Customer Review step. The Customer review steps involves BAC CMT and engineers reviewing the proposed design change and either approving or rejecting that change. This report has analyzed three solutions that addressed the EC processing time problem as well as the underlying causes.
The different solutions were EC Definition Change, Standardized document and Integration. The report concluded that the Integration solution was the most efficient and effective solution. This was determined by analyzing the cost, implementation time and workload impacts of each of the proposed solutions. This solution would split the Customer Review step into two parts: BAC Design Review and BAC CMT Review. This would create a better logistical flow between steps and help streamline the approval process. The integration solution had the greatest impact on the EC processing time when compared to the other solutions. While the other solutions were cheaper and quicker, they would not have provided enough impact on the EC processing time in the long run. Nonetheless, these proposed solutions are only suggestions and at the very least, I hope that they serve to help AD Engineering understand their EC processing time problem.
Works Consulted
Eckert, Claudia M., et al. “Supporting change processes in design: Complexity, prediction and reliability.” Reliability Engineering & System Safety 91.12 (2006): 1521-1534.
Huang, G. Q., W. Y. Yee, and K. L. Mak. “Current practice of engineering change management in Hong Kong manufacturing industries.” Journal of Materials Processing Technology 139.1 (2003): 481-487.
Jarratt, Timothy, Claudia Eckert, and P. John Clarkson. “Development of a product model to support engineering change management.” Proceedings of the TCME (2004): 331-344.
Kocar, Vildan, and Ali Akgunduz. “ADVICE: a virtual environment for engineering change management.” Computers in Industry 61.1 (2010): 15-28.
Koh, Edwin CY, Nicholas HM Caldwell, and P. John Clarkson. “A method to assess the effects of engineering change propagation.” Research in Engineering Design 23.4 (2012): 329-351.
Nadia, Bhuiyan, Gatard Gregory, and Thomson Vince. “Engineering change request management in a new product development process.” European Journal of Innovation Management 9.1 (2006): 5-19.
Quintana, Virgilio, et al. “Re-engineering the Engineering Change Management process for a drawing-less environment.” Computers in Industry 63.1 (2012): 79-90.
Pikosz, Peter, and Johan Malmqvist. “A comparative study of engineering change management in three Swedish engineering companies.” Proceedings of the DETC98 ASME design engineering technical conference. 1998.
Reddi, Krishna R., and Young B. Moon. “System dynamics modeling of engineering change management in a collaborative environment.” The International Journal of Advanced Manufacturing Technology 55.9-12 (2011): 1225-1239.
Rouibah, Kamel, and Kevin R. Caskey. “Change management in concurrent engineering from a parameter perspective.” Computers in Industry 50.1 (2003): 15-34.
Tavčar, Jože, and Jože Duhovnik. “Engineering change management in individual and mass production.” Robotics and Computer-Integrated Manufacturing 21.3 (2005): 205-215.
Whyte, Jennifer, Angelos Stasis, and Carmel Lindkvist. “Managing change in the delivery of complex projects: Configuration management, asset information and ‘big data’.” International Journal of Project Management 34.2 (2016): 339-351.
Wright, I. C. “A review of research into engineering change management: implications for product design.” Design Studies 18.1 (1997): 33-42.
