This page discusses methods to improve the Non Recurring Cost of a project, usually at the expense of the other priorities.
Definition: Non Recurring Cost is the sum of all the development costs - engineering, subcontracts, setup fees, rentals, and breadboards and other use to destruction hardware. Sometimes some capital equipment is costs are loaded on to programs, but this is not common. This is generally tracked using a Work Breakdown Structure, and expenditures are reported on regularly.
Non recurring costs may be presented in dollars, or in man-hours + contract fees. Man-hours are more intuitive, and are used more often in engineering environments.
First, see this article: Practical Techniques for Beating a Schedule and Budget
Since Non Recurring Cost can be used to improve performance of Schedule, Technical Performance, Process, Specification and Recurring Costs, it is clear that any technique to reduce Non Recurring cost will probably affect one of the other characteristics negatively.
If the Non Recurring Cost (NRC) is the most important priority, you have to be ruthless about wrapping up at the end of your expenditure. Too early, you leave in too much risk. Too late, you overrun.
For instance, If you are contracted to perform an engineering service - say write a large software application - then you have to come in under the NRC budget, every time, or your company will go under. To do this, you must keep the scope front and center, and track customer requested changes. Most engineering departments will accept a "Proceed and Quote" process, and negotiate the cost as the work progresses to minimize schedule impacts. But most times you work to the spec, until the changes are received formally. Make sure you know which.
If the NRC is the top priority, better hope that your have a low Resource Constraints requirement. When I ran big jobs that had tight NRC budgets, I turned over about 25% of the people in the first few weeks, either replacing them, or changing their assignment. If they weren't going to be able to make the budget, then something had to happen. Your organization may be better at getting the right people to show up, I hope so. But be advised that the best way to optimize Non Recurring Costs is to quickly replace people or contractors that are not working out.
When faced with a high Non Recurring Cost and low Resource Constraint requirement, many Project Managers will go out to subcontractors, completely forgetting about the management costs. For a subcontractor you have no experience with, expect to match them hour for hour the first time. If they spend 80 engineering hours, you will too.
If you have a tight Non Recurring Cost budget and high Resource Constraints, you won't have much control over things. You pretty much are getting what you get. In this case, the serial development method is probably best for the project. The Schedule won't be good, and the Technical Performance and Specification will struggle, but something has to give. You can be a master facilitator, and make everyone more efficient, but that is about it. Each person will do the best they can. Some companies use this method to control development costs. NRC and high Resource Constraints does allow costs to be predicted without use of a WBS, finance group inputs, time sheets, but you get what you get.
Can you get some relief in Process? Tailoring of the process is essential to meeting a Non Recurring Cost.
The trick to maximizing Technical Performance in a tight Non Recurring Cost environment is know when to say stop and move on to the next milestone. You have to be a hard ass here, and these are tough decisions. If an engineer has been working on a task for three weeks, the productivity during an additional week can be incredibly high in terms of Technical Performance. Is it worth it? Or is the design dithering?
Another place to reign in Non Recurring Cost is in Specification. The specification may be unnecessarily tight, or too many conditions may apply. There should be backup available on your requirements, a review, with better knowledge of the situation, may yield simplifications. Verification testing may be involved. By designing for verification, you can reduce these costs quite a bit. Of course, you can cut back on verification - but this inserts risk. Although it is rewarding to run tests that pass, from a return on investment viewpoint, tests that pass are a waste of money. Tests that reflect real use situations, and may fail are a better buy. Unless you are running the verification to achieve formal certification, of course. In that case, you can't get much here.
Design spins cost money. At Fairchild, we got a passing design in one pass about 50% of the time. Our process was set up with maximum checking, and we used a great deal of programmable logic to cope with things that came up. Nowadays, two or three spins are typical, although I am sure that a lot of those could be removed by checking.
Checking is the most efficient effort, man-hour wise, in the engineering world. If an engineer spends 8 hours checking a PWB, and finds a bad body and a missing track - he has easily saved the company 16-40 hours of rework, and maybe more if it is something that does not show up until environmental testing. It is also the least desirable activity. No one wants to check. I tell the engineers that typically, we find 4-5 errors on a completed design in debug. So there errors are in there. Find them before we build it.
Non Recurring Cost is also driven by the number of spins - optimizing Recurring Costs requires at least a spin or two, to get real feedback from the manufacturing process into the design. So you have to find ways to take spins, or deliveries of incomplete products, out of the program.
Prototypes are also a sunk cost. Having freely available prototypes can improve your schedule, but be aware that the cost of a prototype is not just the manufacturing cost of the items - it is the cost of keeping the configuration up to date, and servicing these units using engineers, rather than operations people. Keep the number of prototypes as low as possible. And by forcing engineers to share prototypes, they develop better work habits about tracking changes and keeping the units working. If you just have five units on your bench, there is a tendency to have them not quite the same after a while, which introduces uncertainty in integration and test. Two engineers can share a system easily (I learned this working with $100k display systems - no, you all can't have one in your office!) Hold back a spare or two for those accidents that are sure to happen.
As a note, a buddy of my launching a trailer tracking product said that at one point he realized that he could have asked for anything and gotten it. He was holding himself back, because he came from a culture that used Non Recurring cost as a top priority. It was weird to be in an environment where he could spend whatever he wanted.