Lets Work Together

Speak with us

9th November 2020

Fletcher’s Law

Fletcher’s Law

Fletcher’s Law of early prototype quantities is a phenomenon first documented in August 2018, following two decades of observations in product development.

Fletcher’s Law simply states that the quality and functionality of ‘A’ model prototypes is inversely proportional to the number of ‘A’ model prototypes produced!

Let me explain…..

Some of you will already have witnessed the phenomenon and so this might raise a smile.  Others will be just about to order a large quantity of first spin prototype PCBs and this might save you putting the majority of them in the bin.

Unless a design is very simple and re-uses or tweaks existing, well tested products you will need at least a second spin of the printed circuit board.  First, or ‘A’ model prototypes are used for test and verification.  These give the software team a platform to work on that is much more representative of the final product than any development kits used at the start of the project. The initial, careful, bring-up of the board usually discovers an issue where the product doesn’t quite work as expected.  There is a huge array of potential issues that can arise. An IC (integrated circuit) behaviour isn’t quite the same as the datasheet in a key area, the enclosure design changed at the last minute so the board doesn’t fit, a power supply is too noisy, a connector is in the wrong place or there is a problem with the pin-out and more.

Ideally product development plans recognise this early risk and builds in time, for R&D activities to build and test prototypes and spin a second, far more finalised design. These prototypes shouldn’t be intended for a customer demonstration, shown at an exhibition, being sold to a customer or demonstrated to raise finance.

We regularly come across situations where the project launch has a fixed end date probably set with an assumption of a timely start. The start date of the plan might even have whizzed past long before any resource was available to work on the project. The time compression can often result in the very early design prototypes having to be used for beta testing, field trials or demonstrations. Realistically, these should be destined for a tame lab environment.

Recover the late starting project

To try to recover the already late project, or to avoid highlighting that the project should really have been started months ago, the dates for beta testing trials aren’t moved. There are high expectations of hitting the test dates for a small army of beta testers all scheduled to go. That means many more prototypes are needed than the initial handful.

Instead of the handful initial prototypes needed to debug the ‘A model’ boards and quickly spin a ‘B model,’ a hundred or more prototypes are made to fast track the project and recover some of the plan.

If the level of design risk is low this may be a good move.  Where there is a trial or demo however it is probably because the product is pushing at least one area of technology or performance forward. The project has started late or is under-resourced or possibly both. This often means that the product development team have been put under pressure to rush the design through to meet prototyping and production deadlines and may be cutting corners and glossing over design reviews and data releases. We have the start of a perfect storm.

Shortcuts

The initial design, that has been rushed and perhaps had design reviews missed, datasheets skim read, specifications not reviewed, and breadboarding or simulations avoided is now being made in quantities for a test team to work on. The probability of this design working first time without modification is slim.

Though a combination of late nights, weekends and plenty of coffee, the design team meets the prototype date. The time spent waiting for prototypes to be delivered was spent fruitfully, the team planned out hardware bring up and ensured all cables, drivers and test kit were available ready.

The first 100 prototypes are produced. The team briefly inspects a few of the batch of boards to check they have been manufactured correctly, all components appear to be correct and properly soldered. The first board is tentatively powered up from a benchtop power supply with the current limit turned down and the power supplies work at least.

Hardware problems

After a few hours of test, there is a list of functional problems that need to be diagnosed. A few hours or days later the issues are understood and resolved so that the first board is working. Modifications to fix the issues are worked out and documented. The mods need component values swapping, tracks cutting and wires adding. These are applied to a second board to confirm, which take a little over an hour to complete. Subsequent boards will be a little quicker to update and so we have a modification time of around 1 hour per unit.

There are now two working boards and ninety-eight board in their original and unmodified state. Ninety boards are needed for the test team and must be available within a week. Simple maths tells us that there are eighty-eight unplanned modification hours needed which takes two engineers a full week to complete.

The two engineer-week modification work wasn’t in the plan. The week was supposed to be used for further testing and updates of the early prototype before a second larger batch of units was made.  The product is now two weeks of test down.

Similarly to the first prototype date, this larger second batch of units can’t slip either. They are needed for early users to generate product interest and iron out the last few issues. There has been much less testing completed, some areas of the design are completely untested – but we need to spin the next board anyway.

Sound familiar?

Projects that need a large number of early prototypes (more than 10 or 20 at a push) which are intended for anything other than bring up and test by the design engineers are more likely to encounter problems and have more PCB respins. We’ve seen simple boards that have been re-worked 5 or more times! Those which have a controlled engineering process with prototypes thoroughly tested using an appropriate amount of engineering time, instead of burning time modifying a volume of early units, are likely to experience earlier success and less ongoing problems.

Somewhere between four and ten prototype PCB’s is often the right number of first prototype PCBs. The team have enough units to bring-up and test with activity focussed on checking all of the design functions correctly and getting the most test coverage possible before the second model. They are not burdened with modifying large numbers of units and although many of the prototypes will ultimately end up in the WEEE bin, the overall cost of the first prototype run is kept low and the impact they have on the success of the rest of the project is high.

Authorship: This article was written by Ignys MD Richard Fletcher. See more about the Ignys Team here.

If you liked this you may also like

Failing to test – Read why testing your product is a great idea.

Are you looking at prototypes for your own product?

MVP from Ignys

We can help you progress your product development with a Minimum Viable Product.