Personally, I have always leaned towards having the fewest people involved in any project, this is based on my feeling that any additional communication, management or human interaction than required exponentially adds to the risk level of the project – however – I might be wrong. What if the team is well established, mature and requires minimal management? (Ideal situation of course)…what value could having more people than required on a single project?
- Higher quality product and more productive if an XP type of team programming is in place.
- Chance to develop a Jr. member on the team
- Continued reinforcement of the team model and on-going success record
- Direct transfer of knowledge to a backup person
I used to be more of a proponent of small project teams as they could be more agile than one requiring a standard team. I see this as a contrast similar to a Star Trek I vs. Star Trek II approach. My background is mainly with software projects, where you could bypass the process to get a customer out of a bind and be a hero (Star Trek I), but you do pay a price, which is usually quality. With a standard team (Star Trek II) you get rigor, which means a formal code review from a different pair of eyeballs and QA by a team who wants to break the program. Good software change management products enforce a process by which every emergency change is considered temporary, so has to be backed up by a standard change process that has a review, full testing and approval process. I am definitely in the big team camp.
ReplyDeletePradeep Bhanot, Product Marketing Director, CA Clarity, CA
Work as a team is better than a group work
ReplyDeleteit certification