Contents

At Acroname, our work revolves around projects and through the more than 15 years, we have come to a consistent method of organizing and planning projects for the best results.  This article outlines our best-practice approach we try to follow when pursuing contract work, product development, and even the organization and development of the company itself. 

These design and planning practices are learned, borrowed, and stolen from previous schooling, observing other companies and project cycles, and, most importantly, these practices are established through learning from mistakes and misguided attempts in the past to complete projects. 

What constitutes finishing a project? Does getting something to work mean it is finished? How about getting more than one to work? Perhaps it is getting the design refined enough that others can complete the building and still get it to work.  Finally, it could be getting it to work, others able to build it, and most importantly, end-users able to use the results effectively.  This is product design. 

Often in school, there is a pressure in instruction to move rapidly and cover a great deal of ground.  Such survey classes often have projects or assignments associated where only the proof of concept is required.  You only need to get it to work once, with prescribe inputs and users, and you can rely on others frameworks, environments, and sub-systems.  This accomplishes the goal of coverage but not the details of building products. 

Complete life-cycle product design ends up feeling very deliberate, slow, and tedious.  The results, however, can be very exciting and can be relied upon as robust subsystems for even more challenging designs and products comprised of well designed sub-components. 

Often work on new products in poorly established markets involves discovery, invention, and basic problem solving to actually accomplish the goals set out for the product.  It is called innovation and it takes a discipline to do well. 

Here is the outline of how we try to approach projects and in particular, product design and contract work based on our experience. 

Goal Setting

Simple as it may seem, establishing a coherent goal is often difficult.  Goals should be very specific and discrete.  The goal must also be measurable.  Saying "I am going to build a cool general-purpose robot" doesn't cut it.  Something like "I am building a robot for hard surfaces that is roughly 1 kilogram in weight, the volume under a cubic foot, and 2 degree-of-freedom motion with good dead reckoning ability" is getting closer. 

Research

You could establish a goal and plow headlong into building something but what if there is already such a thing available? What if some of the component systems are proven and established.  Standards may exist that allow your project outcome to gain much wider acceptance. 

Researching your goal helps see how this has been accomplished, establishes ways you can differentiate or play well with existing approaches, and also avoids unnecessarily re-inventing the wheel.  Unfortunately, when working in the commercial marketplace, this step may force some new or different goals due to silly pursuits of intellectual property by others (patents) or the need to jump higher, run faster, or throw farther than the existing competition. 

This is a great place to start taking copious notes in some form of notebook or digitally as you will find yourself wanting to look back to re-inform yourself of reasons you chose certain paths in the future.  More importantly, if you are working in a team environment, someone else may be responsible for future work and having your notes and sketches, no matter how crude, along the way will be a huge asset to that person in the future. 

Hypothesis

OK, before you start cutting metal, spraying paint, or blowing things up, it is time to sit back and establish what you think will happen.  That means predict how people will use your product, how many you might expect to make in the lifetime, how the tools and sub-components might change or become obsolete which will affect your design, and otherwise attempt to envision the entire path from inception to completion of the life-cycle of the design. 

We can't emphasize this step enough.  A locally good choice for a specific chip that solves a major portion of your product's problems may look great but what if it is only available for a few more months? What if the cost of that same chip is fine if you are only building 10 units but if you want 1,000,000 it becomes prohibitive?

This step takes some experience and group thinking to really get right but it can have huge dividends down the road.  It is also the first thing cast aside when rushing designs to market or doing incomplete product design.  Like many things, the preparation is much harder than the actual process and the outcome is at risk if the preparation is incomplete. 

Design

Now is the time to use tools.  Whether visualizing mockups, building prototypes, or modeling the product in software, you need to complete a thorough design before pursuing the actual development.  If the design is done in a team setting, you need everybody to see the entire plan and all the details to get a collective vision.  Prototypes and mock ups help some people involved.  Implementation details should be fully specified. 

Often a good design ends up looking like an instruction manual for the final product.  Someone reading this should see clearly how you are going to accomplish every sub-component, how they all interrelate, and the design must go beyond just the product itself.  How will it be supported? How will it be manufactured? How long will it last? How will people responsibly dispose of it when done? Can it be upgraded?

Design documents start at this step but they don't end here.  With each subsequent step, the design should be updated, refined, and should reflect all lessons along the way.  Ideally, this is in some sort of journal form so that not only is the outcome clear, the steps, mistakes, and learning is captured along the way. 

Designs need to clearly dictate what is critical and what is not.  A machinist would call this providing clear tolerances.  Does it have to be a 0.1uF +- 1% ceramic capacitor or can it be something "like" that? This may be clear to you but if you send vague information to a teammate, supplier or sub-manufacturer, they will likely error on the side of caution and possibly work way to hard (time and money) to fulfill your request without proper specification. 

Again, you need to pursue projects as though at any moment you may get moved to something else and you will be held responsible for how easily someone else can step in and finish your work.  A good design document would readily fulfill this goal because of the detail, clarity, and capturing of the process as it evolves. 

Really thinking through the design makes the remaining steps much easier and easily divided amongst teams, individuals, or even sites to accelerate development.  The time spent here is won back many times over in the product life cycle. 

Develop/Test/Debug

This step looks something like the instructions on the back of a shampoo bottle...  lather, rinse, repeat.  Often a massive amount of insight is gained with a rapid prototype at this stage.  Corners are cut, expensive or existing sub-systems are used in-place of designed solutions to rapidly mock-up a functional product prototype.  Most of this work will be tossed but all the learning will be employed in subsequent designs. 

The number of cycles at this steps is completely dependent on the product or project.  Some can be fleshed out in a single pass.  New, innovative designs may require many, many passes to learn all the angles, try alternatives, and resolve challenges discovered along the way. 

Again, it is very important to capture in documentation, video, and any other convenient and accessible media not only the outcome of this repeated develop/test/debug steps, but the actual process, steps, mistakes and discoveries made along the way.  Remember, someone else may need to replace you in this project and it would be a shame if they simply recreate your previous failures rather than build on your successes. 

Evaluate/Conclude

By now you have a product...  but you are nowhere near done.  It is often difficult to absolutely reach the goal set out at the beginning.  If you are trying to advance things, in some ways, you want to always narrowly miss your goal as that ensures you are putting the bar just high enough to encourage the most progress in your work.  In this step, you need to evaluate...  again with documentation how close you are to achieving the goal stated at the beginning. 

Often, you nail the design but the cost ends up being higher than you thought or the product is more costly to build than you expected.  You may have been trying to achieve a particular percentage efficiency but missed it due to an unforeseen friction component.  These misses are good...  as long as you document them and explain the reasons.  Future products may build on your work and focus on these areas to make your design "go from 10 to 11". 

Package/Document

How are people going to receive your project or product? Is it a large, heavy robot that requires a crate? Do you have clear, concise documentation that accompanies the product so people can get started? These are the questions and issues that need to be isolated and handled at this step. 

While the excitement of getting the final project/product to work is over, you must absolutely nail this portion to avoid suffering adverse initial reactions to your work.  If it arrives broken or in shabby packaging, it impacts how your product is received.  If a customer spends a good deal of money and they get a functional product but can't figure out how to use it, does it work?

Consider your own experiences.  Sometimes an inexpensive choice at the checkout aisle becomes very costly in time or patience as you await a response from tech support "trouble tickets", wade through automated voice mail systems only to be given a person who reads the website information in a "script" back to you, or the item is broken upon receipt. 

This step requires a new perspective...  that of someone who is completely unfamiliar with what you have spent night and day laboring over.  You get it cold...  the person you hand it to has no clue.  Give them one. 

Demonstrate

OK, you did it.  You built what you said you would....  or at least approached it.  Now, while you may be super tired of the outcome due to the challenges and time spent, now is the time to clean things up (including yourself) and get out there and demonstrate it. 

The new widget may be commonplace to you by now, due to exposure, but if it is innovative and advancing things, others will be very excited to see it.  In academic circles, conferences offer this opportunity.  In companies, road shows, interacting with customers (yikes), and doing sales and pre-sales are great ways to accomplish this. 

This step can be tough for engineers.  The work is done, new projects are kicking around in your head, and we are not the most outgoing lot as a whole.  That said, if you don't see the reactions, hear some of the initial criticism, and show your efforts, you can never improve for the next round.  You also really need to hear how it is received to better adjust your hypothesis for future designs. 

Don't design in a vacuum. 

Record Sources

In an academic paper, you put together a bibliography at the end in most cases.  This sites and accredits all others work you are building on.  In a company setting, this may not be required but it is essential for future benefit.  What website did you find the definitions on? Where did you find the 3 sources that let you to select a particular chip in a design? What software sub-components did you use and how can you track the improvement of them to incorporate?

Just like in writing your academic paper.  This step is hard to get right and takes discipline.  It is 3am, the paper is now 22 pages as required, and you are tired and wanting to go to sleep.  Just siting 10 sources with a Google search does nobody any good.  You need to look back over your well-organized notes and journals (if you are sticking to the system) and put this list together comprehensively.  It is the final icing on the cake and it again allows future work to build on your efforts. 

That's it.  These steps mirror how movies are produced, architects build houses, iPhones are developed, and robots are built.  In all cases, an effective leader likely follows similar steps.  When asked, these leaders also will likely reflect on how early efforts didn't follow these steps and experience has shown how much more effective people come when they follow this discipline. 

The most likely first attempts involve very little planning and serious disappointment along the way.  Maturity, discipline, and experience will likely lead to a much more structured approach and vastly better results. 

Follow these steps and you will skip many unnecessary intermediate "learning moments". 

This document is like the process itself.  It is at the develop/debug/test stage and may always be there.  With each project, we try to reflect on this as part of our conclusion and make sure we aren't missing a step along the way.  Let us know if you feel something is missing.  We will add you to the bibliography!

Revision History:

• 2009-01-06: Initial Article Posted
• 2009-01-06: Removed superfluous soapbox (thanks Art)

Related Links:

Main page for the University of Oregon Winter 2009 407/507 course