The requirements document that never got to the developers. In the spring of 2005 I had the pleasure of visiting India. While I was there I spent time at several organizations discussing with them how to become more agile. Part way through the trip I spent some time with a gentleman who worked for an IT outsourcing service firm. One aspect of his job was to take the large requirements documents provided by their American clients, which were typically hundreds of pages in length, and to summarize them down to something less than ten pages. This summary was then provided to the development team, not the detailed requirements. They did this because they discovered that no matter how well the documentation had been written the problem still remained that the documents were error prone, contradictory, and far too verbose. This in turn led to the wrong software being developed. Experience showed them that by giving the developers the overview document and then having them talk with the client on a regular basis, daily conference calls were common, that they could do a far better job. In short, this CMMI level 4 firm discovered that a significant productivity improvement (SPI) strategy was to reduce requirements documentation, not increase it. Granted, writing this document up front would hopefully have had the benefit that the client settled on a common vision. However, they could still have achieved this same goal without having to write some much documentation (e.g. perhaps they should have just written the 10-page summary to begin with).