Curtis ACM 1988

Summary

The authors seek to investigate problems that large software projects experience, and to reconcile them with contemporary project management theory as it applies to quality and team productivity. They interviewed project participants (systems engineers, senior software designers and project managers) of 17 large projects to get the perspectives of those actually involved, and used them to build models of the important processes and create summaries of the major process-related issues. The 17 projects were in various stages (8 in active development, 5 in maintenance, 2 in design, 1 in requirements, and 1 terminated), were in varied industries, and averaged 200K lines of code. They found that large projects must be at least partly thought of a learning, communication and negotiation process (p. 1282).

They modeled the organizational domain as consisting of five social/behavioral/cognitive layers: individual, team, project, company and business milieu (inter-company or company with outside clients). The paper used these layers to contextualize each of the three major process-related issues. These layers are why the authors refer to their model as a layered behavioral model (p. 1269).

The process issues they identified and their conclusions about them were:

the thin spread of application knowledge: organizations should strive to increase the application domain knowledge across their entire staff
fluctuating and conflicting requirements: software development processes should be re-designed to accommodate uncertainty in design decisions and requirements
communication and coordination breakdowns: software development tools should incoporate strong support for knowledge sharing and integration, change facilitation and communication.

Issues

Thin spread of application knowledge

Although many individual staff members had sufficient knowledge of the components they worked on, they rarely had the knowledge of all the various areas of knowledge needed to integrate the entire application. Software development of large software projects requires a large time commitment to sufficiently learn the application domain; learning a new application domain or project to the point of productiveness required six to twelve months for a new member (p. 1274). At a project level, the time required to design (which may include "throw the first one away") was often underestimated because learning or training time was not included in estimates.

Managers recognized that project performance could be greatly affected by the talent and skill of individual project members, and yet knowing the capability of their staff was difficult for them. The most important and valuable project members were the very rare exceptional designers (p. 1271): those usually senior and highly experienced engineers who took prime responsibility for system design because of their superior application domain knowledge and experience. Expert power (p. 1273) (presumably by these exceptional designers) was very effective at exercising authority within teams during much of the design process, and the early phases of most projects were dominated by small coalitions of experts, or even just one exceptional designer (p. 1273). In the business milieu, companies did not share assumptions about market applications, and knew their own applications, but not their competitors' (p. 1275).

Fluctuating and conflicting requirements

Requirements fluctuation is tied to scarcity of domain knowledge in that incomplete application domain knowledge can lead to a flawed analysis of the requirements at project start (p. 1275). Learning the application domain as the project progresses affects both the engineers (as previously discussed) and the customers who drive the requirements. New requirements often were discovered by engineers as the system was developed because they could not be identified until some parts of the system had been designed or implemented (p. 1278). Similarly, customer learning can lead to requirements changes as such learning can new possibilities for the system (p. 1276). Direct customer access to the development team can lead to requirements changes outside the formal change request process, and having to obtain (or failing to obtain) approvals from regulatory agencies can also cause requirements to fluctuate. Lack of knowledge of actual user behavior at the team level caused requirements conflicts to be difficult to resolve, necessitating requirement prioritization or other negotiation (p. 1278). Some designers argued that requirements should not be hardened until the team had learned the application domain (p. 1278).

If a group internal to the organization is acting as proxy for the actual customer (such as a marketing department providing requirements based on what they think potential customers might want), requirements gathering can be flawed if the customer model used by that group is wrong. Lack a strong sense of mission for a project can also cause instability in requirements. This may be the case if the project was started for political reasons, or if the initial project team is more interested in winning a contract than in accurately forecasting project cost.

Creeping elegance was another source of requirements instability that was the source of much frustration to managers (p. 1278).

Communication and coordination breakdowns

The more people that information had to pass through in order for conversation to take place, the less likely that that communication was going to happen at all. When communications channels to the end customer were long, needed changes were oftehn stifled (p. 1282). Designers and developers needed operational scenarios from the customer (scarce application domain knowledge again), and could seldom get them (p. 1282). Communications between groups and across behavioral levels is filtered, and information altered. Communication to higher levels involved a change in the content of the message, a different context for interpretation, and a narrower bandwidth channel.

Documentation was vulnerable to other project pressures (p. 1279) typically could not resolve misunderstandings about requirements or design issues (p. 1280), and was not found to have reduced the amount of communication among team members. Team members typically had informal social networks via which they could gather information on issues that affected their work. This was crucial to individual project member performance and to resolving design issues. Part of the resolution involved developing common representational notations for diagramming (p. 1280). Documentation was, however, frequently the main source of communication between successive teams (p. 1281), after continuing personnel.

Communication between teams on a project was difficult to establish unless channels opened naturally, and managers often thwarted such communication for political reasons. This can be avoided if members of a single project team span organizational boundaries (p. 1280). Companies usually had formal processes for discussing design decisions, but these processes were often ineffective. Informal social networks were frequently the most effective way transmit information to cross organizational boundaries (p. 1280).

Exceptional designers

were recognized as the core of the project by other engineers (p. 1271)
were often described as inter-disciplinary (p. 1272)
were skilled at modeling the interactions of the different functional components (p. 1272)
were skilled at communicating their technical vision to other project members (p. 1272)
became consumed with the performance of their project (possibly to the detriment of their health, which constituted a project risk) (p. 1272)

Are exceptional designers the hero programmers that McConnell [1] mentions?

Critique

This is an incredibly highly cited article: Google Scholar lists 763 papers which cite it.

I need to look to see when this was written in relation to the development of agile software methodologies. Are the observations that the authors report reflective of a need for large scale agile methodologies? Agile methodologies are not supposed to scale well to large projects.

References

Mcconnell, Steve; Professional Software Development, Addison-Wesley: Boston (2004).