May 17, 2010, 11:06 AM — by Watts S. Humphrey - There are many reasons for teams to be ineffective, but the most common problems fall into one or more of these four categories: inadequate resources, leadership problems, impossible goals, and morale problems.
[ Enter to win a copy of Reflections on Management: How to Manage Your Software Projects, Your Teams, Your Boss, and Yourself. Go now! ]
A team of six developers was told to plan their next project. Only one developer was assigned full-time to the job, and she was acting as temporary team leader. The other five developers each had another full-time job, and two were working on two other projects. Projects were only fully staffed when they became crises. While the hot projects ultimately got done, they were always late and the customers were always irate.
When organizations do not realistically address their resource problems, their projects are always in trouble, and they stay in trouble either until new management is brought in or the company goes out of business. To get a job done, management must dedicate developers to the work. Then, these developers will know that the job is important and be able to ignore almost everything else.
When teams have leadership problems, they lose the excitement and energy that produces superior products. One example is Ken's team. Ken had extensive management experience and was the logical choice to lead the next team, using a process-improvement framework called the Team Software Process (TSP). He had all the right technical qualifications, but he did not believe that the TSP would improve his team's performance. As he said, "We're in a hurry and don't have time for that stuff."
When Ken's product was completed, the results were disappointing. Every other TSP team had sharply reduced test defects and cut test time, but Ken's team was very late and spent over half of the schedule in test. Management found that Ken's attitude had cost the company over $1 million. They could no longer afford to use Ken as a team leader. He soon left the company.
What makes impossible goals so damaging is that teams generally strive to meet them, and then they make counterproductive decisions in a panicked attempt to do the impossible. If they had recognized that the goals were impossible and ignored them, they would have been better off. The most common situation is an unrealistically short development schedule. When teams work to impossible schedules, they often race through the requirements and design work so they can start coding. However, with poor requirements and incomplete designs, the schedule problems will only get worse./p>
Thorough planning, responsible commitments, and quality work will generally pay off. The key is for teams to make plans that they are willing to commit to and to then vigorously defend their plans.
When developers are frustrated about their jobs, thinking that the project is badly managed, or are unable to do quality work, they get upset and their performance suffers.
One company had been secretly negotiating a merger with another company, and for legal reasons, they would have to divest some operations. The same week that management announced required overtime, they also announced that this project's division was to be divested. Morale took a nose dive. These developers were now afraid of losing their jobs. Project performance declined so sharply that the customer cancelled the contract and the team was disbanded.
This tip is excerpted from Reflections on Management: How to Manage Your Software Projects, Your Teams, Your Boss, and Yourself, authored by Watts S. Humphrey, with William R. Thomas, published by Addison-Wesley Professional, April 2010, ISBN 032171153X, Copyright 2010 Pearson Education, Inc. For a complete table of contents please visit: informit.com/title/032171153X
For more project management tips, see:
IT management: How to create and lead a committed team
Project management: Scrapping a doomed project
Four things project managers can learn from base coaches
Prioritizing IT projects