Project management: How to compose a project team

RELATED CONTENT Software Project Management What are the pros and cons of centralizing a QA or software test team? Who determines the appropriate severity or priority for a defect? Variants between software quality assurance and software testing Advice on how to enter the software technology field Differentiating between Functional and Nonfunctional Requirements Where does quality assurance fit in agile development? Quality standards don't always mean fewer defects How to present a project to the management Project management charts: Beyond Gantt How to switch your team to Agile Team building and group leadership What are the pros and cons of centralizing a QA or software test team? How to get development, QA and security compliance teams to play nice How to stop developer vs. tester, quality-killing blame game How software testers can get deliverables without nagging How to get management on board with Web 2.0 security issues How software test teams' people skills affect results Adaptation in project management through agile Expert shows seven ways to improve your project management abilities Cybersecurity czar candidate questions clout of new position Software security best practices: Roles developers must play Hiring, mentoring and training for software projects Is your software test team rigorously incompetent? Advice on how to enter the software technology field Optimizing project management using text messaging, IMs, and Skype How to get a software testing job in a recession Does Microsoft offer an international testing certification? How to handle IT project management in a recession How teams transition to agile development methodologies Do security certifications really matter? Yes, really Cutting staff for a more agile software development team Software development lifecycle (SDLC) trends 2009: Requirements, agile

RELATED GLOSSARY TERMS Terms from Whatis.com − the technology online dictionary Project Management Professional (PMP)  (SearchSoftwareQuality.com)

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary

EXPERT RESPONSE FROM: David Christiansen Pose a Question Other Software Quality Categories Meet all Software Quality Experts Become an Expert for this site

ANSWERED November 2007:

Here are some general rules of thumb about team composition that I like to follow:

Generalist first, specialists last
You should avoid specialists if you can. They tend to be grumpy one-trick-ponies that aren't particularly interested in developing a good core team. Besides, they only do certain tasks, eschewing all other work. Specialists spend a lot of time waiting between tasks that are "appropriate" for their skills, so they are either wasting your project's money OR only partially allocated. Both of these situations add risk and invite failure and can cause tricky scheduling dependencies.

Generalists, on the other hand, can add value throughout the entire project lifecycle. They can help at all phases, which means scheduling isn't such a big deal. In fact, having a team staffed entirely with generalists can go a long way to eliminating dependencies on your projects critical path.

A full-time newby is worth two part-time pros
Don't take on part-time team members unless you absolutely have to. I would take a full-time college grad over two part-time seasoned veterans any day. Part-timers create scheduling nightmares, plus they don't have a sink-or-swim commitment to your project. Both of these things can sink you.

If you have to use part-timers, agree on when they will spend time on your project upfront. If they are 50%, then agree to a schedule, such as Joe Parttime will work on my project all day Tuesday, Thursday, and before lunch on Friday, barring a life-or-death emergency.

Too many cooks will spoil the soup
Some IT people are very competitive, and they can have a tendency to argue endlessly about technical details of little significance. It can be a lot easier to manage a project if there are only one or two highly skilled generalists on a small team. Anyone who can contribute should be allowed to, but you can avoid a lot of fighting if you have one team member who is recognized as the technical leader by the project team (not designated as such by management).

Software project management and team building resources: Facilitate software development team decision making Project managers' evolving role in software development How to mentor new project managers

Small classrooms are better
Don't overwhelm your best generalists. Most likely, they have broad responsibilities across the project. You will suck the life out of a single highly skilled generalist if she is responsible for bringing more than two or three (at the most) newbies from dependency to self-sufficiency on your project.

It takes two smart team members just to compensate for one dummy
Being "un-smart," as you put it, and being inexperienced are not the same thing. Smart people will overcome inexperience very rapidly and will be able to focus on developing their own ability to do their work with minimal supervision. Beware the true dummy, though. He or she can be found at any experience level and will be a big barrier to progress, either by their own incompetence or by their tendency to look effective by delegating their work to others and then taking credit. They are extremely costly. Getting a dummy like this OFF your team will have the net effect of adding to people to your team.