I know that in project management, people are considered resources in the same way that raw materials are considered resources, but for software development projects I have found it counterproductive to treat people like so many interchangeable parts.
The success of a software project hinges on the interactions among many people, including the client, subject matter experts, project managers, testers, trainers and developers. In addition to their experience and expertise, these people bring with them their personalities and communications styles.
Because software development is more a team exercise, like filming a movie, than an individual exercise, like writing a book, the overall team dynamic is just as important as individual qualifications. It is quite possible to put together a team of people with excellent resumes who will be quite ineffective when forced to work with one another.
I have run into clients who focus excessively on comparing resumes as if they provide an indication of future success. Some of the best resumes I have seen belong to work avoiders who spend more time finding others to blame than accepting responsibility and getting things done. Job hoppers have more interesting resumes than steady performers that stay with companies and projects for the long haul.
So many project methodologies are now used that you need to ensure everyone is on the same page. Approaches and activities that work in one methodology are disastrous for others. Excessive love of methodology and documentation over working software is ever more pernicious.
Experience of people who have worked as a team is a great asset for a software project. Knowing the strengths and weaknesses of team members helps project managers and technical leads assign tasks to the right people, and to know how those people should be managed. Some need close attention with frequent interaction, and others need time alone to do their work. Some people will thrive in the intense pressure of a war room environment, while others will crumble.
So even if you call them resources on your project plan, don't treat people like resources if you want your project to succeed.
The success of a software project hinges on the interactions among many people, including the client, subject matter experts, project managers, testers, trainers and developers. In addition to their experience and expertise, these people bring with them their personalities and communications styles.
Because software development is more a team exercise, like filming a movie, than an individual exercise, like writing a book, the overall team dynamic is just as important as individual qualifications. It is quite possible to put together a team of people with excellent resumes who will be quite ineffective when forced to work with one another.
I have run into clients who focus excessively on comparing resumes as if they provide an indication of future success. Some of the best resumes I have seen belong to work avoiders who spend more time finding others to blame than accepting responsibility and getting things done. Job hoppers have more interesting resumes than steady performers that stay with companies and projects for the long haul.
So many project methodologies are now used that you need to ensure everyone is on the same page. Approaches and activities that work in one methodology are disastrous for others. Excessive love of methodology and documentation over working software is ever more pernicious.
Experience of people who have worked as a team is a great asset for a software project. Knowing the strengths and weaknesses of team members helps project managers and technical leads assign tasks to the right people, and to know how those people should be managed. Some need close attention with frequent interaction, and others need time alone to do their work. Some people will thrive in the intense pressure of a war room environment, while others will crumble.
So even if you call them resources on your project plan, don't treat people like resources if you want your project to succeed.