Challenges
A government client hired QSM to perform a software productivity benchmark on 18 completed financial applications ranging from 25,000-225,000 ESLOC. Compared against our Government IT trend lines the client’s productivity was average, yet their team sizes were 2-3 times the industry norm. This additional staff produced modest schedule compression, but there was a price. Development costs soared, and the delivered products were buggier than average.
Fred Brooks of IBM identified this behavior while building the IBM 360 mainframe operating system over 35 years ago. Adding people to a project exponentially increases the number of communication paths between team members. This communication complexity typically produces a bumper crop of defects that must be found and fixed prior to release. The marginal schedule compression is offset by huge increases in cost.
We recommended using slightly smaller teams to reduce cost and improve reliability. Solution
One courageous project manager was eager to adopt our approach. His typical project used a team of 60 people, took 9 months, and delivered about 55,000 ESLOC. He needed to start work on a new technology project, but an existing project was tying up the resources he needed. Our analysis helped him convince management to split his team in half. One team would complete the existing system and the second group would begin working on the new project. Outcomes
Upon completion of the existing project, the team analyzed the results. They were amazed to find that the completed project took just 2 weeks longer than expected! But the real surprise was that they delivered a more reliable product with nearly twice as much functionality at a savings of $4.3 million dollars. Moreover, the small team strategy freed up 30 staff members, giving them a 9 month head start on their next project. It’s hard to argue with results like that.