Excerpt from Code Complete: A Practical Handbook of Software Construction, Second Edition 2nd Edition - Chapter 34 by Steve McConnell

On projects with more than one programmer, organizational characteristics make a bigger difference than the skills of the individuals involved do. Even if you have a great team, its collective ability isn’t simply the sum of the team members’ individual abilities. The way in which people work together determines whether their abilities are added to each other or subtracted from each other. The process the team uses determines whether one person’s work supports the work of the rest of the team or undercuts it

One example of the way in which process matters is the consequence of not making requirements stable before you begin designing and coding. If you don’t know what you’re building, you can’t very well create a superior design for it. If the requirements and subsequently the design change while the software is under development, the code must change too, which risks degrading the quality of the system.

“Sure,” you say, “but in the real world, you never really have stable requirements, so that’s a red herring.” Again, the process you use determines both how stable your requirements are and how stable they need to be. If you want to build more flexibility into the requirements, you can set up an incremental development approach in which you plan to deliver the software in several increments rather than all at once. This is an attention to process, and it’s the process you use that ultimately determines whether your project succeeds or fails. Table 3-1 in Section 3.1 makes it clear that requirements errors are far more costly than construction errors, so focusing on that part of the process also affects cost and schedule