Delaying Circuit Board Spin Till Last Responsible Moment
Added to TechnologyProblem
We were building a mobile spectrometer instrument as a greenfield project.
We needed to investigate microprocessors from several vendors, and support development of new light sensor hardware that another department of our company designed. There were far too many variables and unknowns for us to get to a final circuit board design in one go – but multiple board spins would be very expensive. To drive down the unknowns we needed to get field units out to early customers, taking real-world data readings. Circular problem!
Action
We took these steps:
- Ordered evaluation boards from 3 different vendors of the microprocessor we were interested in
- Created a 2nd board we could build in our lab to interface the eval board to sensors and displays
- Built a couple dozen early field units and sent them out
- Made several revs of our 2nd board, and received revs of the eval boards
- Hand-built field units were upgraded a few times, containing the 2 boards
Result
After about 7 months, we were ready to have a single, final circuit board fabricated to do the job of the 2 boards (the vendor’s eval board plus our hand-built sensor board). As things turned out, we needed one more spin after that one but this was definitely a better pathway than attempting to have a single-board design before producing the field units. Benefits of this approach:
- We selected the microprocessor vendor after experiencing their services
- We avoided several additional board spins
- Every aspect of our product design moved faster due to getting the field units built and deployed quickly
- Upgrades of the 2-board design were inexpensive and substantially in our control
Name: Nancy Van Schooenderwoert Company: Lean-Agile Partners, Inc. website/blog: http://www.leanagilepartners.com/lean-agile-partners-blog.html twitter handle: @vanschoo contact info Email: nancyv at leanagilepartners dot com
About the Author
This is an Agile Alliance community blog post. Opinions represented are personal and belong solely to the author. They do not represent opinion or policy of Agile Alliance.
