Are your processes proactive or reactive?

There are two ways to implement a process.

The traditional way is as a check to make sure people did everything right. This could be required documentation that is written after a project is finished, a separate QA department that runs tests after each release, or various certifications like UL, FCC, CE, etc. There are certainly times when things like this are necessary; however, writing documentation after the fact is never much fun, and dealing with failure reports from the QA department is not all that pleasant, and the FCC testing facility has been called "the house of pain." We'll call this the "reactive" process approach.

An alternative approach is the "proactive" process. Structure your documentation efforts as part of the development process -- as a way to help you think and as a vehicle for collaboration. QA can also be implemented proactively as automated tests that are run during development.

Proactive processes focus on well-designed tools that help the people doing the work get it right vs. tools that help managers who oversee the work. Proactive process tools are well-designed, fast, and a pleasure to use.

Think what could happen if UL focused on providing KiCad templates and DRC rule sets for various high-voltage design scenarios that would help engineers do their work instead of a bureaucratic morass that is very painful and expensive to work through. The first approach encourages innovation, whereas the current approach greatly hinders it.

Some reactive processes are necessary, but where is your focus? The more you can shift your processes from reactive to proactive, the better off you'll be. This is what Platform Thinking is all about -- building YOUR Proactive Platform.