What is a Prototype?

A Prototype is done in order to explore some aspect of a new opportunity without having to fully commit to it yet. Prototype has a number of potential meanings including:

the original or model on which something is based or formed.

someone or something that serves to illustrate the typical qualities of a class; model; exemplar:

something analogous to another thing of a later period:

Biology. an archetype; a primitive form regarded as the basis of a group.

So a Prototype is either an early model or a smaller scale development to test a new idea.

Why Prototype?

So for engineering, we Prototype to reduce risk, and we learn from Prototypes to improve the likelihood of project success by being better informed for the next round of design. So a Prototype is a core Product Development ProcessRisk Management strategy.

Product Development Process

A Prototype can also reduce other risks such as financial risk or market risk and isn’t always done for technical risk reasons.

Financial risk can be managed by breaking a project up into a series of stages and only committing funds to a stage when its predecessor has been successfully completed. A Prototype is often done ahead of a major block of Product Development to test whether the technical approach is likely to succeed and provide early warning of unexpected problems or interactions.

Market risk can be managed by trialing a new product idea with a smaller group of candidate customers to gauge their acceptance of the product. This has to be well managed however as history has shown that this approach, especially in the case of focus groups, can often just elicit the outcome the company hoped for and not a real example of how the market will react. Just look at all the failed Coca Cola new flavour launches.

And of course, technical risk can be managed by making Prototypes that implement the highest risk features as early as possible. We covered this in Improving Product Development.

And then having designed a product it is normal to build a Prototype to ensure the final solution works as expected. This manages the risk that production tooling might need rework or even redesign.

How to Prototype?

This depends on the problem you want to solve. For this section we will focus on technical risks. A Prototype is very useful to allow you to measure some essential elements of the final product without committing to a final solution. So you can explore:

modelling a problem and simulations

noise and interference

power consumption

performance versus cost (compare several different prototypes)

responsiveness

system resources required

hardware versus software solutions

temperature rise

materials properties

shape and usability / ergonomics

fit (especially PCBs in mechanical housings)

…

And the list can go on. The key is to determine where the risk is and manage that. In Project Management Pre-preparation we looked at using a Prototype to reduce both technical and financial risk at the same time. In this case, other developers hadn’t been able to produce a working product so the client had a clear risk to manage. And our approach was to make a jig that allowed us to explore the sensing that was needed and get real data to then analyse and develop a solution. The same jig allowed the solution to then be tested before we designed the Electronics PCBs and Embedded Software needed for the final product. And the client was able to authorise each next level of expenditure with confidence based on us having delivered against the requirements for the previous stage.

Simulation

And of course, 3D Printing for Electronics has enormously expanded the possibilities for mechanical prototypes by allowing anyone to quickly build and test the fit of objects together. It is also a viable option for low volume manufacturing.

Viewpoints matter

This is often one of the areas where Engineers and Customers can get out of step. And in particular, is a big issue for Software Development and IT systems. Check out the image below.

Round or Square Columns

Technical professionals such as Engineers and Software Developers tend to be detail driven and so probably look at the system from the ground up. So we would see round columns.

Entrepreneurs and Business Owners tend to see the world from the top down and so would see square columns. And this difference in perspective can be a problem in implementing a solution that works for the customer.

So here we have an image that represents the potential difference between the Engineer Viewpoint and Customer Viewpoint.

Requirements Management

The real issue here is Requirements Management. This is one aspect of Software Development where I like the V Model for Software Development and the European Space Agency Software Engineering process. It splits the problem down into steps and also lets you know whose language the documents at the step are written in. So User Requirements are written in the language of the use. Technical Requirements are written in the language of the technical professionals. And Requirements Analysis is required to determine the relationship between the different viewpoints. For most projects the analysis is used to translate User Requirements to Technical Requirements. So now we can all have a viewpoint that we understand and it is linked.

V Model

The general steps are:

User Requirements – in the language of the user

Product Requirements – in the language of the user and relevant standards and market needs

Technical Requirements – derived from both the above and in the language of the technician

Functional Decomposition – breaking the problem down into specific functions to be performed

Architectural Decomposition and Requirements Allocation – working out that is done in hardware, software, locally, remotely …

Detailed Design and Module Specifications – specific modules to be designed and tested

So we move from user language to technical language in a structured way that allows us to understand was is required and make sure nothing has been missed.

Requirements Analysis

Product Development Process

The Product Development Process is intended to ensure that the product meets its requirements and is delivered on time and on budget. And regardless of the size of the project the above steps are required. Who does them and how they are done is less important than that they are done. Smaller projects might not require a formal approach but any significant project certainly does. And this also helps to overcome the difference in viewpoint between Technical Professionals and their Customers.

Product Development

As a technical professional, I tend to think of the Product Development Process, also known as New Product Development, as the creation of the product technology through to a working unit that can then be manufactured. And of course managing risk to Improve Product Development Outcomes. The only thing wrong with this picture is that this is only a part of the overall process of bringing a new product to market. So I’ve put a diagram together that shows a more complete picture.

Product Development Process

One thing I noticed when I did this is that there were 4 areas that had the most influence on the overall process. These are:

design capability

development capability

funding

production capability

And of these, the ones that had the most influence were:

funding

development capability

Products Have Stakeholders

A successful product is successful within a market and has multiple stakeholders. A developers, we might not be as aware of all these stakeholders as we could be. For instance, a product must not only work from the technical performance perspective, but it must also work from the perspective of the manufacturer, the sales person, the installer, the service technician, the shareholders, those tasked with public safety and clear mobile communications, those who have to dispose of the product at its end of life and of course the end user. That is a lot of people to please. And they aren’t all on the chart above either.

This is why exceptionally good Product Development is not just a case of following a specific methodology. So we are mostly involved in the Product Development Process but it does help a lot to see that there is a bigger picture and that even if you do a good job technically, it is just one of the the ducks you need to line up in order to get all your ducks in a row and a successful product into the market and making money and adding value to everyone.

In this post we will look at the Product Development Process and how to get improved outcomes. But first here is a fun graphic made from our logo.

Successful Endeavours – Making Electronics and Embedded Software Work

Product Development Process

The Product Development Process is intended to reliably deliver new products for manufacture or distribution. This is a critical component of a Product Strategy where you are creating the product rather than sourcing it from a supplier. So you would think that it should be a highly optimised, well oiled machine that reliably delivers successful products.Alas that is not always the case.With 30 years of experience in Developing Products for a wide range of industries I have seen my share of projects handled well and not so well.Here are some general principles I have gleaned from my experience in Successful Product Development Projects:

Risks must be identified and managed. Track them and eliminate them as soon as possible.

Hold the timeline. Foster an attitude that slippage is not acceptable.

Test and check everything.

It’s not finished until no-one has to do another thing to it.

So six core principles. They are inter related of cousre. Let’s look at how these work out in practice.

Successful Product Development Principles

Lets look at how each of these priciples can be used to improve the likelihood of a Successful Product Development Project.

Risk Management

Risk Management is an old idea. Not surprising since risks have always existed. Did you know that during the Manhattan Project it was determined that there was a chance that a fission bomb could ignite the whole atmosphere ? Having got contradictory reports the argument was eventually settled by a report showing that although it was possible, it was unlikely. How comfortable would you feel running that risk ?Fortunately the average Development Project is dealing with much more mundane risks such as achieving Technical Requirements such as:

Power Consumption

Unit Manufacturing Cost

Performance Criteria

But the approach is still the same:

Identify the risk

Work out how to ameliorate the risk – reduce it – or eliminate it

Do tests to confirm the risk has been dealt with

Iterate until it is no longer a risk

Review the clever bits

Test Everything – Clever Design Needs Test

Where possible, any particularly clever or tricky areas of the project need to be reviewed by someone not involved in the everyday work of the project. This is primarily to ensure that assumptions are challenged. If you can’t get an outsider to do the review, use a process like Six Thinking Hats by Edward De Bono which can allow team members to step outside their emotional and assumptive predispositions. Unchallenged assumptions are unmanaged risks.

Review the rest of the project

Review Everything

The astute amongst would have noticed that I am proposing everything gets reviewed. But the tricky bits get extra review. This section is for the regular bits.Reviews are an essential tool to find mistakes early and eliminate problems down the track. You don’t have to solve a problem you don’t have. Or as Jack Ganssle famously quipped “Skip Bugging To Speed Delivery“. The whole article refers to using Code Review and Design Review to find problems early and fix them so they don’t become much bigger problems later on.Imagine a scenario where a Software Bug causes an electric motor to try and spin backward every now and again and then corrected itself almost immediately. You would get a momentary shudder or jerk followed by correct motion and it would only happen every now and again. How would you determine that this was a software fault and where the fault lay? It could be symptomatic of any number of issues including Mechanical Design and Electrical Design.How about this similar real world case. I won’t mention the company, but their elevators had an Integer Overflow problem in the motor controller that caused the elevator to go in the wrong direction, about once a month, for half a floor. Very disconcerting to the passengers if they pressed up, and promptly dropped half a floor before then going up. Fortunately they found it and fixed it before it happened to someone at the top or bottom floor.All the Software Industry Metrics show for that for Software Development; Design Review, Code Review, Unit Tests and System Simulation save money and time. And yet in many projects they don’t happen enough or are done after the event as a Quality Assurance box ticking activity where they add mostly cost and little in the way of value. Lean Coding argues that you can reduce your Software Development Budget in particular by doing Code Inspections during the project as part of the Risk Management and Quality Management process. By reducing the bugging, you can reduce the debugging.

Stick to the Timeline

Project Development Timeline

An attitude that the schedule slipping is normal can be very costly. Some examples of how to avoid this are:

Develop and Simulate the Software before the Hardware is ready

Prototype early and thoroughly

buy in IP where it makes financial sense – this can also reduce risk

get expert assistance with areas outside your competence

review regularly and honestly

As someone who has done a lot of team leading and project management, I have learned to ask about progress in more than one way. I find the following to be very common:Manager: “This module is estimated as 10 days of work to complete. How complete is it”? Developer: “About 80%”. Manager: “How many more days of work are required to fully finish everything”? Developer: “To fully finish everything, I would think 6 more days would cover it all”.The discrepancy is easy to spot. People estimate high on progress because they want to please. They also like to finish well so they tend to estimate conservatively on required effort. In practice the real answer lies somewhere between the 2 extremes. If the task had already consumed 6 days of effort then it is likely to run late.If you have ever built a house you might have experienced the knock on effect it has when one trades person doesn’t turn up and everyone else misses their scheduled action time because they are now waiting on a predecessor task, the trades person who has to come back again, before they can start their task. The same thing happens on projects.So fight hard to hold to the schedule. It is better to over resource a task (according to the plan) and get it done than to let everything and everyone slip which usually costs a lot more.Additionally, it is quite common that the later you are in the market, the lower the overall profit. So it is worth holding the schedule for this reason as well.

Test and Check Everything

Test Everything

This is another Risk Management related principle. Don’t assume it will be OK. Even if you have done it 100 times before, test it again this time. Make sure it really is OK. This ensures it really is 100% complete.This also implies that you are going to design things so they can be tested. Another principle. Design For Testability or somestimes called Design For Test. Do it. It will save you time, effort, money and sleep.Test Driven Development is another example of a Modern Development Methodology where you set up the test first then develop the product so it passes the test. If the Product Requirements change, you change the tests first, show that the old Product Design fails the test, then update the Product Design until it now passes the test.

It is not finished until no-one has to do anything else to it

Many tasks are called complete but they aren’t. The documents might be checked into the Revision Control System, also known as a Version Control System or Version Management System, but it isn’t complete until it is 100% tested, 100% integrated, 100% reviewed and 100% signed off and no-one has to do another thing.This also means that when tasks are identified that weren’t thought of in the original Project Plan, you then add them and don’t try and fiddle them into existing tasks. This is different to working out the fine detail of a task and realising it is under resourced or over resourced on the Project Plan.You also want the extra tasks visible on the Project Management Plan so when you do the next project you have evidence that they were required last time and can make allowances for them.

Trip Assurance for Developers

Satisfaction Guaranteed

In marketing, the term Trip Assurance refers to the client having a clear expectation of this transaction or experience being a good one, just like every other one has been. I think we can begin to develop some of the same as developers whereby projects can be routinely good experiences and likely to be so each time.