One of the results of the decreasing defense budget is that competition and value returned are not just hot topics, they are cold facts. Critics have long contended that defense programs were not managed efficiently because these programs were not driven by the laws of the market place. But even if this is only partially true, the perception of a diminished threat (and the resulting diminishing defense budget) is forcing a re-evaluation of the way we manage simulator software projects. The government wants more for less. In the software arena there are a number of advances in both technology and in philosophy that may allow us to do our jobs faster and cheaper. However, as Dr. Deming says, one obstacle to progress is the supposition that automation, gadgets, problem solving, and new machinery will transform industry.

Competition is forcing us to really address software project management. The paper presents an approach to solving the pertinent issues of software project management. How many people are really required to do the job? What kind of people should they be? Who should be the system architect and what kind of person should he be? What are the underlying productivity drivers? Which tools are cost effective for our team, and which are simply neat toys? In which direction should we drive team communication and structure? The issues involved sound so familiar as to be old-hat - a complacency which blocks productivity enhancement. We can not afford this attitude because only the most productive organizations will survive.