design cycle estimate

Guys,

I need your help with political sort of problem. I am getting pressure from 
marketing on timeline for product delivery that looks to me quite 
unrealistic. Has anybody seen some kind of publication discussing design 
cycle for embedded product and giving some inputs that would allow to deduce 
rough time estimate for development? Of course I know how long it will 
really take but this (obviously) doesn't count :(
Generally speaking the product is an embedded box having some MCU and DSP on 
board doing our proprietary stuff. It will also have some lcd, keypad, 
various I/Os. We are to design PCBs as well as embedded SW.

Thanks all
Mike 

Mike_33 wrote:
> Guys,
> 
> I need your help with political sort of problem. I am getting pressure from 
> marketing on timeline for product delivery that looks to me quite 
> unrealistic. Has anybody seen some kind of publication discussing design 
> cycle for embedded product and giving some inputs that would allow to deduce 
> rough time estimate for development? Of course I know how long it will 
> really take but this (obviously) doesn't count :(
> Generally speaking the product is an embedded box having some MCU and DSP on 
> board doing our proprietary stuff. It will also have some lcd, keypad, 
> various I/Os. We are to design PCBs as well as embedded SW.

Are you writing code for a working board, or do you need to debug 
hardware too?

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

Mike_33 skrev:
> Guys,
>
> I need your help with political sort of problem. I am getting pressure from
> marketing on timeline for product delivery that looks to me quite
> unrealistic. Has anybody seen some kind of publication discussing design
> cycle for embedded product and giving some inputs that would allow to deduce
> rough time estimate for development? Of course I know how long it will
> really take but this (obviously) doesn't count :(

Hmmmm.... a tough one.

I don't know how to get through to managment with these things,
but you could set up a prior estimate for the plan. Use something
like MS Project, set up the different stages and the time required,
staff needed, the critical path and all that.

That way, you might have a chance to communicate your points
to whoever, in *their*own*language*. If I have learned anything
the last few years, it is that getting a message across, depends
99% on the message being conveyed in the *recipients* language
or form, only 1% on the contents.

Even if you don't succeed in getting your message across first time,
you might have a better starting point for the next project --
provided,
of course, that your estimate hits to within a reasonable degree.

Of course, there may be all sorts of risks asscociated with this
sort of approach ("trying to take over the boss' job" etc), so
play this one very carefully, whatever you decide to do.

Rune

Mike_33 wrote:

> Guys,
> 
> I need your help with political sort of problem. I am getting pressure from 
> marketing on timeline for product delivery that looks to me quite 
> unrealistic. Has anybody seen some kind of publication discussing design 
> cycle for embedded product and giving some inputs that would allow to deduce 
> rough time estimate for development? Of course I know how long it will 
> really take but this (obviously) doesn't count :(
> Generally speaking the product is an embedded box having some MCU and DSP on 
> board doing our proprietary stuff. It will also have some lcd, keypad, 
> various I/Os. We are to design PCBs as well as embedded SW.
> 

Any technical argumentation is not useful in that kind of disputes. 
Pretty much all you can do is this:

1. Make a clear point of yours.
2. Surrender to the pressure.
3. After the fail, don't say "I told you that".

VLV

Vladimir Vassilevsky wrote:
> 
> 
> Mike_33 wrote:
> 
>> Guys,
>>
>> I need your help with political sort of problem. I am getting pressure 
>> from marketing on timeline for product delivery that looks to me quite 
>> unrealistic. Has anybody seen some kind of publication discussing 
>> design cycle for embedded product and giving some inputs that would 
>> allow to deduce rough time estimate for development? Of course I know 
>> how long it will really take but this (obviously) doesn't count :(
>> Generally speaking the product is an embedded box having some MCU and 
>> DSP on board doing our proprietary stuff. It will also have some lcd, 
>> keypad, various I/Os. We are to design PCBs as well as embedded SW.
>>
> 
> Any technical argumentation is not useful in that kind of disputes. 
> Pretty much all you can do is this:
> 
> 1. Make a clear point of yours.
> 2. Surrender to the pressure.
> 3. After the fail, don't say "I told you that".

You left out "update your resume".

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

Jerry Avins wrote:

> Vladimir Vassilevsky wrote:
> 
>>
>> Mike_33 wrote:
>>
>>> I need your help with political sort of problem. I am getting 
>>> pressure from marketing on timeline for product delivery that looks 
>>> to me quite unrealistic.
>>
>> Any technical argumentation is not useful in that kind of disputes. 
>> Pretty much all you can do is this:
>>
>> 1. Make a clear point of yours.
>> 2. Surrender to the pressure.
>> 3. After the fail, don't say "I told you that".
> 
> 
> You left out "update your resume".


As long as you don't say the magic words "But I told you", you are 
probably OK.

And what is your solution, Jerry?

VLV

"Mike_33" <michael.shklyarman@bioscrypt.com> writes:

> Guys,
>
> I need your help with political sort of problem. I am getting pressure from 
> marketing on timeline for product delivery that looks to me quite 
> unrealistic. Has anybody seen some kind of publication discussing design 
> cycle for embedded product and giving some inputs that would allow to deduce 
> rough time estimate for development? Of course I know how long it will 
> really take but this (obviously) doesn't count :(
> Generally speaking the product is an embedded box having some MCU and DSP on 
> board doing our proprietary stuff. It will also have some lcd, keypad, 
> various I/Os. We are to design PCBs as well as embedded SW.

1. Does your company have any previous "actuals?" I mean previous
projects in which any part would be similar to the current project
that could be used as an estimate or basis. This is probably the best
way to open management's eyes.

2. Can you identify any particularly complex or time-consuming task
specifically enough to break it into documentable, believable steps?

This really depends on the managers you're working with. Some people
won't listen to reason no matter what, some are very reasonable, and
some are in between.
-- 
%  Randy Yates                  % "She's sweet on Wagner-I think she'd die for Beethoven.
%% Fuquay-Varina, NC            %  She love the way Puccini lays down a tune, and
%%% 919-577-9882                %  Verdi's always creepin' from her room." 
%%%% <yates@ieee.org>           % "Rockaria", *A New World Record*, ELO   
http://home.earthlink.net/~yatescr

Vladimir Vassilevsky wrote:
> 
> 
> Jerry Avins wrote:
> 
>> Vladimir Vassilevsky wrote:
>>
>>>
>>> Mike_33 wrote:
>>>
>>>> I need your help with political sort of problem. I am getting 
>>>> pressure from marketing on timeline for product delivery that looks 
>>>> to me quite unrealistic.
>>>
>>> Any technical argumentation is not useful in that kind of disputes. 
>>> Pretty much all you can do is this:
>>>
>>> 1. Make a clear point of yours.
>>> 2. Surrender to the pressure.
>>> 3. After the fail, don't say "I told you that".
>>
>>
>> You left out "update your resume".
> 
> 
> As long as you don't say the magic words "But I told you", you are 
> probably OK.
> 
> And what is your solution, Jerry?

An escape hatch. Preferably to a firm that doesn't let marketing 
override engineering judgments. It doesn't matter that you told them and 
that you don't tell them you told them. In the end, it will be judged to 
be your failure.

Never say the schedule can't be met. Detail the resources needed to meet 
it. If those resources aren't provided, you'll be in fairly well 
positioned. If they are and you fail anyway, look out.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

Mike_33 wrote:
>
> I need your help with political sort of problem. I am getting pressure from
> marketing on timeline for product delivery that looks to me quite
> unrealistic. Has anybody seen some kind of publication discussing design
> cycle for embedded product and giving some inputs that would allow to deduce
> rough time estimate for development? Of course I know how long it will
> really take but this (obviously) doesn't count :(
> Generally speaking the product is an embedded box having some MCU and DSP on
> board doing our proprietary stuff. It will also have some lcd, keypad,
> various I/Os. We are to design PCBs as well as embedded SW.

This article on Embedded Agile

http://www.ddj.com/dept/architect/193501924

talks about some tools/methods purported to be industry standards. I
have no prior knowledged of these tools. You might have to investigate
their specific merits yourself, but it is a starting point!

Apart from the suggestions others have given, the method I have used in
the past is to come up with what you *can* do in the given timeline.
This would be a subset of the full product of course. You can sacrifice
basic features or nice-to-haves. If you sacrifice testing you need to
identify the risks. And so on.

Good luck.

C

Jerry Avins skrev:
> Vladimir Vassilevsky wrote:
> >
> >
> > Jerry Avins wrote:
> >
> >> Vladimir Vassilevsky wrote:
> >>
> >>>
> >>> Mike_33 wrote:
> >>>
> >>>> I need your help with political sort of problem. I am getting
> >>>> pressure from marketing on timeline for product delivery that looks
> >>>> to me quite unrealistic.
> >>>
> >>> Any technical argumentation is not useful in that kind of disputes.
> >>> Pretty much all you can do is this:
> >>>
> >>> 1. Make a clear point of yours.
> >>> 2. Surrender to the pressure.
> >>> 3. After the fail, don't say "I told you that".
> >>
> >>
> >> You left out "update your resume".
> >
> >
> > As long as you don't say the magic words "But I told you", you are
> > probably OK.
> >
> > And what is your solution, Jerry?
>
> An escape hatch. Preferably to a firm that doesn't let marketing
> override engineering judgments.

Very hard to find, but they do exist.

I know this might seem out-of-this-world for some, but I *have*
been involved in projects where the client asked "help us
find out whether or not this can be done", as opposed to
"we are in the year 2006 and it's about time this problem is
solved, you do it!". The former kinds of clients are rare (I must
admit I know of only one), but they do exist.

> It doesn't matter that you told them and
> that you don't tell them you told them. In the end, it will be judged to
> be your failure.

Indeed. Basically, you either have to surrender to the pressure,
or leave.

There is the argument that "a coorporation where incompetent
management drive off the competent engineering staff will lose
in the marketplace", but I can't really see how that can solve
anything in the short term. Such companies would go bust
after some time, but that might actually encorage the
competitors that what *they* do -- the same thing -- is correct.

This is the ancestor to Catch 22.

> Never say the schedule can't be met. Detail the resources needed to meet
> it.

Resources or reorganization. Can stuff that is done manually
today be automatized? What about red tape, are reports and
documents handeled by several people? Are products
documented in separate stages, or is documentation and
reports generated as part of the basic activity?

Know your tools. Know your work.

My experience is mainly from low-tech areas (i.e. people *use*
the technology rather than *produce* the technology). In these
applications the way people deal with papers and red tap is
what slows the process down. The "big toys for the big boys"
are used and handeled pretty efficiently; it is all those seemingly
trivial details that take time: Somebody writes a log, somebody
else copy those numbers for a report, some third person cuts and
pastes the same numbers from the report to a database. These
sorts of things seem trivial and cost "almost no time and work"
when viewed isolated, but it's like sand ind the machinery: One can
absorb the wear and tear by a few grains, but as they add up and
work over time, they grind down the works. None of the individual
"grains" are large enough to case concern in their own right,
but somehow, they bring the system to a halt if there are too
many of them around.

It's like ordering plane tickets on the internet as opposed
to in the travel agency: On the net, you do it yourself when
you need the tickets. Previously, you needed to wait until
opening hours for th etravel agency, wait for some clerk
to become available, and then spend some time explaining
those particular details about staying one extra night in
in that city close to where your meeting is.

> If those resources aren't provided, you'll be in fairly well
> positioned. If they are and you fail anyway, look out.

Agreed.

Rune