As for ROI, I’d have to say the time spent is well worth it and once it becomes part of the process, its hard to turn back.

Anyway thanks for the clarification..it certainly gets us thinking.

Thanks for taking the time to read the article and commenting.

Hopefully, I can put this into a little better perspective. The size of our project teams is dependent on three variables: the amount of functionality to deliver, the project budget, and the project duration. If we are looking to deliver sooner, increasing the number of people helps to a point. If we are delivering more, increasing the size of the team helps to deliver more to a point. Of course, all this is constrained by the budget.

Teams were naturally smaller years ago because of technology constraints. The primary technology constraint is memory since more features requires more logic which requires more memory. There’s no way to deliver the complete feature set of Microsoft Excel in a Commodore 64 because there isn’t enough RAM to hold the logic for the complete feature set. You’re never going to justify 100 programmers to write software for a Commodore 64 because there is only so much logic you can deliver in a 64kilobyte machine.

So on PCs and embedded products the amount of logic we could develop was constrained by the amount of memory available to hold the logic. So years ago our teams were naturally smaller because we were delivering less because of technology constraints. And as the amount of memory has grown, the feature set of our applications has grown, complexity has grown, and the size of the teams to deliver these applications has grown.

You can get away with less formalism when the teams are small. Years ago we were successful with less formalism because the teams were smaller because the demands were less. Today, you can rarely get away with less formalism because we are delivering more feature laden products. And to deliver these feature laden products quickly the size of our teams has grown.

Formal project management practices are always good, and I believe they would have benefited the projects I worked on when I first started out, but on small teams delivering small feature sets, you can be successful without the formalism as many teams were successful many years ago. So I was answering the question why is it necessary to have formal project management practices today as opposed to yesteryear when formal project management practices were less common, yet projects were successful.

If you are reading this and you’re looking for a simple tool, try project123. We attached the ‘Change’ block, which gives us historical data and that works for us.

Btw thanks Bill for a beautiful article. I look forward to reading more pieces.

Changes in technology are not a significant factor in relation to team size. Teams are large because of the combination of many stakeholders (including preexisting systems), and complex processes. In other words, complex or bureaucratic organizations with legacy systems breed large teams. Smaller teams can (and do) produce equivalent results in smaller, simpler organizations.

There were many large teams in the 80s and 90s. There was a technology link then – they needed more people to achieve the breadths of functionality that would take just a few people today.

PS: I also enjoy the Herding Cats blog.

- Sue.