The Goal of Project
Management
(one man's perspective)
The goal of managing a project is to make sure products are designed, tested, and manufactured in a reliable manner as quickly as possible. In order to do this the product's requirements must be completely understood early in the project. Agency approval requirements, EMC and validation testing plans, and production testing methods should be taken into account in the design phase. And every effort should be made to reduce confusion, reverse engineering, and duplicate efforts by those working on different parts of the project. Otherwise delays in the the project are inevitable.
A project usually starts with requirements specified by the customer. Sometimes this is called a CTR (Customer Technical Requirements). It specifies the requirements for hardware and software in order to interface with the servos and sensors being used. The CTR generates a preliminary hardware design, and this generates a Worst Case Analysis (WCA), which may reveal the need for circuit changes. Then a DFMEA is performed (Design Failure Mode and Effects Analysis). And then a Validation Test Plan is written up and performed. The customer is usually involved in each step of the way, being informed of the progress and results.
Usually companies specialize in certain kinds of products that they are accustomed to designing. Engineers are not comfortable creating new designs completely from scratch for new products with which they don't have much experience. They would rather use a Continuing Engineering Effort, where they make new designs by modifying and improving old designs. The more cut-n-paste they can use from old designs, the quicker the development of the product. In fact, many times the cost quoted for a project depends on how much of it can be cut-n-pasted from previous projects. For the previous circuits and designs have already passed extensive testing, and that's usually the longest and most expensive part of a project.
Designs may vary somewhat from project to project. But to facilitate the ease of development, it would be best to have standardized documentation that can be cut-n-paste and easily modified for your next project. This might be done, for example, with WCAs, DFMEAs, EMCs, Validation and end-of-line Function Tester procedures. If these procedures can be separated according to functionality and type of interface, and labeled and filed in an obvious directory, they can be called up at any time as needed. This is already done for UL testing and the EMC test procedures. I think it can also be done for WCAs, DFMEAs, and validation test procedures. Some engineers think that the interfaces for each project are so unique that no standardized test procedure is possible. But I think it is possible to categorize them according to functionality, and design the procedures so that they can easily be modified.
The interfaces to a control boards consists of inputs and outputs. Inputs measure either a digital level, an analog level, or the frequency. Outputs supply either a digital level, or a PWM, or a voltage or current source. Many outputs provide fault detection of short or open circuit. And some of these interfaces have accuracy and resolution requirements. The differences in interfaces are just voltage, current, frequency, accuracy, and resolution requirements. These are parameters that can be listed at the top of a validation test procedures and then referenced in the rest of the document. But the electronic equipment used to measure the parameters can measure many orders of magnitude; so the basic test set-up could be the same for most of the testing. The same thing might be done for the WCAs since the circuits are vary similar.
The point is that then we have the ability to pass parameters back and forth between analysis and testing procedures and whatever Requirement Management software is being used. This makes it easier to choose from a list the tests that are needed since the procedures basically already exist. And it makes the requirements to do the testing obvious from the start because the requirements are listed at the top of the tests you choose. If the parameters for testing are not in the CTR, the customer will have plenty of time to get you this information before testing begins. You may need to ask for what kind of loads to be used in a test, what frequencies and duty-cycles to test. You don't want to wait until you actually get to the testing bench before you realize you don't have enough information to begin testing.
Also, if the test procedures have been standardized into a list of easy instructions, then engineers no longer need to do the actual testing. With the right modifications a technician could set up the equipment and report results.
Another document that would help development is a Theory of Operation. It describes how the circuit operates and how the signals flows in order to sense the inputs and drive the outputs. Of course, if you are the only one working on the project, you already know how it works. But if you have others working on WCAs, DFMEAs, and validation testing, then it might be a good idea to write up a Theory of Operations. That way if the design engineer is not available to answer questions, work can continue. Most of the time the circuits are easy enough to understand. But it can be frustrating to have to try and reverse engineer a circuit in order to do your job because you feel like you might be guessing. A Theory of Operation is especially appreciated during testing when you have to possibly diagnose and trouble shoot a circuit.
And a Theory of Operation does not need to include too much information. There need not be any design equations nor even any circuit values for resistors and capacitor. But it does need to identify components by reference designator and the expected voltage levels as it performs various functions. And if there are many similar circuits on the control, just one of them needs to be explained. The audience for a Theory of Operation would be a technician who might need to trouble shoot down to the component level. This might also help when performing WCA and DFMEA.
Many manufactures implement a "just in time" philosophy where they carry just enough inventory to get the required volume of product to the customer at the rate agreed upon. If the production line goes down for any reason, that is not the time to reverse engineer the product in order to do diagnostics. One needs to determine quickly whether the problem is with out-of-spec components on the product or whether it is the end-of-line Function Tester. This is where a Theory of Operation would me most useful. Also required are pictures that label nodes on the board for corresponding nodes on the schematic. This makes it easy to follow the signal to the bad component. And the root cause of the problem will have to be determined, whether it is a component that is out-of-spec or something else is driving that component beyond its specifications.
To quickly determine if the end-of-line Function Tester is working, you might want to create special "calibration boards" that are known to be good and bad. Just because most boards are passing the Function Tester does not necessarily mean that they are good. And just because they fail the Function Tester doesn't necessarily mean that they are bad. The Function Tester itself needs to be checked occasionally with known good and bad units. This quickly eliminated the Function Tester as the problem in an emergency, when the line goes down. More about Function Testers here. These calibration boards can also be used to validate the Function Tester to begin with. And they can be used to periodically calibrate the Function Tester without having to take the Function Tester off-line; just use the boards that were calibrated.
When hardware and software and production engineers are working separately in dispersed regions, they may end up initializing and programming the control board for their own purposes. This may be a duplication of efforts that could be avoided. And it doesn't guarantee that software will be specifically designed to enable EMC, validation, or diagnostic tests. A special effort is needed to coordinate the work of software engineers across various departments. Perhaps all of them could work on initialization and basic input/output routines at the same time. Code with more fault tolerancing can always replace this preliminary code as needed. And then layers of code can be added to that for their specific purposes.
All that's needed to do validation testing and production diagnostics is the ability to operate the basic functions of each of the interfaces. In fact, the same tests designed for validation can be used in production diagnostics. This is another reason to standardize the validation tests. However, the software team will need to know early on what functionality is required for testing. This is yet another reason to standardize test procedures, so that the functionality required is visible at the beginning of the project.
Sometimes software engineers will cut-n-paste code for various interfaces, or write code based on theory alone without actually trying it on the hardware. But there is no guarantee that it will function accurately. As part of initialization, software engineers should actually exercise inputs and measure outputs with calibrated test equipment and try it at a few different values. This allows them to put in code the correct scale factors for accurate operations. Otherwise, the test engineers will discover that the code really isn't ready for testing, and the project will be delayed until the software is updated.
I've noticed sometimes that young Lead Engineers can be stuck in "brain storming" mode. Their minds are always searching for answers to problems that come up. They are pretty good at finding specs in the CTR or knowing who to talk to in order to find answers. But they may not have time to generalize problems or see solutions on a systemic level. They only have time to take care of issues one at a time as they come up. If engineers under them need their help, this is just another problem that they need to fix, and communications can suffer. They may forget to give clear instructions or share techniques because they are too focused on solving the problems of that day.
However, a mature Lead Engineer will try to get ahead of common errors and misconceptions that may be starting to confuse engineers. The Lead Engineer will find answers and email or call a meeting to inform the engineers with clear instructions so that all of them can easily follow it. The Lead Engineer will take the responsibility to give new engineers an adequate orientation of purpose and procedures to get them started and keep them motivated. I hope this article helps in that regard.