Our Process
Electronic Product Architects
Our team handle a range of complex electronic development projects and offer a full turn key service to get your product ready for production.
Our Process
We are experts in turnkey project delivery. We carry out all aspects of design work for your electronic product. This includes designing your enclosure, the hardware to go inside it, and writing any software to delight your customers.
We start our projects by getting your requirements from you. To demonstrate we understand them, we write your requirements back to you. From this we create a test plan. This critical step shows you how we will demonstrate the product works. Critically for us, this also scopes the work and helps us both avoid scope creep, where the final product bears little resemblance to the original idea.
We then carry out the expert work. Depending on the product, we might design an enclosure to go around it. We have experience in a variety of materials and processes. Perhaps your product will be mass produced, perhaps it will be a one-off. Either way we have the know-how to get it to market.
Perhaps your product requires a circuit board, to activate a feature or provide a user experience. Again we have experience of high power and low power designs. We have experience of simple and complicated boards. We can identify a manufacturing partner for you, or work with your existing partners to get the product to market.
Perhaps your product requires software. Maybe the product itself has some feature that is easiest implemented in software on the product. Perhaps it is a companion app, or a reporting tool which supplies data into (say) an ERP system. Regardless, we can work up and down the software stack.
When the design is stable, you will have prototypes you can take to market. This is a good time to evaluate the product. Does it perform the way we want it to perform? Does the way we want it to perform need to change? Ideas do not always survive contact with the customer. Perhaps the customers have their own ideas about what the product should do, or how it should behave. This is the moment to evaluate the product and consider whether or not the design meets expectations.
Research and Estimates
We have significant experience in what we call “research” projects. These are projects where we do not know what the outcome will be, or whose outcome is uncertain. For example, “How much will this product cost?” is a research question. Let’s break it down.
To keep the project under control, we need to tame the unknown. We can do this in a number of ways. First we have to scope the research which will be carried out. We don’t want time to be spent on anything other than the core research. Ancillary research may be interesting, but if it’s not in scope it should not be of interest. For our sample cost, if the product is made of wood, we don’t research the cost to make in metal. Perhaps though we might explore different woods, or different sources of the same wood.
When the project has been scoped, we estimate. With the unknown, prior experience can guide us. We can estimate the novel features in the research and use that to create an estimate. For our wood product, perhaps we know the response times of dealers and factories. We can use this information to estimate how long the quoting process might take.
With a time estimate in hand, we set a budget. We do not want our research phase to end with no tangible output. Setting a budget helps to keep cost in mind while carrying out the work, and helps control overall project cost. Research is usually a precursor to another set of expert work being carried out, so the budget for research must reflect that it is only one aspect of bringing the product to market.
All the best projects, research or no, gain from being SMART: Specific, Measurable, Achievable. Relevant and Testable. By applying these criteria to our research, we help to keep the scope manageable. For our sample wooden product, we can give a specific answer: a number. The project will be measurable because its budget has been set. We can call it achievable because we know a number of suppliers are available. Cost is directly relevant to the business model. Finally we can say whether or not the research delivered by testing whether or not a price is supplied.
Testing and Test Plans
Testing and test planning is an often overlooked area of project management. It is critical for us as a tool to scope the projects on which we work. Many projects we encounter in the wild have not planned anything for testing. We see this as a critical weakness, to be addressed immediately.
By agreeing a test plan up front with the client, we agree exactly what the tests will be. Anything other is out of scope. This helps keep the expert work focused. It also helps the client keep in mind the most important features of the product. As the expert work is carried out, the focus is on passing the tests.
In some industries, test planning is mandatory. We would not get far working on medical devices without traceability of the requirements through to test reporting. However it is an important tool no matter the regulatory requirements of the product. Skipping this step is attractive due to the reduced workload, but the false economy becomes obvious as development ends. How do we know the project has ended successfully? First we have to define success.
Clients mention the overhead in writing a test plan. The counter argument is simple: how do we know the project is complete without it? If the client “just knows” when it is ready, that’s great – for the client. That knowledge must be communicated through the whole of the project team. The test plan sits alongside the requirements in defining what the product must do. When the client is unavailable or cannot clarify, these documents communicate the intent to the experts.
Just because a test plan has been written does not make it final. All documents can be iterated and the test plan is just another document, in that sense. If an opportunity is identified part way through the project to improve the delivery, or to scope the work differently, it can be taken. The process does not have to be onerous.
Testing and test planning is a critical part of our procedure, and we hope you will agree.
Design Flexibility
Maintaining design flexibility is a key component of the work. We have witnessed projects where key design decisions have been made too early. This can tie development down into a route which would never have been able to succeed. The key to avoiding this is project mapping.
When we have requirements in hand, we begin breaking down the project into the smallest chunks we are able, at that stage. We try to map dependencies through to identify the decision points in the project and make an estimate of how late the decisions can be left, or how early we need to commit to keep the plan viable.
One example is component selection. An electronic design requires components. Many components will be commodity – typically 80% or more of the bill of materials. Because these components are commodity, in the early stages there is often little value committing to a particular supplier.
On the other hand, if the function required is more esoteric, it may be necessary to commit earlier during design. Perhaps the power supply has a particular requirement – efficiency and accuracy are often raised – necessitating an early choice. In this case an appropriate supply will be selected early.
We want to avoid being in a situation where the product is over-specified early in its design. For example, we were supplied a PCB from a 3rd party designer with an existing microcontroller built in. We had to write firmware for it to interface with a Bluetooth device. Later, when the Bluetooth module was changed, the same microcontroller was used. Due to changes in command structure, the code turned out to be near the memory limit of the microcontroller, which it turned out had no easy upgrade route. Here the early decision to optimise for unit cost turned out to have cost implications when changing the radio. Had the design offered flexibility, an optimisation stage (and its time, and cost) could have been avoided.
The advantage is clear. Allowing flexibility in design until the last moment gives contingency. It allows us to deal with the unexpected easier.
Change Management
Late arriving requirements are a fact of design. Everybody begins the requirements phase with the best of intentions. It is unusual for those requirements to become a product directly. Usually requirements will change over the course of the design; this is natural.
Handling the requirements change process must be formalised as early as possible. Some industries mandate traceability of requirements changes but other customers consider this an unnecessary burden. We believe the requirement is never unnecessary, but must be appropriate to the customer.
The downside risk of not controlling changes to requirements is confusion. It is easy to have a 10 minute call and outline a change, but this change then needs to be communicated through the team. If the change is not communicated effectively, the tester may not know the test plan has changed. The designer may not produce a design compliant with the updated test plan. Or more commonly, the change is not effectively confirmed with the client and the client is disappointed by the delivery. A key part of the project planning stage is requirements gathering; that means the same process should be used to confirm the change back to the client as the requirements are updated.
A change to requirements means a change to the test plan. The 10 minute call needs to be disseminated throughout the group. While this might be opaque to the client, it is imperative this be carried out internally.
Change management requires continuous assessment. When changes are substantial, it may be appropriate to open a fresh scope of work. Usually substantial changes are a result of contact with an important stakeholder. Some contingency is included each time we quote, but substantial changes which overwhelm the contingency may result in changes to the scope of work.
Key to the process is realising these are processes along the route to a product. There is no judgement when requirements arrive late, or change. Professionals have systems to deal with late arriving requirements. The possibility must be acknowledged, and formalised early.
Requirements Engineering
Requirements engineering is a difficult discipline. There is a fine line between staying in scope and meeting the client’s often-unspoken dream. Clients always buy a dream. There is an idea of a product which will sell millions. The difficulty is communicating enough nuance that the essence of the product can be captured inexpensively.
One of the skills encouraged in our team is an ability to recognise going out of scope. If something is not defined in the requirements, there are two options. Either we make an assumption on the client’s behalf (risky!) or we clarify with the client. Our preference is usually clarification.
The risk of assumption is we get it wrong. It is impossible to fully communicate a dream. The dream itself may be half formed and our brief might be to investigate possibilities.
The best answer to this is to spend the time with the client, going over the idea and documenting as much as possible. In this way the “feel” of the product, the user experience, is likely to take form. Questions can be posed.
It is critical to identify a fail state as early as possible. “What do we do if something goes wrong?” is a question we always ask. Untested error states are one of the largest causes of in-the-field failure. We must identify an error state early in the design and work out what is the best action. We must then test this action. In some industries, test report coverage of error cases can be mandatory.
It is useful to give the problem to a number of minds. One of the goals is to reduce the amount of unspecified behaviour to a minimum. By exposing the idea, and the requirement, to as many minds as possible, the chances of “not thinking of” something are much reduced.
Requirements engineering therefore requires a deft touch. We must be careful to gather the requirements without spending so long doing so that we delay the project.
