search.noResults

search.searching

dataCollection.invalidEmail
note.createNoteMessage

search.noResults

search.searching

orderForm.title

orderForm.productCode
orderForm.description
orderForm.quantity
orderForm.itemPrice
orderForm.price
orderForm.totalPrice
orderForm.deliveryDetails.billingAddress
orderForm.deliveryDetails.deliveryAddress
orderForm.noItems
FEATURE EMBEDDED TECHNOLOGY


TO THE RESCUE Preparing for failure and adapting to the cause


Words by Dunstan Power, director, ByteSnap E


ven with the best requirements and specifications, electronics design projects can drift. Missed deadlines lead to slower time to market, frustration in both technical and management teams, and potential financial/reputational damage if a product isn’t delivered. Each unsuccessful project has its own unique problems. Sometimes a single event is the cause. But often, a complex, entwined set of factors cumulatively result in failure.


Based on reviews of the projects presented for rescue, the following are the most common issues that lead to, or contribute to, the failure of electronics design projects: obsolescence, hardware choices, redesign life limited, field trial issues, slipping timescales, skills leakage, lack of resources, and the operating system no longer suiting the use. To counteract these concerns, ByteSnap, as an embedded systems consultancy, has recently launched a new, discreet service to put struggling electronics back on track. Dubbed the ByteSnap Design Rescue Service, it includes a thorough analysis of a project to identify reasons for failure, advice on





the best approach for rescue and the provision of realistic timelines for the ultimate delivery.


THE PROCESS The design rescue process is straightforward and operates as follows: Firstly, open communication is


established with project stakeholders, both technical and management: the development team needs to recognise there is a problem. The hardest part of the process can be making a start and admitting that there is a risk of failure. A consultation with a design rescue engineer can establish the problem and the device or system involved. Then there’s an analysis of the existing design - towards the end of the first consultation, a design rescue consultant will state whether the project is salvageable, and will subsequently provide an estimate of the time and cost involved. A detailed review by design rescue engineering experts thus leads to modifications to the system, testing the changes to find root cause of the problem and identify usable elements of the project.


   With the results verified, together, the


next step is planned. This could involve verifying the changes with a limited production run, or releasing modified software to a few key customers. The service was developed for the increasing number of clients looking to troubleshoot hard/software design projects: here’s a case study.


CUTTING CORNERS Previous development efforts failed to deliver a working device for a client that originally wanted a customised off-the-shelf solution; they then engaged with a contractor to deliver something bespoke. However, the resultant development ended with a non-functioning product, and the client was “ghosted” by the contractor who cut off contact. ByteSnap was able to reverse engineer the device to salvage any hardware and software, and ensure that the product was ready for manufacture.


ByteSnap


www.bytesnap.com Tel: +44 (0) 121 222 5433


14 DECEMBER/JANUARY 2020 | ELECTRONICS


/ ELECTRONICS


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44  |  Page 45  |  Page 46  |  Page 47  |  Page 48  |  Page 49  |  Page 50  |  Page 51  |  Page 52