What's a professional way of tracking design history in plant engineering?

Question

If you look at the design documentation in our projects (Biogas and waste-to-energy plants), you find out what we plan to build but not what other options were considered and why they were discarded. This information rests only in the engineers head. Occasionally, a plant will be in a conceptual stage for years, sometimes switching between engineers. So I find myself revisiting an option that a coworker considered and ultimataly discarded last year.

What is a good way to track design decisions, the 'whys' and 'why-nots'? I'd strongly prefer an approach that's tried, tested and used elsewhere in industry.

Additional information: My company will be pursuing ISO 9001 certification, an approach that fits with this QA regime would be prefered.

Answer 1

I think this depends on how much information you want, and how formally you want to track it. It sounds like currently, none of this information is written down anywhere, which is obviously the first problem. But putting down information for a solution that you don't intend to pursue is, at best, a less-than-optimal use of time. You'll have to define which ideas are fleshed out enough to be recorded. If you have a meeting and a dozen ideas are put on the table, but half are almost immediately discarded, do you want to make notes of what those ideas were, and why they were discarded? That's a lot of effort for what was probably a very low-level analysis, but they're still design decisions.

It seems more intuitive to me to only do this for ideas which reach the stage of having some actual work done on them. This way, you've already got something tangible, and this just has to be filed away in a project file, which I'd hope is something you already have. Because this system really will only be generating reference materials for future projects, I don't think it would be a good idea to create a whole new system for archiving these materials, or overhauling an existing system. Find a way to integrate it into your current design management system.

The one key I would make sure you have is a way of classifying your different designs by their key parameters. I don't know much about your field, but I'd assume there are certain design parameters that each project has to meet (physical size, capacity, type of plant, etc.). Make sure these are easily visible somewhere, so that when starting a new project, you can identify old projects that are similar in various regards. If you have these discarded ideas stored in those folders, you'll be able to analyze their utility to your current project.

However, I also want to warn in general about going too deep into this. Again, I work in a different industry, where projects are much shorter, and as such, there are many more of them, but some products have been in existence in some form for decades, and there are 15-20 revisions of them. Maintaining a revision history for actual design changes that were implemented is very important. Knowing what the customer was given in the past, when changes were made, and why they were made is key to not repeating past mistakes and correctly servicing old designs. But when you catalog designs that never were fully realized, you're adding non-essential data on top of essential data, and there's only so much you can sort through before things start to get lost. It sounds like you're looking for a replacement for solid communication and good experience. When these projects change hands, the engineers involved have to communicate all the relevant information. I understand wanting to make sure you know what has been considered, but I'd advise you to temper that desire so as not to flood your records with unnecessary data.

Answer 2

This answer from Trevor gives a pretty good over all philosophy, but I want to get more at the details.

First, figure out why the alternate records are not being kept. This likely started out as either a foresight issue or a storage (paper or computer) issue.

At one time in the past, someone thought that the alternates would not be useful, so they were thrown out or deleted. This is likely a company culture problem. Now that this has been identified as an issue, it can be raised company-wide. Keeping records that have already been created is easy.

Even if the original engineers thought that the alternatives might be useful, they might have not kept the documents because of the cost of storage (physical or computer). If this is still the case, this problem needs to be resolved now. If this is no longer the case, the word needs to be spread throughout the company that keeping records is not a costly proposition.

Second, look at the alternative comparison method. There are two categories of alternative consideration: thought and calculation.

The thought comparisons are ideas that discarded quick enough that they never make it to paper in anything other than concept form. If these ideas were discarded so quickly the first time, then they probably don't need to be recorded. The effort to discredit them is so trivial that they will just be discredited again.

The alternatives that actually made it to the calculation stage should be kept in some form. If calculations or plans were done the first time, then there is already something to save. Even if the idea proves to be a dead-end, the work has already been done, so put it in the file! As long as it is dated, it can be referenced.

Write a memo (to the file if not to someone in particular) when a decision is made. This saves time in the future, but it adds a step to the process. This is something to work on along with improved documenting in general.

Last, date everything! Try to work with the systems that are already in place to keep the final records, just add a date to everything. Even if other methods of organization fail, the order of alternatives can be rebuilt using the dates on the items.

Answer 3

Following are three general methods how white goods, consumer goods and OEM manufactures I have associated with document ideas.

Front End (Conceptualization) idea documentation
Create project numbers for ideas considered big, impact full, and ground breaking but not currently considered for implementation. Document these ideas in most cases on a one or two page document and before shelving the project. With the growth in search engine technology and software these ideas can be stored in a searchable database. With a transitional nature of the current work force I found this a good way the document the idea. With the growth in technology and implementation method the detail documentation of technology is less relevant because in $t+1$, it is high likely that better and improve technology will be available.

Design reviews (NPD - New Product Development)
Design reviews another good process that can help document engineering design decisions. This tends to be more technical documentation, ideas that are rejected tend not to be well documented. In most organizations design reviews are part of phase gate model.

Back end (In or close production) idea documentation
I found organizations using an existing change management system to document new ideas. In this system the engineer propose the idea in a simple one or page document. The idea is reviewed and accepted or shelved for future. This particular organization used the SAP for change management, thus system as less apt to technology base searching but did sever well for them.

In summary, most ideas are shelved for the following reason

• Lack of financial resources to execute the idea/suggestion
• Lack of human resources to execute the idea/suggestion
• Doesn't fit into the current project plan
• The market is not yet ready to embrace new technology

Therefore it good the track ideas, because when above barriers are resolved the ideas become realistic solutions.

References:

• Change management
• Design review
• Phase–gate model

Answer 4

Others have made a lot of good comments about documentation in general, but I want to suggest a particular class of software that will help tremendously.

I find version control software to be excellent for these sorts of issues. It's not too common outside of software development, unfortunately, but it's only a matter of time before it catches on in other fields.

Here's an example: My research group has a Subversion repository that most people use (A popular alternative software is git). Using version control helps ensure continuity of the research projects after someone leaves, because most of the files relevant to a project are there, along with a detailed log of what work they did at what time, and (if they do it right), their rationale. I'll elaborate.

Let's say you have a folder on your computer that contains all of the files

Everything is automatically dated when it's committed (the version control term for what others might call "uploading"). The commit message acts as a short memo (as Mahendra Gunawardena suggested, you might want longer and more official memos for bigger decisions). You describe the change to the project files, say "We decided that approach X is not feasible. We are going to try Y instead. Deleted the files associated with approach X and created a new CAD model for approach Y."

Then, later, if you decide that approach X is actually the right thing and you want to dig up the deleted files, it's not hard. You can roll back any part to older version with ease and continue from there.

There are some additional benefits to this approach. First, it makes sharing files with others pretty easy. They just check out the repository (a version control term which could either mean the current version, or all versions) and then regularly update it (there are commands to do that). Basically, everyone is synchronized. Second, you can get a backup (older versions) for basically free. With that being said, this doesn't mean you don't need to keep normal backups, just that you have another option for restoring accidentally lost files. I highly recommend backing up the entire repository as well.