The # 4 mistake is…Not Understanding the Purpose of Traceability.
DO-254 is a requirements-based process. As part of this process, requirements must be captured and validated, and then traced (via a Traceability Matrix) into both the corresponding design implementation and verification (test cases, test procedures and results). Traceability is an integral (i.e., Supporting) process verification activity. What traceability provides, if done properly, is assurance that all requirements have been implemented, that all portions of the design tie to requirements, and that the design as implemented behaves as the requirements say it should. Traceability done throughout the development activity will identify derived requirements that need validation. But all of this entails integrating traceability into the process as you go. By integrating traceability, it offers insights into design completion and verification coverage, and can even help find design bugs!
Instead what I often see is project teams who think of the Traceability Matrix is an artifact to be generated after the fact, with no thought about it until it needs to be reviewed during SOI audits. If you wait until the last minute to create a traceability matrix, as opposed to incorporating traceability into each phase of design (used as a analysis tool as part of requirements, design, code and test reviews), you miss the point and the benefits that this activity provides. So in your program, try to remember that Requirements Traceability isn’t an output of the program as much as it is a tool to be used throughout the program to help you understand your progress and provide an added measure of verification and visibility for change impact for each phase of the process.
If you need help understanding how to best implement traceability in your DO-254 program, this is covered in the Patmos Engineering Services “DO-254 Airborne Electronic Hardware Certification” training.