Ads
  

Parts Need to Work Together

Parts Need to Work Together

Apparently clear but frequently overlooked is the importance of choosing a good team (when possible) and preparing the members for the project. The majority of projects fail because the team never "jells". Many times, project leaders are given team members based on personnel availability rather than being able to choose them. However, preparation by the project manager to understand individual personalities and team dynamics is the key to creating a successful working group.

Hire for Trait and Train for Skill

It is much easier to start with a positive, jelled team that might become worse later than to start with a dysfunctional team in the first place. Whenever possible, select team members for their compatible and complementary personality traits rather than their demonstrated skill in a specific area. This seems contrary to popular belief at first, but it makes sense when you understand that it is easier to train people in a new technical (and often rapidly changing) skill than to change their personality. The majority of people enjoy learning new things anyway. The training need not be formal. The general ability to quickly learn and adjust to constantly changing information is frequently more valuable than deep experience in one or two skill areas, assuming that basic ability in the core technologies. Of course, if the person's personality does not fit the task, stress results and less desirable characteristics begin to appear.


McFletcher WorkStyle Patterns Inventory

A useful instrument for explaining behavior is the WorkStyle Patterns Inventory (WSPI) from the McFletcher Corporation. The purpose of the assessment is to discover how a person prefers to approach work versus the approach that the position or current assignment requires, and it may be administered by a facilitator certified by McFletcher. Analysis of discrepancies between a person's preferred workstyle and their actual workstyle can create various degrees of stress, which may be manifested in a variety of ways.

McFletcher describes two kinds of stress: personal and organizational. Typical personal responses to stress include indifference or low productivity, irritability and frequent complaints, and health disorders or illnesses. Personal stress generally occurs because you want to perform more activities of a particular kind than the position requires.

Organizational stress can be observed through misunderstandings of work expectations, product quality and customer service problems, missed deadlines, and high turnover. Organizational stress may result when the position requires more activities of a specific kind than you are inclined to perform.

According to the inventory, a person may fall into one of the categories indicated in Table 1.

McFletcher WorkStyle Inventory Model

Each of these profiles is explained in depth, and the contribution to the organization of each is described in the inventory booklet. The inventory (questionnaire) scores are graphed as a difference of preference versus actual position, as shown in the example in Figure (a).

Sample McFletcher WorkStyle Inventory

The sample graph in Figure (a) indicates profile scores for a team leader with a preferred workstyle of independent worker and an actual position workstyle of supervisor. He prefers to work independently through managing his own work. The position requires coordinating the work of others. Perhaps the team leader wants to perform more direct computer work, whereas his position requires more coordinating, coaching, and scheduling activities than he is inclined to do. This is typical for many technologists promoted to a position of leadership. This team leader may want to think about obtaining some coaching or even making a job change.

The work styles of each team member may be plotted on a summary chart, validating a complementary mix of work styles or exposing a difference or imbalance. For instance, if everyone wants to redesign the health-care system, there may be no one left to administer care to the patient.


The Skill Gap

Again, a leader's ability to quickly assess a person's personality characteristics will go well beyond the one-sided balance sheet of accomplishments called a resume. Actually, resumes can be terribly misleading.

When Bill Curtis, a behavioral scientist and coauthor of the Capability Model for Software, was at ITT in the early 1980s, he conducted a study of how the skill of programmers could impact a technical project schedule. He seeded a Fortran program with bugs and then timed a sampling of ITT's programmers on how long it took them to find all the seeded errors. All of the participants were Fortran programmers by trade. The results were astonishing. The differences in technical skill performance varied by 20 to 1. That is, it took the worst programmer 20 times longer to find the bugs than the best programmer. This kind of variation has more impact to a project than any method or process followed. Imagine trying to build and hold to a plan with this kind of variation underlying the schedule!

Curtis also discovered that there was little correlation of skill, as measured by the test, to the individuals education, experience, and qualifications as represented in their resumes. This exposure means that it is important for the project manager to understand the subtleties of personality differences. Managers/leaders who are trained in motivational theory are better at observing different types and responding to their needs. When appropriate, such managers are also capable of employing professional personality-typing instruments to deepen understanding of the team's needs. Examples of such instruments are those offered by Alignment Products and Processes from the previously mentioned McFletcher Corporation.


Understand Group Dynamics

A leader must recognize how teams form to be able to lead them correctly. A well-known model of team structure is the five-stage model shown in Table 2.





This model represents the process of how a group decides on its operating profile. The profile is different for every group and is time- and place-dependent. This is why there is one set of accepted behavior for team members in a project meeting and a different set at the local pub, even though membership may be the same.

Every team experiences this cycle and frequently repeats it many times during the course of a project. Each time a new member joins the team or an old member departs, the team norms must be recalibrated for the new team situation. The stages needn't take place in order, either, as some teams cycle back and forth between them. Teams may iterate between storming and norming many times before moving on to performing. Occasionally, this is misinterpreted as a Dr. JekylltoMr. Hyde transformation taking place. It is the leader's responsibility to recognize the state of the team at any moment and take actions that will move the team toward the performing stage in the least amount of time, using the correct techniques for each personality type.


Recognize Teamicide

Teamicide is the result of group dynamics in the organizational environment that become stuck in the storming stage, causing the members to retreat into the roots of their personalities, frequently in a hostile way. DeMarco and Lister devoted an entire chapter in their book, Peopleware, to "Teamicide", referring to it as the inhibition of team creation and the disruption of project sociology. They list teamicide techniques as environmental things that a leader should watch for to avoid killing teamwork. These comprise self-protective management, bureaucracy, physical separation, fragmentation of people's time, quality reduction of the product, phony deadlines, and clique control.

A technical project leader should look for signs that any of these are happening and take action to correct them instantly. DeMarco and Lister give us some hints:

●   Defensive management - Allow the staff to make their own decisions, even if they sometimes make a mistake. Giving them the freedom to make errors is a sign of trust.

●   Bureaucracy - Avoid turning developers into bureaucrats. Allow the team to believe in its own goals, and express your belief in it (and them) as well.


●   Physical separation - Place workers together so that casual interaction may happen. When people are on the same team, they tend to go into "quiet mode" at the same time and suffer less interruption of their thought flow.

●   Fragmentation of time - Limit the number of projects, and, therefore, teams, that a person is assigned to. There is high overhead in "switching gears" when moving from one team culture to another.

●   Quality reduction of the product - A developer's self-esteem suffers when he is required to build a product of lower quality than what he is capable of. Don't allow "cost-reduced" products to become "quality-reduced" products. Promote a sense of pride.

●   Phony deadlines - Tight deadlines are sometimes a necessity and can even present an enjoyable challenge to the team. However, phony deadlines are not tight deadlines, and teams know the difference.

●   Clique control - Managers don't generally work in jelled teams. Instead, they achieve peer acceptance via roles. Even so, the importance of allowing a team to remain together should not be forgotten as one moves up the management ladder. On jelled teams, team activities are pleasurable, and energy is produced by team interaction.



Tags

project manager, jelled team, organizational stress, teamicide
The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.
Copyright 2018 SPMInfoBlog.
Designed by TechPlus