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
Reference
1. Rosenthal, SB, "It takes more than technical skill to
consult in the embedded market," PE&IN, Feb 1998, pgs 64-65.
Adapted from an article that appeared in Personal Engineering & Instrumentation
News.
Return to the article index.
|
