Successful Endeavours - Electronics Designs That Work!

Design Led Innovation

Traditional Product Development comes up with the product idea, does the development, gets it into production and then tries to find customers to sell it to.

Design Led Innovation tries to turn that process around so the actual needs of the customer or user become part of both the product definition and the business model development. If you haven’t already heard of it, check out the Business Model Canvas.

I get the opportunity to present on topics like Innovation to Business Groups and even MBA programs and one of the interesting statistics I use is that the number one area for Innovation in the world today is the Business Model.

How Does Design Led Innovation Work?

So how does this all work?

Design Led Innovation

Design Led Innovation Process

In Design Led Innovation, the expected outcome is that when you engage with your customer, and begin to understand their needs, then you can start to offer them something that has much higher value for them and allows you to get a better price for offering that much higher value. The outcome is the classic win:win that great business is meant to deliver. And it is a key factor in not getting caught in the classic commodity service price war with the client’s purchasing officer driving the process.

It is also a continuous process. One description is that it is like “rebuilding the plane while it is in flight”.

Sounds scary, but the results seem to show it is well worth doing.

Design Led Innovation session at SEBN

At a recent SEBN breakfast session we heard from Tricomposite about their  experience of using Design Led Innovation to revolutionise their business and not only service their existing customers better, but offer them products they didn’t even know they wanted and create a much better value offering for them than they had ever considered before. And this has opened up potential market offerings to other customers who they would never have considered they could work with.

Here are the themes they explored in finding this offering:

  • focus on designers, not buyers
  • test is time pressure leads to design mistakes
  • test is rapid full-sized final material prototypes were valuable
  • test if there was room for service level agreements
  • test if there was room for collaborative design

And the answer to 4 of these was a resounding yes. Only the service level agreement test failed. Basically, customers expect service as a given. But the rest has opened up a complete rethink of their business. In fact, they shared that it was their existing perspective on their business that proved to be their biggest limiting factor.

Business Model Canvas

Rethinking the Business Model is a key component of Design Led Innovation. But not as an end in itself. Only after understanding your customer’s real needs can you determine how to make it easier to do business with them.

I recommend getting the Business Model Canvas book and taking advantage of the free downloads at Strategyzer. Here is a example of one of their tools.

Business Model Canvas Example

Business Model Canvas Example

Successful Endeavours specialise in Electronics Design and Embedded Software Development, focusing on products that are intended to be Made In Australia. Ray Keefe has developed market leading electronics products in Australia for more than 30 years. This post is Copyright © 2016 Successful Endeavours Pty Ltd.

Product Development

As a process, Product Development can be handled a number of different ways. And if your product only requires input from a single technical discipline which you are very experienced in, then you can usually predict everything you need to do and just make sure it all happens the right way.

But if the product is complex, involves many disciplines, and has unknowns about the technical direction to take, then it can sometimes resemble a roller coaster ride more than it does a straight forward journey. And there can be unexpected bumps along the way.

Our most recent employee brought this video to my attention and I thought it covered this topic really well. We used it for an in house lunch and learn session so I recommend you check it out to. It isn’t short so you might want to set aside a time you can sit back and enjoy it.

The presented is Andrew “Bunnie” Huang and the conference he is presenting at is linux.conf.au 2013. 

Quite a list of things you can run into just getting a fully package embedded computing device ready for market. The HDMI Man In The Middle exploit was my favourite part.

Successful Endeavours specialise in Electronics Design and Embedded Software Development. Ray Keefe has developed market leading electronics products in Australia for nearly 30 years. This post is Copyright © 2015 Successful Endeavours Pty Ltd.

Requirements Capture

Product Development is the core process your use when you have a great idea for a new product, or an improved version of an existing one. The very first step is to define what it is meant to do.

This first step is known as Requirements Capture. And requirements break down into 2 categories:

  • User Requirements
  • Engineering Requirements or Technical Requirements

These are related to each other and it is often useful to look at them in the right sequence. I’ll explain why later. Let’s look at what each involves.

User Requirements

This is a description of the product from the perspective of the user. It is written in the language of the user and describes what the product does and how it is used by the user.

User Requirements

User Requirements

We work with both technical and non-technical clients and the one thing they both have in common is that they can both write a document like this. It is also important that the focus begins with the user. Otherwise we can get carried away with the technical side of things and forget a real human being is going to have to use it one day. Concepts like Intuitive can have very different meaning to Engineers and the general public. So it is important to start with the user’s perspective.

Technical Requirements

This is what you end up with when you analyse the User Requirements through the lens of technology. We are translating from the user perspective to the technical perspective or engineering perspective.

Technical Requirements

Technical Requirements

As an example, the User Requirement might be that it complies with the relevant standards. This will translate to it passing C-Tick requirements for sale of product in Australia as part of the Technical Requirements.

Another example is that the User Requirement is that it must run off a pair of AA Batteries for 6 months. This then translates into a Technical Requirement that its average current consumption must be less than 0.57mA. If you are wondering how I came up with that then the maths goes like this:

An AA alkaline battery = 2500mAh so the average current consumption has to be 2500mAHr / (24 hours * 365.25 days per year  / 2) = 0.57mA.

That is the sort of analysis that is done every day by Engineers every day.

Requirements Analysis

The reason that it is important to look at User Requirements first is that we technical professionals love technology. And we love all the answers to the How questions. If we don’t focus on the What questions we can end up with a beautiful piece of technology that no-one actually has a use for. 

User Requirements = What

Technical Requirements = How

So there is quite a difference in how Engineers think compared to the rest of the world. For some other examples you might like to also look at these posts:

Does this work

Does this work?

Successful Endeavours specialise in Electronics Design and Embedded Software Development. Ray Keefe has developed market leading electronics products in Australia for nearly 30 years. This post is Copyright © 2014 Successful Endeavours Pty Ltd.

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

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.

Successful Endeavours specialise in Electronics Design and Embedded Software Development. Ray Keefe has developed market leading electronics products in Australia for nearly 30 years. This post is Copyright © 2014 Successful Endeavours Pty Ltd.

 The Client Perspective

 What you see depends on which direction you are looking from.

What do you see

How many bars?

If you count from the top, there are 10 bars. But there are only 7 bars when you count from the bottom. In this case it is an optical illusion based on how the drawing is constructed. However in real life the same sort of dilemma faces us as engineers when we are looking at Product Development from the technology perspective and the client is looking at it from the Return On Investment (ROI) perspective.

Roger La Salle makes the case in his book “Think New” that the problem with most new product introductions is not the technology. In general, we engineers will find a solution. The risk that usually kills the product is the business risk or market risk. So our focus as engineers is on making the client successful by getting the product to work technically through Innovation and our skill as engineers, but the client’s biggest risk remains maximised the whole time. The business risk is only dealt with when the product is finally being sold in sufficient quantities to cover the development costs and now return a profit.

Those are 2 very different perspectives. It is worth keeping that in mind the next time you are working on a new product.

The image for today’s blog post was provided courtesy of Dr Marc Dussault, The Exponential Growth Strategist who is always on the look out for examples of antimimeticisomorphism, which I am sure you’ll agree this is!

Successful Endeavours specialise in Electronics Design and Embedded Software Development. Ray Keefe has developed market leading electronics products in Australia for nearly 30 years.  This post is Copyright © 2013  Successful Endeavours Pty Ltd

Ideas Worth Pursuing

Matt Barrie

Matt Barrie

BRW recently ran an article by Matt Barrie on business ideas that are worth pursuing. If you haven’t heard of Matt Barrie, he founded Freelancer. In the article he wrote about business ideas that interest him, and what doesn’t interest him. In particular he had a sideswipe at us Engineers about our focus on the technology and solving those problems first instead of testing whether the idea has a viable market. As an Engineer who has had to learn about business in order to run one, I can agree with some of what he said. In particular, we can become so focussd on the technical problem that we don’t make sure there is a real business case for the final product or service.

Here is the short list of what Matt Barrie doesn’t like in a business:

  • Anything that involves selling your personal time – eg. consulting
  • Anything that isn’t scalable – more on that later
  • Anything that requires a technology breakthrough before you have something to sell
  • Small, niche and low total market potential opportunities

By scalable, Matt means that the sales potential is not directly proportional to either people or capital investment. Matt wants leverage. In his words “Businesses that are not scalable are bad“. But is this really the case? And what does he mean by bad?

Is non-scalable always bad?

I agree that if you want to maximise your income potential, the non-scalable businesses will not give you same ability to do that as scalable businesses will. However my business doesn’t only exist to make money. Making money is a byproduct of a good business that is well run and meets a real need. Businesses should make money, otherwise they are not adding enough value or not well enough run.

My favourite business quote is “The purpose of the organisation is for ordinary men and women to come together, and in cooperation with each other, do the extraordinary”!

For me, business is a mechanism to make the world a better place in partnership with others. It is too big a job to do on your own. And it should deliver real value.

There are many essential non-scalable activities out there. Here is a short list:

  • anything to do with the patient side of medical or nursing care
  • most forms of teaching and education
  • personal services
  • mental health
  • government
  • Product Development
  • construction

Notice I said activity. For the quote above also covers the “Not For Profit” sector and Government. Both should deliver real value. They just don’t directly derive their income from that value.

I’m sure Matt Barrie is not upset if he has to see a Doctor just because the Doctor does not have a scalable business.

The final point above is about Product Development. Thomas C. Gale said, “Good design adds value faster that it adds cost“. So I am not advocating development at any cost. It has to have a value proposition. A client of ours recently told us of a product we designed for them nearly ten years ago that they had made millions of dollars from. Given our fairly modest fees for that project, they got a massive bargain there. That was an example of very good value Product Development which they got a lot of scalable leverage out of.

Product Development uses a mixture of leverage and personal effort. Leverage comes from using existing technology tools to do the work faster. This includes things like:

  • Computer Aided Design and Analysis tools
  • Reference Designs and existing technologies
  • Science and technology understanding already known
  • High Level Design tools and processes
  • Compilers, libraries, components, operating systems, platforms, standards
  • Research findings, existing data, other specialists

The above all came from past work that can be used to make current work more productive or more effective. I started my career laying out PCBs using tape. Now I wouldn’t dream of not using a CAD System. We use Altium Designer for Electronics Design Schematic Capture and PCB Layout. This is much more productive than the manual methods. As part of our ongoing Product Development activities for our clients we design and lay out a new PCB every 2 weeks on average and this is only possible with the use of CAD tools and the full leverage of our experience. In general I don’t want to rediscover the wheel, or the technological equivalent of that, in whatever area of Electronics Design or Embedded Software Development we are working at the moment. I want to take as much advantage of leverage as I can, and only apply the personal effort to what I can’t buy at a reasonable price.

Likewise we use proven Software Development tools that just work every time. It is not a good use of any of my team’s time to be working out why the latest release of something no longer works or breaks a project we had nearly completed. Of course we shouldn’t do that mid project anyway, but the legacy issue still applies. Clients do want updates down the track. So we use IAR tools for our Embedded Software Development. They work, are well supported, and we almost never have an issue of any kind with their performance.

So my conclusion is that non-scalable business activities are essential to modern economies. They just aren’t where the maximum profit potential is.

Let’s take manufacturing. We serve Australian Manufacturers by providing them with the new Electronics Designs they need to either remain competitive, become market leaders or bring a brand new product to the market for the first time. The manufacturing side is scalable although the Australian economy primarily supports lower volume or niche manufacturing opportunities. But once a design is in production and the process is running, they can scale up to meet demand within their capacity.

But our business activities are not scalable. Each design takes at least some personal effort to produce. But if I stop my non-scalable activities, then someone else has to do it. And if everyone does the same, if all the non-scalable activities stop, guess what – the scalable activities also stop!

Freelancer enables the buying and selling of non-scalable activities in a scalable way. It is a great service to those who use it and extremely good value. I agree with Matt Barrie that it is a good business.

Personal effort is still valuable

There is an old joke that goes like this, “No matter how many women you put on the job, it still takes 9 months to make a baby“. Some things cannot be sped up by adding more resources. This analogy works well because we all know this is the case for pregnancy. Many other things are also like this. It will take generations to get peace in some parts of the world. Mindsets cannot be undone overnight. And it takes time to create economic frameworks. Successive Australian governments have spent 50 years working toward an uncompetitive Australian Manufacturing industry. This will not be undone with one policy initiative or one statement of a change of approach. It will take time and personal effort, by those with a vision, to make it happen.

So my belief is that personal effort is not only still valuable, but still essential, even if there are limits to how much I can scale it. I agree with Matt that it isn’t going to make me as rich as his approach will make him, but I’m not just in it for the money. For me, it is not bad, it is essential.

The link to the full article is at Ideas Worth Pursuing.

The twin pillars of modern business are Greed and Ruthless Efficiency according to the Harvard School of Business. If this were an organic process, we would call it cancer. Ultimately it will kill. We need a better model and we need better values. Greed and Fear are the enemies of many a good thing.

And if you were wondering where my favourite business quote comes from, it is from Aristotle, some 380 years B.C.

Want a great career?

And finally, a Ted Talk on “Why You Will Fail To Have A Great Career”! OUCH!  But is it true?

This is an excellent presentation that challenges many of the common assumptions about careers. But there is hope and Larry Smith explains both the challenge and the solution.

Successful Endeavours specialise in Electronics Design and Embedded Software Development. Ray Keefe has developed market leading electronics products in Australia for nearly 30 years.  This post is Copyright © 2012  Successful Endeavours Pty Ltd

Electronics Hardware

The idea for this post came from an interesting article by Bryan Murdoch who also writes a blog on technology topics. In the article he looked at why some developers can be Averse To Change and made some interesting observations about why that is so.  One of those conclusions I agree with very strongly.

Before I come to that, let’s look at the basics of the Embedded System.

An Embedded System is a computer that lives inside a system and is dedicated to that system. It has specific control functions and can be quite simple or quite complex depending on the system. An Embedded System therefore has Electronics Hardware that Embedded Software runs on.

Electronics PCB

Electronics PCB

 

The Electronics Hardware can be as simple as a tiny 8 bit processor such as the Atmel ATtiny13 or a full blown Intel multi-core processor. But the key is that it is dedicated to that system and not a general purpose computing device such as a Windows or Linux PC that we just happen to be using for that purpose today and can use for something else tomorrow.

Electronics Hardware is not generally reconfigurable in the field and where it is, such as FPGAs, it is really the software control portion that is changed and not the underlying hardware itself.

Embedded Software

Embedded Software

Embedded Software

The Embedded Software is therefore the software that runs on the Embedded System. This can be as simple as a few lines of assembler through to a full Information Kiosk product running on Windows Embedded. As usual with software, it can be anything. We are not going to focus on what it is, but why we prefer to use Software for much of a modern system’s functions.

Why Software?

The real reason for the focus on software, is that once you deploy the hardware, the only thing you can easily change to improve it is the software. This is one of the core points made by Bryan Murdoch that I agree with.

Another point he made in a post on Software Cost is that software becomes more valuable and more usable when we make the effort to make it simple, testable and compact. This makes it more readily reusable and also more easily maintained. These are 2 lifecycle costs not often considered at the front end development phase of a project. It is also a good reason why the number of lines of code is not a good indicator of the real value of a piece of software.

Product Development

So this is where the rubber of the New Product Development process hits the road. Amongst other things, you have to be able to decide what you will do in software and what you will do in hardware. And it also depends on your core competencies as a company and those in your supply chain. During the development of the XBOX processor Microsoft told IBM that they were a software company and so any issues with the silicon they would fix in the drivers. This was done to reduce the development timeframe and fits with the comments from Bryan Murdock about one of the primary reasons people use software, its changeability. It also played simultaneously to both IBM’s and Microsoft’s strengths and was a smart business move on Microsoft’s part.

Successful Endeavours specialise in Electronics Design and Embedded Software Development. Ray Keefe has developed market leading electronics products in Australia for nearly 30 years.  This post is Copyright © 2011  Successful Endeavours Pty Ltd

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

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.
  • Anything clever or tricky needs to be checked by someone else.
  • Everything else also gets checked.  Design reviews, code walk-throughs and prototypes save time, money and heart ache later on.
  • 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 ManagementRiskManagement

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

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

Test Everything

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

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

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

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.

 This post is also available as an eZine article with Expert Author classification.

Ray Keefe has been developing high quality and market leading electronics products in Australia for nearly 30 years.  For more information go to his LinkedIn profile. This post is Copyright © Successful Endeavours Pty Ltd.

Electronics Development and Success

Hello again,

A couple of posts ago in Electronics Manufacture Shines in Melbourne I said I would explain the origins of our company name.  Many have suggested that Successful Endeavours sounds more like a personal coaching enterprise or a business that handles products by people like:

And the list could go on for a long time.

While I do hope we motivate and encourage our clients to improve their results, we assist them by undertaking activities such as:

Electronics Development Activities

  • Electronic Circuit Design
  • Electronic Circuit Simulation
  • Analogue Electronics
  • Analogue Design
  • Printed Circuit Board Design
  • Printed Circuit Board Layout
  • Electronic Prototyping
  • Electronic Testing
  • Embedded Software Design
  • Embedded Software Development
  • Embedded Software Coding
  • Embedded C
  • Embedded Software Debug

 

Development Statistics

The name came from some industry statistics on the success rate for Product Development.  You can read more details in Reducing Electronics and Embedded Software Product Development Costs and I will summarise here:

  • 80% of embedded development projects fail in someway or another
  • Embedded software is 80% of the cost of an embedded development project
  • Embedded software is responsible for 80% of the delays and shortcomings

 

Successful Product Development

So it seemed to me that many Product Development Projects are unsuccessful endeavours.  I wanted to change that.  We have a success rate significantly better than all the industry norms. Our short USP ( Unique Selling Proposition ) is:

We Make Stuff Work

That’s it.  The details are complex but the philosophy is simple.  So for me, Electronics and Embedded Software Development should be a routinely Successful Endeavour.  And so the name Successful Endeavours was chosen.

I am passionate and committed to assisting Australian Electronics Manufacturers who want to keep making their products in Australia.  Made In Australia is what we are pursuing and we are focusing on this segment.

Ray Keefe has been developing high quality and market leading electronics products in Australia for nearly 30 years.  For more information go to his LinkedIn profile. This post is Copyright © Successful Endeavours Pty Ltd.

 

National recognition for local Casey Business

OK, I couldn’t resist that blog title or this headline.  It isn’t often you get a chance to say something like that.  If you hadn’t heard yet, we are finalists in two categories in the EDN Innovation Awards for 2009.  Melbourne is the Electronics Manufacturing capital of Australia and we are based in Berwick which is administered by the City of Casey .  And we are also members of the Berwick Chamber Of Commerce.

Successful Endeavours in the NEWS

The Casey Weekly Berwick has just done an article on Successful Endeavours that also covers the EDN Innovation Awards we are finalists for.  You can check it out here Electronics Whiz Wired For Success.  And as a bonus, you get to see what we look like.

Electronics Manufacturing

Our aim is to turn Australian Electronics Manufacture into Low Cost Electronics Manufacture through improving the total cost of a product throughout its life cycle.  This is not a quality reduction process.  Quite the opposite.  Getting the product right so it doesn’t fail and does do what it is meant to do is one of the things necessary to reducing cost.

Located on the outskirts of Melbourne we primarily serve Melbourne based Electronics Manufacturers by providing them with Electronics and Embedded Software Development services that save them up to 70% compared to traditional linear Product Development.

So how do we do that?

Firstly, there are a few blog posts you can refer back to that will fill in some of the details.

Successful Product Development

Australian Electronics Manufacturing

Low Cost Electronics Manufacture in Australia that competes favourable with China is feasible.  Ignoring the trade offs discussed in the links above, the steps to take are:

  • Identify the primary priority – is it time, cost, performance?
  • Reviews costs – all the costs – see the last link above if you are sure what they all are
  • Reduce Cost through redesign to remove unnecessary labour and to streamline manufacture
  • Implement
  • Deploy
  • Monitor and correct as required

Written like this it sound simple, and conceptually it is.  Where it gets lost is in the assumption that it can’t be that simple.  But there aren’t any hidden traps in this process.

We have had a few queries about how we came up with our company name, Successful Endeavours. Next post I will reveal all.

Ray Keefe has been developing high quality and market leading electronics products in Australia for nearly 30 years.  For more information go to his LinkedIn profile. This post is Copyright © Successful Endeavours Pty Ltd.

________________________________________________

Next Page »