Keeping Engineering & Operations in Sync

Whenever there are two or more working copies of the same file or document, there is an increased potential for change edits where one or more of the documents no longer reflect the latest version of the part or assembly of record. If there is no centralized Documentation Control operation, then it is difficult to tell who has the “correct” version and who is working from a copy that is out-of-date.

Imagine that Engineering has changed a drawing, but Purchasing has the unmodified version of the same drawing filed by part number in its files and has attached that version to a purchase order that had been sent to a fabrication house to make 500 parts at a considerable cost. The parts are ordered, received, and sent to the factory floor. The assembly line stops, because a fastener location has been moved slightly to make it possible for the part to be used in other assemblies, but not the assemblies scheduled for completion today.

Had the latest document, edited by Engineering, been given to Purchasing, the part ordered would have been fabricated with both old and new assemblies in mind. What happened? Here are three possible answers:

  1. Design intent . Engineering recognized the need to reduce cost in its design by modifying the old design to work with all assemblies. This would reduce inventory part count and lower costs by consolidating purchasing volume requirements across many assemblies and simplifying the assembly effort. This is the practice of “Design Intent” in action.
  2. Not enough information . Purchasing was maintaining its own files and did not know of any changes to the part or drawing at the design level. Purchasing believed it had the latest technical drawing and could order as the MRP Forecast had required.
  3. Lack of documentation . Engineering may have informed Purchasing verbally of the pending changes, but that isn't the real problem. The company had no real documentation control process or procedure. In fact, Purchasing may have been told that a change was coming and to hold off purchasing any new parts until the drawings were released, but the person who was told was not the person who purchased the parts.

Word of mouth is never sufficient for documentation or part change issues. In the next part of this series, I will review certain critical steps that could have been taken to avoid this problem. The terminologies to keep in mind here include the following: Revision Control, Documentation Control, ECR/ECO/ECN Procedures, and the CRB or Change Review Board. Don't worry. I'll explain further, but let me know what could have been done differently in the above scenario.

21 comments on “Keeping Engineering & Operations in Sync

  1. AnalyzeThis
    October 7, 2011

    Back in the day, prior to easy-to-use version/revision/document control systems, this was a GIGANTIC problem.

    Now things are much better, but even if you have a solid documentation control system, problems can still occur. As you say, “word of mouth is never sufficient for documentation or part change issues.”

    Documentation control isn't really a technical problem (unless, say, engineering and purchasing are on different platforms), it's more of a process/management/communication issue: if people don't use the system, or use the system poorly… there's not much you can do from an IT standpoint.

    Anyhow, I've mostly only dealt with this issue from a technical standpoint, so I'll look forward to the next part of the series!

  2. dalexander
    October 7, 2011

    Dennis, If you would like the full paper just give me your contact information and I will send it to you or visit


  3. DataCrunch
    October 7, 2011

    I agree with DennisQ on this one, but it does underscore an issue that is more common than we may realize which is companies are still using antiquated and in many cases inadequate methods for file sharing and communications. 

    Douglas, would you say that companies properly utilizing version/revision/document control systems, as DennisQ mentioned are more   the exception rather than the norm?


  4. dalexander
    October 7, 2011

    Dave, I can't work in a disorganized organization that isn't moving towards best practices in all departments. Hence, I am highly motivated to introduce procedures, flowcharts,forms and guidelines as quickly as I can. So to answer your question, I have worked in environments that had already recognized the need for greater controls and so I was compelled from within and without to put the processes that were within my scope of work in place as quickly as possible.Every company I have experienced either as an employee or a consultant have had mild to severe organizational issues, so in brief I would say there probably are more that need a better defined infrastructure with defined, but still flexible job descriptions than not. This first section of the paper posted herein, is just the first secion of a longer document that EBN has chosen to split up to present. I tell of a few disasters because of the poor communications and interdepartmental snafus that resulted from “everyone doin' their own thing”. I am a Component Engineer and by definition have to be so detailed and research oriented, that my own discipline would be in shambles if I did not keep fastideous records and follow processes to get from A-Z efficiently. That is a lot of commentary on a subject that defines chaos from order. I appreciate your question. My entire website is dedicated to structuring a Component Engineering department…from the ground up.

  5. mfbertozzi
    October 8, 2011

    Good article and good summary Douglas, I would like to put on the table a question: is there a specific reason to leave off sales and marketing in sync process? I believe they are fundamental blocks in the puzzle “keeing sync” and maybe sometimes a few mistakes come just from there. Isn't it?

  6. dalexander
    October 8, 2011

    Mfbertozzi, I think you have hit upon one of the key communication issues within a company, that being who is in the loop whenever there is an introduction, discontinuance, modification, or consolidation of a policy, procedure, process etc. It is rather interesting that companies live and die by whether their product sales are sufficient to support the entire operation. And sales “reach” is definitely effectuated by Marketing and Communications. A change deep inside the bowels of a company that has any impact on form, fit, or function of a customers experience, without the Marketing and Sales force in the “know”, could have a huge negative consequence on the morale, credibility, and ultimately sales revenue. So, in the paper ECN, Change Order Control, I definitely include in the routing sequence, Marketing and Sales…anyone impacted by the change. In the next section of this paper on Documentation Control, you will see nuances of that. Your point is well- taken and I suspect you have been a victim of this very omission in “Best Practices”.

  7. mfbertozzi
    October 8, 2011

    Good to hear your point of view Douglas, it is very clear. You are right, as large enterprise veteran, I've really experienced sometimes how is important to fill the gap among marketing/sales/engineering/operations and I believe is one of key talent an executive can bring inside corporation which he is in charge of leading, in collaboration with whole management team. I am convinced your next paper will be very interesting, as current, is.

  8. dalexander
    October 8, 2011

    To all… Let me throw this out there and see if we have a consensus of opinion. At what point in a technical company's development should formal processes be put in place? Too early and you run the risk of stifling development by slowing down early development efforts by taking hands away from product R&D to handle paperwork, and too late, people start tripping over each other because jobs are I'll defined and repeatability in product quality suffers because there is too much tribal knowledge and new hires have to catch up by violating poorly or nondocumented process and procedures. This amounts to a waste of time, money, and more often than not, occasions many reworks in development efforts. So, when is the best time to hire Engineering Support Services in a company's growth cycle?

  9. Clairvoyant
    October 8, 2011

    Good point, Douglas. I think for a new company, they should start implementing these types of procedures gradually and when it becomes a benefit to do so. That way the company does not get behind on implementing these procedures and also does not take too much effort away from working on the real products.

  10. dalexander
    October 8, 2011

    So Clairvoyant and anyone else. What order would you put the following positions in place?: Document Control Specialist -Electronics Technician-Component Engineer – Program Manager – Reliability Engineer – Engineering Stockroom supervisor. I know there are many talented and experienced people who can do more than one of these positions, so let's limit this exercise to full-time positions for each one. I would like to see the different responses as differentiated among Executive Management, Middle Management, Individual Contributor staff. Perception among these different groups is often an issue that impacts company growth in more than just the physical infrastructure. 

  11. elctrnx_lyf
    October 9, 2011

    for any organization that has many departments working together to deliver a single product requires a right coordination. That's timw when you actually need right document controls to take care of the flow of information through all these departments.

  12. mfbertozzi
    October 9, 2011

    I agree with elctrnx_lyf, processes are right output of a good internal organization, based in principle on collaboration among teams involved in activities. Coming back to the question ” right time for support services “, in my opinion, either you are conceving products or services, support services are a part of the project and as per other physical components, they need to be embedded as whole part of the project, since the beginning.

  13. saranyatil
    October 9, 2011

    As mentioned, establishing the process is quiet important and also the support team to be in close network and work should go hand in hand. with lot of care taken both sides definitely there will be a sync established.


  14. itguyphil
    October 9, 2011

    True, most businsses that fail do so primarily because of missteps in proper scaling. Too early or too late. This goes hand in hand with the planning and milestones. 

  15. dalexander
    October 10, 2011

    Looking at a start-up, we find a highly talented beginning staff that usually have worked together in a former company, have decided to split and create their own fortunes, and who really know and appreciate each other's ability and can almost read each other's mind. Hence, this beginning crew trust each other implicitly and everyone knows the roadmap because everyone made a critical contribution to it. So we have the CEO, a CTO, a highly skilled Design Engineer, maybe a super tech, and someone well versed in Engineering support logistics. Purchasing, Part Mastering, BOM configuration, and maybe an inexpensive MRP system. This team are the ACE performers and together they can do everything to get that first proof of concept product in front of some venture people. Let's assume the venture people are so impressed, they toss in 3 million. Who or what position would you hire now that you have funds for headcount and the ball is ready to roll? You can hire up to five people and pay them up to 100k/yr salary. Ready, Get set, Hire! Who did you just hire?

  16. Daniel
    October 10, 2011

    Douglas, documentation is a vital part in any sort of development activities. That’s the one reason ISO and CMMI have given much important for the documentation purposes. I think now a day’s most of the companies are using version control software’s to track all the changes made in documentation. More over, any change in such pages can reflect to other versions of same copy also.

  17. William K.
    October 11, 2011

    I have seen just exactly such an error made, which in that instance was the result of haste and not waiting until a design was released to start cutting metal. The solution in more than one of my jobs was for an engineer making a change to physically replace all of the previous versions, and write “OLD” on the version as it was superceded. The OLD part was a compromise to allow use of marked up versions of drawings and BOMs.

    Of course, the big question comes up about starting to “cut metal” before the engineering is completed. Running production changes must always be carefully choreographed or disasters of some level are certain to occurr. In the example given, a change for the mating part should have been released at the same time as the change for the original part. It is possible to have running production changes, but they do need extra work to be successful. IN the same example, another option would have been the release of a third version that would work with both designs of the main part. I have done that once, and it did work out very well.

  18. dalexander
    October 11, 2011

    William, you have to wonder why Documentation Control isn't one of the first hiring areas for Engineering Support. Many evils are avoided by a really well run Document department because they usually take ownership for ECO/ECNs,fabs, drawings, and artwork. The problem becomes really evident when critical people are left out of the loop because there are no formal sign-offs or routing channels for changes. I asked in an earlier reply for people to put hiring positions in chronological order when considering a start-up company's headcount planning. I find it interesting that nobody took a crack at that. I was also hoping that a CEO or a CTO would respond from an executive management perspective. I thought the responses would start flying in. To be honest, many of the people who are out of work, are from these key support areas, but top management did not consider the real cost of losing these positions.That subject is a blog of its own.

  19. arenasolutions
    October 11, 2011

    The systems and all that are great, and anything you can implement that automates communication and change between departments will help you, but for companies who build a product, clarity of communication starts with the BOM. Making sure your BOM is complete is the first step toward making sure all teams have a clear picture of what the product is, how it will be built and what it will cost.

    People often think they are writing everything down in the BOM that should be there, but this is where taking an inter-departmental approach comes into play. The core mechanical and electrical parts are usually recorded (because that's what engineering cares about) but what about the random and non-modeled parts like glue, software, cables, and patch cords? If you have these types of elements in your product, make sure they’re in the BOM!

    In addition, it’s important that the documentation, warranty cards, offers from business partners, and packaging are accounted for, because these pieces, while they may not directly be part of the product, affect the working of your product as well as your customer’s experience.

    I wrote more on this recently, as I have been thinking about BOMs and making sure collaboration between teams happens. Check it out.


  20. dalexander
    October 11, 2011

    Good point Arena. I have used BOM.Com, now Arena and believe it to be a pretty good solution for the Engineering environment. I read your blog and heartily agree about an all inclusive BOM. As you know, there are direct materials and indirect materials. We used to assign Glip a PN with a UOM of one drop. Our EOQ was “bottle, 6 Oz”. It was a direct material. However, we had other things like q-tips and Kleen wipes as indirect materials. We had these last two in free stock with Min/Max inventory control at the work station…not the stockroom. Would anyone consider these as COG inclusive or would you classify them as misc. Supplies and write them off as expenses?

  21. itguyphil
    October 12, 2011


    I would hire the best business developer I could find. Etiher through previous relationships or from channel relationships that the other team members have forged. Try to get the word out ASAP and to the target market and other investors.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.