In this section we are going to talk about project management as it relates to electrical engineering. And, we are going to start by describing the flow of projects, specifically development projects, where a product is developed and brought to market. Development projects can be considered in phases.
Phases of Development Projects
- Architecture
- Investigation
- Development
- Manufacturing
In the architecture phase the product is roughly defined, and the electronics are sketched out at the block diagram level. Also, cost of the product is estimated along with effort and time to develop it, and the feature set is established.
The investigation phase is where certain aspects of the electronics are explored that are unknown to work or are particularly difficult or risky. The purpose of this phase is to make sure the electronics can be implemented and can work in terms of technology, cost and schedule.
Then comes the development phase where the design is implemented and tested thoroughly. And, finally the development cycle ends with the manufacturing phase where electrical engineering R&D supports the development of production manufacturing processes and hands the electronics over to operations. I will go into detail on each of these phases.
Documentation and Design Reviews
There are a couple overarching efforts that are key to a development project, which you must take seriously and do well. The first is good documentation, documentation that is accurate, detailed, organized, and accessible to anyone who may need it. Document not only the design, but the theory of operation and the thought process behind the design. Also, document simulations you perform and thorough test plans with results. So many EEs make signal integrity measurements and either do not record the scope screen shots, or store them in the scope. Put those into a document that is posted in a shared project space.
Good documentation is critical for several reasons. First, it allows you to hand the design off to someone else, if needed. Your documentation should be thorough enough that another EE can read through it and understand not only what the design is, but why it was done the way it was. Another reason is that creating the documentation forces you to thoroughly think through what you are doing. Instead of jumping into some testing, creating a test plan will help you think through test coverage, the purpose of the test, resources you will need, and dependencies you have on deliverables from other disciplines. Third, documentation is important, because it creates a record of decisions made. For example, if you document the features your design provides and its interfaces, and you share it with other disciplines and ask for review, then you reduce the chance that some other engineer will implementing around a feature that your design does not have. Imagine this conversation, “You formatted the firmware for 2K page size NAND flash?!? I changed to 4K page size last revision, and this was documented in the change list and reference specification, which you reviewed.” See, that sounds alot better than, “Oh, I changed to 4K page size last revision, didn’t I mention that in the project meeting 3 months ago?”
The last thing I will say about good documentation is that it is a leadership skill and can help move you up the career ladder. It gives you more visibility than someone who doesn’t do much documentation, and by doing documentation, you are establishing part of the plan of record and driving decisions.
Another important thing to do throughout a devlopment project is to host good design reviews. Design reviews get you valuable feedback, raise awareness of the project, align everyone’s thinking, and give people the opportunity to contribute their ideas. It also mitigates your culpability in case there is a major problem with the design: CYA (cover your ass).
For any type of design review, I highly recommend that you break the review down into multiple focussed meetings. I have seen over and over in my career large design review meetings that try to cover everything from licensing issues for a software driver to the type of screws used to attach a heatsink, and the problem with that is people lose interest and their attention drifts away, so when something comes up that they could provide useful infomation about, they miss it. Perhaps have a separate meeting just with the firmware team and talk just about the aspects of the design they care about, and then meet separately with manufacturing and supply chain to talk about how these electronics will be produced and tested. Cover all the key people and key topics, but do it in small focussed meetings.
Design reviews should be held throughout the development project and for more than just the design. If you are developing a PCA, for example, don’t just host a design review for the schematics and think that is good enough. Host a design review for the architecture, a review for the schematics, a review for the layout, and for each new revision unless it is extremely minor. Also, host design reviews for major test plans that you created or for extensive simulations you performed.
Next: Architecture Phase