SLTF Consulting
Technology with Business Sense

 Home | Bio | Contact Us | Site Map


Consulting in the embedded world requires diplomacy

Scott Rosenthal
April, 1998

My last column (Reference) identified three key ingredients for achieving success as an embedded-systems consultant: product, customer and you-in that order. Many technologically adept people make the mistake of entering the consulting arena without understanding basic business practices such as schedules, budgets, marketing and customer capabilities. This approach will sink you as well as your customer. Further, without knowing your limits-whether technical, financial or the ability to stick to a schedule-you're again relying on a recipe for disaster. To help avoid a tragedy, this column examines the customer and then finishes with some tips on how to become a good consultant.

The customer

In my last column, I addressed customer expectations. This month the focus shifts to the customer himself. In a nutshell, all customers are different. This statement is simple but extremely important to remember when dealing with a prospective client. What works for one person might backfire with another. You need to solve a technical problem as well as satisfy some need that makes the customer feel better, too. That customer wants to feel important. This can be accomplished in a number of ways including:

  • sharing technical ideas,
  • keeping the customer informed about little successes during development,
  • faxing him articles of interest,
  • staying in contact with him throughout the entire design process.

Remember, there's no universal approach. You must find a technique that works for a particular individual and keep doing it, even when the project encounters tough times.

Creeping featurism

Even with constant communication, customers can create their own brand of problems. For example, I'm sure that you've all experienced creeping featurism where a client adds features to a project to satisfy some inexplicable need. In my experience, every customer falls prey to this in some form or another, especially on the software side. With hardware it's easy to explain production cost for new features. But with software, that cost might actually be zero, so some customers don't always understand the true cost of changes. Your choice as an embedded-systems developer is to decide how to handle these additions.

Knowing in advance that customers will want to add features to every product, you've got a choice: either code defensively for new features or ignore the future. I prefer the former. So how do you code defensively? Probably the easiest way is to ensure that every new feature fits in with existing code. For example, if a system has a simple display device with a menu, make sure you can easily add new selections. If a system works with multiple sensors, make it easy to add more sensors with minor software changes.

An often overlooked technique for controlling creeping featurism is to talk with the customer. Nine times out of ten, he has no idea what a change to embedded software entails. The comment I always get is "What I think is easy turns out to be difficult. What I think is difficult tends to be easy." Remember, you're the expert, not the customer. Help him understand the tradeoffs needed for every new feature. If a feature will be really onerous to insert, discuss alternate ways of implementing it.

Another option the customer has is to not add the feature if it causes undue burden on the software. I view existing software as a corporate asset. As with any other asset, you're always trying to protect its value. If a feature threatens to turn some software into a plate of spaghetti, inform the customer of the future ramifications of spaghetti code. Most customers appreciate such candor.

Changes cost money

A great customer understands that all changes cost money. For example, if I must change an error code from 20 to 15 in the software, it might involve the following steps:

  • Check the source code out of the configuration-management system.
  • Find the location in the code.
  • Change the source code.
  • Compile and link the revised code.
  • Burn a ROM or microcontroller with the new code.
  • Verify that the change works.
  • Check the source code back into the configuration-management system.
  • Correct any project documentation that might be dependent on this change.
  • E-mail the new binary file, source code and any doc to the customer.

As you can see, this list becomes extensive even for a small change. Each step takes time. An ordinary customer won't understand, nor care, about the steps involved. To him, it's a "simple" modification, just a change in a single number.

You, the expert

Now it's time to examine your role in this process. In my last column, I stated that the best thing a customer can do is to tell me what the product must do and not how to accomplish the what. If the customer's requirements aren't clear, there's no way anyone can successfully complete the project. The customer must focus on what the product must do and let me concentrate on how to implement the intended functionality.

Typically, the ordinary customer tries to micromanage how-the development process-without letting on as to the what's driving the project. This scenario involves running all technical decisions by a non-embedded systems manager who doesn't understand the technology and wants results at little cost. My advise is to steer clear of these types.

Even if you have customers that take a hands-off approach during development, they still look at the end result. A funny thing happens when you embark on the embedded-systems consultant route-all of the dirty laundry in your design is now available for everyone to see. Now consider some of the repercussions:

  • A customer might reject a project if a comment line has a misspelling.
  • He might insist on changing the name of a source code file.
  • He might ask for changes in variable names.

In each of these cases, a customer is getting into the hows. But because he considers this code part of the project deliverables, he might feel that he has a right to these ideas. But if you keep your code clean, you provide fewer targets for criticism. Remember that someone will review everything you deliver to a customer. These people will not only look at it but scrutinize it for two reasons: First, because your services cost more than a typical engineer's weekly salary, people tend to carefully review what you deliver to make sure they're "getting their money's worth." Produce professional-looking code and documents. Second, people sometimes search for faults in the "expert's" work. Not everyone strives for the best product. Some employees of the customer will feel threatened by you and might work very hard to discredit you.

Further, documentation represents some of the most visible fruits of your efforts, so comment code extensively and create good documentation to support a design. The product isn't yours-it belongs to the customer. Therefore, produce something that others can work with. Your security with the customer depends on keeping him happy and satisfied and not in hiding the details.

Probably the most important thing I've learned in this business is to make sure that the project scope is extremely clear to all parties. Know your responsibilities, know the customer's responsibilities and resolve as much as you can up front. Both you and the customer must know how to handle the issues that always come up, including inevitable project changes. Bring up this topic at the beginning of your relationship before signing contracts or accepting purchase orders. PE&IN


1. Rosenthal, SB, "It takes more than technical skill to consult in the embedded market," PE&IN, Feb 1998, pgs 64-65.

About Us | What We Do | SSM | MiCOS | Search | Designs | Articles

Copyright © 1998-2014 SLTF Consulting, a division of SLTF Marine LLC. All rights reserved.