Freezing requirements in embedded product development

I work on the basis that every problem identified (including the fact that the spec is fuzzy) is noted on a problem report form (one problem per form). This is reviewed and, if it leads to a change proposal that is evaluated for programme and cost impact. If the change is agreed for inclusion then it gets added under a written work order and a review ensures that it was implemented as stated. The only question about whether a problem report leads to a change proposal is whether the problem is a simple case of not reading the clearly written instruction manual for the product (if the manual wasn't that clear then that is the problem to resolve).

All this helps engineering remain truthful and up-front for the customer so that he has the facts about the impact any change might have on cost, lead-time and quality of product. A certain amount of controlled change during development is good. Uncontrolled change will, however, always be very very bad.

As I have stated often before (mostly in this forum) make the spec firm quite early and get the customer to sign up for it (which they will do if you demonstrate that it captures their requirements properly and provides the solution they seek). make the specification document part of the contract with the customer but be amenable to change provided the customer understands the cost/benefit ratio any change will impose.

If you have a requirements document for this portable product, that you are trying to cobble together, begin a component performance selection table. If you can show that none of the pre-exisiting components meet the requirements then the customer can either relax the requirements (under properly controlled contractual changes) or you get to select from a different pool of components that would enable you to meet the requirements on all fronts.

Now I have no idea what you are talking about. How is honor an issue if I am working on a program that gets canned because they are starting with an impossible approach?

I don't see a lot of options at this point. In order to get another job I would have to do a much longer commute and I am not willing to do that. So I will do the job as best I can and not worry about whether the job ever produces anything of value. Let's face it, there are tons of jobs that although they produce products, they produce nothing of value in the real sense.

You are in way over your head on this one. This is a huge program involving multiple defense contractors and literally hundreds of millions if not billions of dollars. There is pretty much nothing I can do to change the course of the program in any way other than the small part I am working on.

Heck, I tried to simplify one of the parts I *am* working on and got my head handed to me. This board uses 6 RF relays to select filters. I suggested that we did not need an MCU to control the relays since the MCU can't directly drive the coils and the relay driver chips can be directly controlled over the same SPI buses that they want to use to talk to the MCU, not to mention that there is little room left for the control circuitry. All they had to do is put the "intellegence" into the DSP or 32 bit processor on one of the other boards. This "intellegence" is a lookup table to translate the mode into the relay settings. Sounds pretty simple no? They called a special design meeting to discuss this, the prime contractor started asking lots of questions about it and things got very heated. I caught most of the heat. So I said I could squeeze in a small MCU that can support the three SPI ports needed and a CPLD for the discreet logic required rather than just using about 8 very tiny CMOS logic chips.

In the grand scheme of things this decision is not very big, but you can see why there is little hope for my changing much on this program.

I have known for a long time that when you work in defense you don't make waves (unless you are testing a new ship hull). No one wants you to be the most efficient, including the customer. Everyone is in it to keep their job and maximize their salaries (including the government people). It is up to the government to set up a system that maximizes benefit to the goverment while all this is happening. This is no different from any other business, the government is just less effective at setting up the right environment.

As to the issues about the portable performance, that is being addressed, but in the usual inefficient and ineffective way. Some of us think this will result in the portable being cancled, but not for maybe another year...

Try this, some find it helpful:

See ya, Dave

Also treat the documentation as a project deliverable: factor in the cost of doing it right, and test it. That is, get someone who is technically literate, but otherwise unfamiliar with the project at hand, to read it, & submit a critique. If the reviewer can't understand it, neither will the maintainer in a year's time.

rickman wrote: [snip]

Given the outcome of that new Coast Guard ships procurement, I doubt they made enough waves...

Hello ,

If the customer changes his requirements, please note that the scope is changed. When scope is changed, everything gets changed and you can suitably charge your customer for the additional work! There should be a provision in your contract for doing this!

Yes, this is the traditional approach of a matrix organization! If the organization is projectised, this problem can be avoided. You have lots of problem in completing a project in a functional organization, as the functional managers will have more power that the project managers. All the organization is working towards addressing their customers problem in the form of project and a project has a duration, budget, scope! Who is going to manage all these, ensuring that the quality is maintained? Its the Project Manager!! It is essential that a person with technical background with other skills - Business, Management, Finance should takeup this role! Then the Project Manager, will know these were the problems faced by his boss when he was a team member!! and he will ensure that the past mistakes done by his boss are not repeated! Also, you can gothrough PMBOK (Project Management Book of Knowledge) from PMI, which is written by more that lakhs of people. PMBOK contains the reality of life! The best practices followed in successful organizations! This problem is faced by many people across the world, and some have solved it! Only thing is, we have to accept the solution - this involves change in culture!! The way we do things!!

Best Regards, Vivekanandan M

Hello ,

You are under illusion! Have you ever tried asking questions like why do you want to do this, how you are currently doing this, what is the benefit you get by doing this, etc...?? If you ask such questions, the answers will come out from the customers mind, you as a project manager should capture it!! If you have not asked/bothered to ask questions, you are under illusion and start complaining customer is changing the requirement!! Do you think the customer is a fool? When he has a problem, he approches experts! As experts you should talk to him understand and then goahead. Imagine yourself as a customer, you want to buy a embedded systems book. After going to a bookshop will you change your mind to get a book on management, as a customer, you are clear on what you want! As a vendor you should know completely what your customer wants and how you will deliver! Imagine you are sick and go to a doctor. If the doctor does not ask you any question and gives you medicine!! Same is the case here!

There is a problem in your organization structure! Your senior managemen/top management will takecare of this, provided you give feedback!! Things are changing!!

Your organization style is functional!! It definitely require changes if you want to survive in the market!! I will ask you a question - Your customers want things to be done at cheaper cost, your management wants high ROI, team members want good technical work (for their career) and increase in pay, who will handle all this? Do you notice how cost plays a very important role here!

Best Regards, Vivekanandan M

"rickman" writes: [snip]

One of the problems that occurs with government projects is that it takes a little short of forever to get approval of changes. You get into cases where everyone agrees that a change would be good but it isn't worth the hassle of getting it approved.

The worst-case scenario for this is the Defense Communication Agency which is subordinate to all three services. Approval of anything requires getting the Army, Navy, and Air Force to agree, a near impossibility.