There are times when managing an IT project team can seem like building the Tower of Babel. Individuals seem to be speaking different languages, and you can't get them to work together. Lynne Wardell calls this confusion the Chaos Period, and she calls its antithesis Group Think. "Group Think is where everyone has the same understanding of what the project is about and how you plan to achieve it," she said. Wardell is the president and founder of the Haddon Group, an IT consultancy based in Oakland, CA. She provided a few hints that she's discovered in her 15-year career as an IT manager and consultant. These are her thoughts on getting through the Chaos Period and achieving Group Think. Group Think is about speaking the same language
To achieve Group Think, you have to get your team to use the same language and work toward the same set of goals. To get her teams to this level of understanding, Wardell actually helps the team create the language by defining the project's objectives. To illustrate how this is done, Wardell cited one case in which she and a team were tasked with rolling out a new OS to seven call centres and 3,200 users. Two business units and a technical infrastructure organisation were involved in the project, and there was a tremendous amount of animosity among the groups from the start, she said. One business unit was known for dominating resources, and the other was known as a sluggish giant. Meanwhile, the technical organisation had a reputation for pushing substandard technology without considering what the business units needed. "When we brought individuals from each of the organisations together, along came their attitudes about one another," Wardell said. First, Wardell identified the most agitated team members and apply her tried-and-true teambuilding techniques, as described in a previous article on TechRepublic. Then, to establish Group Think, she needed to transform everyone's individual ideas about the project into one set of thoughts that the group would share. To encourage that to happen, Wardell took the following steps:
- She asked the three division managers to submit their main goals for the project and combined them to create one set of objectives.
- She asked individual team members what those objectives meant to them and how they thought the team should achieve them, which encouraged them to take ownership in the project and to be more committed.
- She published the project objectives on every document and started out every status, strategy, planning, or presentation meeting with, "If we are trying to achieve objective xyz, then...."
Sometimes, when people from separate units or divisions are brought together to solve an existing problem, they bring an "it's not my fault" attitude to the table that results in finger pointing. That blame game is detrimental to the team because it detracts from actually solving the problem. In one such case, Wardell and a team were charged with rolling out a custom application built to handle over four million customer calls per month. There were divisions responsible for the GUI, middle tier, WAN, and mainframe portions of the system. The system began having major performance problems, with five- to six-hour outages every two weeks and poor daily performance. Each group involved was convinced that the problem wasn't theirs, Wardell said. The resulting commotion was being communicated through their managers to the chief information officer. To help solve the system's problems, Wardell put together a task force of key business and technical staff from each area, leaving the higher-level managers off the invitees list. Next, she set about helping those key individuals define the group's goals using the following steps:
- Asking the business proponents to help define success in terms of performance. In other words, what was acceptable performance to the users?
- Redirecting everyone's energy from pointing fingers as to who was responsible for the problems to working together to achieve success as defined by the proponents and discussed and agreed on by the team.
- Compiling feedback from users to validate that the data we were using was telling the right story.
- Agreeing on what the data was saying and what it wasn't saying, establishing a common understanding and agreement of how the data would and wouldn't be used.
Both projects were successful beyond the expectations of anyone involved. The OS rollout came in on time and 50 percent under budget. The custom application team improved the performance of the system "beyond those thresholds set by the business proponents," Wardell said. Most remarkably, Wardell was impressed with the way the teams began to work together toward a common goal. "Perhaps the most amazing thing to watch was how much more time individuals from different departments spent visiting one another's desk, sharing thoughts and ideas before they proceeded developing and implementing," she said. "No longer were they working in a vacuum." TechRepublic is the online community and information resource for all IT professionals, from support staff to executives. We offer in-depth technical articles written for IT professionals by IT professionals. In addition to articles on everything from Windows to email to fire walls, we offer IT industry analysis, downloads, management tips, discussion forums, and e-newsletters.
For all job and work-related news, or to search for a job and get information on training, go to ZDNet Jobs.
If you have something to say about work and employment issues say it here at the Jobs Forum.
Let the editors know what you think in the Mailroom.
Talkback
Isn't groupthink traditionally viewed as a negative aspect of organizations -- ie. The Challanger Space Shuttle Disaster, IRAQ, etc? There are even companies whose product / service lines are aimed at combatting the ill effects of groupthink (i.e. TheFirst2.com). Seems we should clarify the termonology a bit,