IT Team Development: Better IT Team Building for Projects

I.T. managers in just about every industry share a common challenge: motivating teams of people to make projects work. "Great technology, great project plans, and even great people are not enough," says consultant Peter Temes, president of Enterprise Interactive [http://www.enterprise1.com]. "You need to have the right people on the right projects -- that means teams of people who believe in what they're doing, and put the success of the project above their personal goals on a day-to-day basis."

Teaching leadership at Harvard University in the early 1990s, Temes came to see that the most effective groups were made up of self-selected participants. People choosing to work together on projects they believed in -- in a social setting, in a political setting, or at work -- in most cases outperformed groups that were required to work together, even if they had better technology and greater financial support.

"Imagine," Temes says, "a group of civil rights protestors facing off against a group of state troopers. How in the world can people with just the clothes on their backs win when they come up against paid professionals with riot gear and weapons and the support of the government? But they often do win. Or consider the small software company that sets out to beat an industry leader. What do five young people working in the basement have that can beat a billion-dollar organization with row after row of Ph.D. scientists working on the finest equipment?"

The answer Temes kept finding was that the personal desire of team members to work on a project was the ultimate predictor of success. "Wanting it more matters the most, in the long run," he says. "The real question, then, is how to help someone managing an I.T. organization in a large or mid-size company get the same level of personal commitment."

The answer often lies in casting a wide enough net to find those people who want to be part of the project so much that they'll learn new skills, and devote personal time to meeting the goals of the project. That's what Temes calls "Opt-In Teaming."

"If you're organizing a team to work on an Internet-related project, for example," says Temes, "you might find that there's someone in accounting taking HTML classes at night, because she's just wild about the Internet, and she'll self-select into the project ahead of someone with stronger credentials who's just not excited about it. And that's all to the good."

Temes offers these guidelines for creating self-selected teams:

• Cast a wide net. Be sure that everyone in your organization knows what your project is about, and that people from every discipline are welcome, if they have the skills you require.
• Start early. Ideally, you want to start recruiting team members early enough for people without required skills to acquire those skills before the project begins. Example: An upcoming conference on user interface design might allow a motivated professional without an interface-design background valuable training opportunities and exposure to the field. Announce your project, and your desire for volunteers to work on your team, before the conference, and you'll have a broader pool of potential volunteers.
• Make it easy to qualify. Prepare a brief that you can circulate widely, listing ways for interested colleagues to qualify for your team -- including lists of conferences and courses they might take, or over-the-Internet training programs.
• Maintain the level of excitement throughout the project. Remind team members that they're a special, self-selected group. Give them the opportunity to make decisions collaboratively whenever possible, and share the results of their work -- even while it's in its early stages -- with a meaningful audience whenever you can.

"Opt-in teaming is no guarantee of success," Temes adds, "but it can help make a good project great, and help keep some of the teamwork demons at a safe distance."