Change Of Software Process
In Bruel & Kjaer, it was determined that the resistance would have been considerable if the project managers had not been involved in a configuration management database. Without involvement of the project managers, the only possible changes would be for management to force a change of formal structures such as the quality system. However, such changes would not be followed by a change in software process practices since this would depend on the active involvement and commitment of those who should change their practices, i.e., the project managers.
In the terms of Mintzberg, Bruel & Kjaer is a professional bureaucracy. The primary mechanism for coordination in a professional bureaucracy is standardization of skills (i.e., education and indoctrination). Without the direct involvement of the professional practitioners, changes are unlikely to have any effect. For example, changes in processes made by the techno structure as standardization of processes may work for a machine bureaucracy, but it will not fit the professional bureaucracy. Simply telling a professional to change his practice has little or no effect.
However, the limitation of problem diagnosis is that disagreements and conflicts are not easily handled. Disagreements may easily arise between different perceptions of problems. We did not experience this, since we found surprisingly consistent explanations of software process problems. This may in hindsight be explained by the fact that the involved project managers, to a large extent, had common interests and goals with the SPI project. The question we are left with is whether problem diagnosis can be used if there are more manifests or dominant disagreements among project managers. We have little experience with this, since problem diagnosis was designed to embrace and cater for disagreements on a small scale. Disagreements at this level are dealt with through dialogue. First, the dialogue between each project manager and the research team during interviews. Second, the dialogue at the workshop among the project managers themselves and between the group of project managers and the SPI group. This will deal with disagreements that can effectively be resolved or otherwise handled through dialogue. Other, more fundamental conflicts must be resolved through negotiations.
Another question is whether the lack of serious disagreements during the problem diagnosis at Bruel & Kjaer was caused by the deliberate exclusion of other groups from the process, particularly top management, the quality assurance department, the marketing department, and programmers. On one occasion, when a programmer participated in the interview, some conflicting views between him and the project manager were revealed, but we did not find reason to analyze this aspect closer. Both because we did not have sufficient time and resources to do so, and because we wanted to maintain our focus on the project managers.
In general, problem diagnosis need not be directed solely at project managers. In other companies, the organizational culture may well point in the direction of other relevant participants, such as senior management or programmers but it remains important that the interviewees represent powerful groups in the organization and that their viewpoints are essential for understanding the organization's software process problems.
|