1. Cooperative Work

U.S. software developers emphasize originality. So, in comparison with Japan, U.S. managers rely more on input by individuals than they do on the contribution of a team. U.S. software development certainly makes maximum use of individual creativity and is widely admired by the Japanese. Japanese software development is the result of cooperative work of many software engineers. A developer not only gets cooperation from other members of the team, but also obtains the cooperation of others from different departments. Moreover since it is important for software developers to understand fully the needs and to obtain the cooperation of customers, they frequently cooperate with each other, Japanese software developers analyze requirements and specifications as groups, rather than as individuals. In sum, one of the main characteristics of companies in Japan is that they rely on the creativity of the group rather than on the originality of an individual.

2. Custom Software

Japanese companies prefer custom software developed for a specific purpose rather than general purpose packaged software from external sources. Whereas in the United States packaged software comprises 50 to 60 percent of all sales, the percentage of packaged software in Japan is very small. In 1991, custom software and system integration accounted for 78 percent of the Japanese software market, compared to 39 percent in the United States. Japan has little international market presence in the software field. Industry analysts remain divided over where Japanese firms currently stand in the software field (Cusumano, 1991). On one hand, some reports continue to claim the Japanese are years behind the United States.

On the other hand, there are increasing reports of high productivity and quality in Japanese software. Japanese firms display enormous creativity in other areas of engineering and possess many abilities that should be of benefit in computer programming.

Both views are partly true. Japanese companies are strong in the process of FA applications software such as the steel industry; numericaj control machine tools and industrial robots. This is in contrast to the United States, which is very strong in the product of packaged software as well as basic system software (for example, Microsoft, Oracle, Novell, Computer Associates, etc.).

The key to FA is software. Logically, therefore, the Japanese must have the expertise to produce the FA Software

3. Software Houses

In Japan, much of the FA and CIM software is developed by software houses. These software houses are typically subsidiaries either of the computer manufacturers or the companies that use the software, or they are independent subcontractors This use of outside software developers would be very expensive in the United States, but in Japan it is just the Opposite. In strong contrast to their U.S. counterparts Japan employees do not like specializing in anything because it hinders chances for promotion. Even in management ranks the cross-trained or multifunction (tanoukou) worker is considered the the ideal. Those employees who do specialize migrate to specialist firms and accept lower pay. Thus, it is possible to use outside consultants at lower expense than internal employees. This way of getting the services also solves the difficult personnel problems that would come from permanently assigning employees to specialist operations such as computers, which would effectively end their career.

Because of these three special characteristics of Japanese software development, cost management for software in Japan in focused on managing each software order as a whole, and these orders are often entrusted to external personnel who have a detailed reporting obligation

The Software Industry Is a Manufacturing Industry

Many experts who develop software in Japan consider the information services industry to be a manufacturing industry This is the major reason why the Japanese adopted the word “factory” for the place software is developed. Thus it is only natural that more than two-thirds of Japanese software houses use cost accounting for software. Japanese companies have also adopted the factory approach to software management, So, it is only natural that most software developers believe that a cost accounting system for software is essentially the same as that for industrial products, even though there are several technical and Conceptual differences

Characteristics of Software Costs

Software costs have some unique characteristics. One is that work in process has no physical substance, As a result, managing software costs is more difficult than managing hardware costs. In addition, for cost management it has become very important to measure properly the number of labor hours spent in developing software.

The second characteristic of software costs is that the cost structure for software is very different from that of hardware. Labor cost is very high, much as it was for manufacturing before automation.

One of the driving forces behind the cost accounting systems is that many software developers need to provide full cost information for reimbursement under the common cost-plus contracts. Only 18 percent of developers use direct costing (variable costing), and the remaining 82 percent of the software houses use absorption costing. The form of absorption costing is more extreme than would be seen in the U.S. manufacturing systems. Their methods calculate the full absorption cost by adding even sales and general administrative expenses to manufacturing costs either regularly (51 percent) or when necessary under production contracts (31 percent). This practice differs markedly from manufacturing companies, which do not continually calculate full absorption costs. However, it is similar to the methods used by defense suppliers.

Cost Management Tools for Software

The major tools for cost management in software development include standard costing, budgeting, target costing and TQC.

Standard Costing

Software development is labor intensive work. This suggests that standard costing can be an effective tool for controlling development cost. In fact, many Japanese mainframe manufacturers use standard costing for control ling system software costs.

Time and motion studies, which are effective in industrial production, cannot be applied to software development because developing software is an intellectual operation that changes from project to project. Thus, Japan’s mainframe manufacturers often use cost models to set standards instead of attempting to use work measurement methods. For example, the following standard is set for direct labor costs, input costs and machine costs for a typical software developer.

Standard direct labor costs	=	the standard wage rate	x	the standard labor hours
Standard direct input costs	=	the standard entry unit cost	x	the standard entry hours
Standard direct machine costs	=	Standard cpu rate	x	the standard machine hours

However some factors hinder the adoption of standard costing. First, software is not a mass-produced product. It is produced individually. Thus setting a standard cost for each program takes time and is very difficult. Second, standardization is difficult because the Skills of Systems engineers vary widely across individuals Third, software engineering techniques are improving rapidly. In addition, once a standard is set, it becomes behaviorally fixed and work group flexibility is likely to be lost. This could threaten the future development of software technology and would certainly slow it down in many companies. Standard costing is thus a two-edged sword, which must be considered carefully before implementation.

Budgeting and Progress Management

The core of the manager’s control of software development is self-regulated management with profit goals and cost targets. In other words, management sets the overall profitability targets, but leaves the details to the lower-level managers and employees. It relies on the quality and training of the employees to innovate their way to good performance. Software developers must use profit planning and budgeting for this purpose. A profit plan should be prepared first, cost targets set next, then software developed efficiently to achieve the profit goal and cost targets. Performance should be compared between the results that could be obtained and the goal and targets.

It is necessary to check development progress against the schedule by using a budgetary control trend chart. The comparison between the budget and actual results should be conducted at the overall project level, the intermediate levels, and for sub-sub systems Figure 18, a cost item control table, is an example of a trend chart.

Control chart cost elements
	April 20xx to March 20xx
Cost	April 20xx	Cumulative Total	Forecast
Labor Cost
Purchase Cost of SW
Contract Costs
Computer Costs
Supplies
Travel Expenses
Etc.
Adapted from: Sakurai, Michiharu, and Paul Scarbrough, Integrated Cost Management, Productivity Press 1995. Used with permission

Cost management linked with progress management of software development work is a part of budgetary control for software development. Budgeting plays an important role in effective project management for most developers. However progress management with the budget system is not as easy as it might seem.

When product development is behind schedule, even in only one module, the entire operation will probably be delayed. This adds costs. In addition, changes in the external environment (mainly in the marketing, such as changed lead time, features or operational requirements, etc.) and changes in internal environment (mainly management conditions such as transfers of personnel, a new project, delay in operations lack of appropriate experience by software engineers, etc.) will necessitate changes in planned costs. In this situation it is important to compare actual with planned figures to determine what the effect on profits will be. It is no exaggeration to say that progress management for each operation is the heart of cost management for software.

It is sometimes difficult to estimate revenues and costs when working on a sub-task such as system design, detail design, or testing. In such case, one must always proceed from the premise that the estimated costs may change due to changes in design and operating requirements. Normally, software developers have hundreds of orders and for most projects personnel will be reassigned regularly due to changes in shipping dates desired by customers, delays in the development of hardware, delays in internal company operations, etc. Consequently, planned costs may change. Thus, it is necessary periodically (usually every three months) to compare actual costs with the budget and to modify and revise the budget. It is also essential to trace the variations in costs in the budget systematically from the time of estimation to the time of actual shipping and to identify the cause of the variations. Typical reasons for increases in costs include mistaken estimates and failures in operations due to lack of personnel expertise.

Target Costing for Computer Software

One promising tool in cost management for software is target costing. When a software contract is discussed with a customer, the developer forecasts the sales price. Target profit can be computed from the forecast sales price. Japanese software development houses typically use ROS goals for backing into the target profit. Allowable cost can be computed by subtracting the target profit from the forecast sales price.

While calculating the estimated cost for each feature and process, cost reduction is always the goal. After cost reduction activities have been tried, the drifting cost is calculated and compared with the allowable, or target cost. When the drifting cost is larger than the allowable cost, it is once again subjected to cost-reduction efforts, if the drifting cost cannot be lowered to the target, then negotiations to raise the price may be necessary In calculating the drifting cost, modules of code that can be converted or made into general~purpo5e modules will be taken into account. The ability to convert or reuse parts of an existing program is a major point where cost management for software and hardware differ.

TQC

Since software is developed through the teamwork of many different people, total quality control (TQC) is one of the most effective means of managing it. TQC was introduced to Japanese manufacturing companies at the beginning of the l970s but its use in software development came much later, in the early l980s. TQC for software began around 1980 in Japanese mainframe manufacturers From about this time both NEC and Toshiba aggressively began to develop unique types of TQC. In NEC it is called software quality control (SWQC).