Tell us about how you approach a project with a customer.

We’ve been through this process many times and laid out a series of steps to take to ensure a successful project. The first step of the process is to determine who the customer is.

How is the customer defined?

We define our customer as the person or group that will receive and utilize whatever it is that we have been asked to produce. For example, in a large company where we are providing software drivers to support a large software effort, our customer may be the group building the next higher layer of code. In a test-prototype environment, our customers may be the hardware group trying to find out if the hardware is working.

For smaller customers, the client and the customer are often one and the same. But even in small companies, our work will often be transferred to another person or group to be re-packaged before heading out to the ultimate end user.

Why is it important to define the customer?

In a recent project for a small company, the President and the Chief Technical Officer didn’t always agree with each other about what the ultimate project would look like. This type of disagreement is common, because if two people always agree with each other, one of them is redundant! We’ve found that the best way to resolve this type of inconsistency is to get all the players in the room at the same time, point out the differences, then let the clients resolve the issues together. When we agree on who the customer is, it's more obvious to everyone what the project should include.

What do you do if your customers are not sure what can be implemented?

We pride ourselves on being experts in automation technology and electronics. It is a mistake to let this pride get translated into arrogance. Our customers may or may not be computer literate, but they are all the experts at what they do. We will help them determine what can be implemented at a reasonable cost, without expecting them to take the time to learn everything about what we do.

Does this make Automation Engineering Group different in the way it treats its customers?

Yes! We’ve been in enough different manufacturing and industrial environments to realize that we aren’t, in fact can’t be experts in everything. We count on our customers to be experts in their fields, and treat them with the respect due any expert that we’re trying to learn from. Our customers are usually busy, competent people who know what they want to do, but not how to do the computer part of it. That makes us a good match for each other.

What really makes us different is the principles we use to guide us as we approach projects. Those principles are that we are financially conservative, motivated by being effective, and respectful of our customers' position as experts. Also, we will research the best solution for each situation, be candid if we don't have the answer for a given situation, and take pride in seeing our services help our customers succeed. I don't know any other automation company that has distilled this customer respect in quite the same way.

What if a project is ongoing and just needs a little extra staffing?

We understand that different customers have different needs. Large companies with well established internal technical capabilities often need extra manpower for short bursts of activity. For these customers, we provide highly skilled, motivated professionals that are easy to instruct and manage. For smaller companies, we can act as a "part-time" engineering group, performing all the functions of a staff engineer, but on a part-time, as-needed basis.

How can you help if a project is not yet clearly defined?

Often, assistance is required to specify and define a project. We are skilled at defining the project and what will be required to complete it. For these customers, we can provide a detailed analysis of the project, along with estimates for each phase of the project. If the project is experimental in nature, we often build review points into the schedule. These points serve as milestones so that progress can be monitored and the project revised if the experiment is not working out as anticipated.

How do you begin to define a project?

Requirements gathering can be one of the most important parts of the project development process. Although both the customer and engineer are intelligent and experts in their own field, each has their own vocabulary and assumptions that sometimes interfere with accurate communications.

What is the first step to gather these requirements?

The interview is our most effective way to establish common vocabulary and transfer data from the experts to our designers. There isn’t just one interview, but several, each getting finer and finer detail from the customer.

The initial interview is often hidden in contract negotiations and project scope definitions. We separate these "business" discussions from the "technical" discussions when possible. This avoids wasting time, yet helps us to be sure we have the right people in the room for each type of discussion. All the major players should participate for the initial interview. This often means that the person paying the bills, the person managing the project and the person who has to go out and sell the end product are all in the room. They discuss, in broad brush strokes, what the product will look like to the end user, what its capabilities are and what the price targets are. The designers direct the conversation to extract information like interface specifications (what does the device connect to and interact with), processing power requirements (like, does it run on a AAA battery) and operational overviews (what will it do).

What do the designers do next to determine feasibility?

The designers then go off and research the requirements. Often, phone calls or emails are required to clarify issues raised by the research. The interview process can go through several iterations.

Is the project a ‘go’ or ‘no go’ at this point?

At the end of this process, we present a proposal for acceptance outlining what will be done, what will be delivered, what we propose for the pricing and the schedule.

What happens when work begins?

We start with building models. A software model is like the models other engineers build. For example, a bridge engineer might build a scale model of a bridge being designed to see how it looked, how it performed under simulated loads and other details. Software engineering also involves building models.

How do you begin the model building process?

We work to get a picture of how the software or hardware should behave, what we want it to do if this or that happens. The method we use is to define each state of the system on a notecard. The notecard contains the name of the state, and any defining characteristics of the state (such as TURN ON RED LIGHT, or DISPLAY "PRESSURE: x.xx mPa"). No specific detail is mentioned on the card (such as which I/O turns on the red light), but enough so that the customer will understand what the system is doing. When a stack of notecards is prepared, a meeting is called with the customer.

What happens at the customer meeting after this picture of system performance has been sketched?

This meeting will define the early design of the system. It is critically important that the customer be fully involved in the decision making at this stage. Anticipate an all-morning or all-afternoon meeting to define the state machine and make sure we will build the right product!

We tape the cards up on a large whiteboard, usually starting with some known state (like power-up or cold-start). The transitions between states are drawn on the whiteboard between the cards. At the end of a session (2 or 3 hours), the whiteboard is filled with states, events and transitions. This will form the basis of the final design.

How can you tell when the design is complete?

We believe that design is never actually "finished". At some point, however, we must agree to stop improving the design so the project can be delivered. We try not to place a deliverable further out on the schedule than six months. We have found that when a design becomes finalized, the temptation to change it become unbearable when the deadlines are further away than six months. Either the market changes or the project definition is "tweaked". When the deadlines are shorter than six months, any scope changes can be put off until the initial project is completed.

What does the customer see coming back to them after this design stage?

We feel it’s important to get prototypes into the hands of the customer as quickly as possible. This is especially true if the customer has not been through the development process before, or is unsure of what the project outcome is going to be. Just like models, prototypes can show that segments of the design are going to work. Better to find out early that a design isn’t meeting expectations than to realize this at some later date when changing the design will impact schedules.

If the project is purely software, we try to prototype the user interface quickly. Often, this leads to changes in the specification as the customer realizes that what was thought to be a desirable feature doesn’t work out as planned.

When the prototype is done, isn’t the project done?

Prototyping is usually done by breaking the project into small pieces that can be developed and tested individually. If there will be a user or operator interface, we prototype that as quickly as possible, getting it into the customer’s hands quickly so it can be analyzed while the hardware is being designed. We often use Windows or DOS to prototype user interfaces, even though the actual hardware may not be a PC. This allows for a quicker project path overall.

What other prototype pieces might there be?

We prototype everything. The user interface is only the beginning of the prototypes, usually because customers have a clearer vision of what they want the user/operator to see than they do of much of the rest of the machine. For projects that require some hardware design, for example, we often prototype that separately. This way we can get prototype hardware into the customer’s hands as quickly as possible, even if we know it’s not the final version. The customer often comes up with additional requirements ("it must fit in this cabinet", "that’s got to be a 250 Volt motor now") when the prototype hardware becomes available. Just as with other design changes, it’s better to find out early in the process that a change is needed, rather than making frantic changes as the project is being shipped out the door.

What if changes or improvements are suggested later, after this point is reached?

We understand that many customers are hesitant to call a project "done", when design changes are still occurring. This is a fact of life that doesn’t bother us. Our process is flexible enough to accommodate change. For us, a project is done when the customer accepts ownership of the project and no longer requires our assistance in either project updates or manufacturing.

What kind of documentation do you leave with a customer?

We prepare the customer documentation in whatever format they require for their own internal needs. We recommend readily transferable formats such as Microsoft Word, Adobe PDF and Orcad. Document preparation is part of the project, and we don’t consider ourselves finished with a project until enough documentation is in place to pass all development and maintenance responsibilities to the customer, even if this is not part of the original contract.

How long do you keep records if additional work on a project is requested years down the line?

Records and documentation are maintained indefinitely. We could revisit 15-year-old projects and be up to speed on new development requirements in a matter of weeks.

We’ve been in this field as a company since 1989 and we intend to continue to deliver success to our customer for a long time to come.