Disruptive Tools Can Stall At Group Boundaries

Interesting web site demo at http://nextgenerationelectronicsdesign.com/ by the folks at Altium. Unlike any PCB demo I have ever seen and an interesting use of self-deprecating humor to talk about the challenges of linking FPGA, Board, and Mechanical design. Two time coded remarks

• at 2:25 “We did what any traditional EDA company would do, we denied and avoided the problem.”
• at 2:50 “After offering the same thing as everyone else for a while, we decided to grow some bollocks and actually solve this properly.”
• Followed by a sequence of 3D views of PCB design–not the traditional a birds eye view–that allow you to more easily judge height interaction issues.

Altium is an Australian company–you may know them as Protel–that does about US$50M in revenue. I caught this link on the Mentor communities site in the comments by “pcb_man” on a post by John Isaac “Collaboration Across the Product Development Process.”

Based on a number of efforts to foster collaboration between Mechanical and PCB design teams in the past, I suspect that there will be significant cultural issues to be worked out to enable real time MCAD/ECAD integration and it’s attendant quality and time to market benefits. Loosely coupled toolsets in both domains allow groups to work more autonomously, even if the schedule impact is negative. Anytime you see a new tool that can redraw decision making and political boundaries, the barriers to adoption have more to do with changes in perceived level of control than shortcomings in the actual solution.

I have developed a rule of thumb for introducing new systems: the difficulty is proportional to the cube of the number of “silos” or distinct team/administrative boundaries you had to cross to get to an initially viable solution. For example

• 0 boundaries crossed: only adjust the workflow within a singe team or work group, leaving external inputs and outputs unchanged (except that you hope they have fewer errors or lower latency or can handle more complexity).
• 1 boundary:  both sides have to want to change or one group has to be convinced to either supply a new input or accept a different output. This gets attempted unilaterally a lot in the form of
• “if you will only give us this new input our jobs will be easier” If the two groups don’t share a common reward structure there is always a sense of “What’s in it for me?”
• “You have to use our new form/system to make requests” You mean I can’t pick up the phone or send e-mail? Let’s see what kinds of crises get manufactured.
• “We can no longer give you this data or output, our new system doesn’t support it” Well then you may be spending a lot of time doing manual work-arounds until you get that fixed.
• 2 boundaries: 2³ = 8 times harder. There are several different ways that three groups can merge together. If you can turn this into two pairwise transactions it’s much easier. Only possible if all three unhappy and willing to change.
• 3 boundaries: 3³ = 27 times harder. I have only seen four groups come together in response to things like a corporate commitment to pass an ISO 9000 audit or satisfy SOX. Even then it’s much easier to focus on pairwise changes  in the context of an overall plan for evolution.