The process fails to cope with increase in scale
The process works while the enterprise is small or only small projects are undertaken, but fails to cope with increase in scale.
Processes do not naturally scale up – what is suitable for a small project is not suitable for a large one. The benefits gained by having rich communication between members of a small team are lost as more members are added to a team and more time must be spent in communicating to get the same richness. There are two alternative approaches (or two alternative extremes). First, one may divide up the work so a larger project becomes several smaller projects, then add on an extra layer of organization to maintain coherence between the projects. Second, one may increase the size of the team and run everything as one project. This requires more formalization of the communication between roles and between people in the same role, to replace the informal communication that now threatens to cut too deeply into the available time. Yet this formal communication also cuts deeply into the available time. Up to a point, the best approach is to get better quality people so they can work more efficiently and do the increased work without increasing the team size. Moving to a more agile process can add to this effect. Yet it is unlikely you will get more than a five-fold increase by these approaches in combination with each other (that’s a ball-park figure, circumstances vary), and if already using top quality people and agile approaches, there is no room for improvement in this direction.
Greater throughput with the same number of people can be achieved by getting better people and by moving to a more agile process. These approaches are not always feasible and will not be sufficient where the project size increases more than about 5-fold. Some process re-organization is likely (see InappropriateOrganization). However, a degree of scaling up can be obtained by applying the DivideAndConquer pattern.
Some of the modern Agile approaches such as XP do not scale up well, and need added practices, particularly on the management side, to cope with large projects. Yet there are hybrid approaches appearing, having an agile approach dealing with agile management, married to XP to deal with agile development. DSDM and Scrum in particular frequently include, or are used in conjunction with, XP. Adaptive Software Development and Feature Driven Development are probably more appropriate for larger projects than for smaller ones.