Part 1 of this article focused on the structural issues of how staff fungibility (the concept that one staff member can be substituted for another) can impede project management. The project management notions of project-month and full-time equivalent, are used to apply simple mathematical operators to people (e.g., two half-time people equals one full time person). However, the math only works if we assume that all people have the same experience, skills, and work ethic. The project planner relies on the fungibility of staff because actual people are not usually assigned to a project until project approval or kickoff. The project planner has no other choice.
However, the first fungibility problem, and the core of the fallacy of fungibility, is assuming the fungibility of staff when building, managing, or assessing a team after project kickoff. Applying fungibility to real people is error-prone and can lead to eventual project failure.
Second, Fred Brooks, in his book “The Mythical Man Month,” points out that the larger the team, the more individual effort is required to interact with other team members. Multiple people on a team require resources for dividing up work, coordinating effort, and just ensuring that everything that has to be done is being done consistently. The time required to coordinate work is called communication overhead. Fungibility does not take communication overhead into account.
RELATED CONTENT: The Fungible Fallacy: Structural impediments to effective project management
The conclusion of part 1 is that while the concept of the staff fungibility might be a necessary evil for project planning, which traditionally takes place before any staff are assigned to a project or before actual team size is known, it should not be used without significant caution after project approval.
Part 2 points out a sociological problem with assuming staff are fungible, discovered by a 19th century French farmer conducting a tug-of-war.
Part 2: Where None is Better Than Half a Loaf
In the 1890s, Maximillian Ringelmann, a French professor of agricultural engineering, was studying the work accomplished using early farm machinery, and comparing it to the work produced by horses, oxen, and humans. One of his experiments involved a tug-of-war between a man and a scale used to calculate the human’s pulling power. After testing many individuals, he discovered that a single man tugging a rope exerted an average force of 85.3 kg. However, when the same subjects were placed in teams of two, the average force per team member dropped to 93% of when the subject worked alone. When the team size was increased to four, then the force exerted by each team member averaged only 72% of when they worked alone. That number dropped to only 49% for a team of eight.
Ringelmann found that an individual, who is part of a team, puts out less effort to accomplish a task than when he works alone. Further, the effort of the individual diminishes as the team gets larger. This is known as the Ringelmann effect, later renamed, and more popularly called, social loafing. Unfortunately, it took more than 60 years for anyone to show interest in Ringelmann’s work. Then it launched a firestorm becoming a founding pillar of the new science of social psychology.
Subsequent studies by modern researchers found that social loafing is present whether the task is physical (pulling a rope) or intellectual (such as solving math problems). Researchers also found that the level of social loafing was based on a number of factors, not simply team size. Social loafing, they discovered, was most prevalent when team members feel that:
- Their individual efforts did not matter. When one is part of a group, they can feel that their contributions to the group are insignificant and that they have little effect on the outcome of the task. These feelings can lead to worker apathy.
- Assigned tasks are unchallenging. Team members can feel that others on the team are assigned the choice or important tasks, while they were left with the boring or unimportant tasks. Feeling your job is unimportant or that you are not treated fairly in team assignments can lead to social loafing.
- Little satisfaction performing assigned tasks. Being assigned simple and/or unimportant tasks can rob team members of any personal satisfaction of a job well done or appreciation for their contributions. Karl Marx, it turns out, had it right—performing tasks that do not provide personal satisfaction can lead to the alienation of the worker. Alienated workers simply do not work as hard as those who find personal satisfaction in what they do.
- A lack of a united team. Social loafing is more prevalent in team members who feel they are more part of a crowd than of a unified team. They feel little need to help the guy next to them or to “win one for the Gipper.”
Social loafing is certainly a problem for any project manager, playing havoc with the notion of staff fungibility—that all staff produce equal work. Unfortunately, this problem has largely gone unnoticed by the IT profession.
One important finding of the research completed since Ringelmann is that social loading is not inevitable. It is possible to mitigate the effects of social loafing through some social psychology techniques.
What’s a project manager to do?
Understanding the causes of social loafing can help the informed project manager reduce its effect by applying a number of remediation techniques.
- Team size. As mentioned in part 1 of this article, team size is an important contributor to project success—small teams are more productive than large teams. This conclusion is also straight out of Ringelmann and many other researchers. (See “The Big Bang Bust, or Size Does Matter,” SD Times, July 2021)
Small teams give individuals an opportunity to shine. Team member work products are more visible to others and they are often more inline with team goals. Social loafing can be reduced by partitioning big teams into a number of smaller teams, when possible. However, partitioning a team can be a difficult and trying task. Each sub-team needs to provide meaningful and unique work for its staff while minimizing the communications needed across sub-teams.
- Team spirit. The team should function as a single-minded unit. One of the functions of military basic training is to instill a sense of camaraderie among new recruits—a feeling that they are all in it together. Shared experiences, even negative ones, bond disparate recruits into a unified team that supports and trusts each other. In the business world the same is accomplished with team building exercises.
A crowd is a group of individuals in the same place at the same time. A team is a group of people working together to achieve a common goal. Projects work better with teams than with crowds. Unfortunately, people assigned to a new project might not have previously worked together or even know each other. For all practical purposes they are a crowd. If things go well, over time, the crowd will learn about each other, identify strengths and weaknesses, instill trust, and eventually coalesce into a team. The purpose of team building exercises is to shorten the time it takes to turn a crowd into a team. A good team building exercise can start, if not achieve, that in as little as an afternoon.
Team building exercises can be complex, requiring a large indoor space, considerable props, and overseen by outside behavioral experts; or as simple as an hour or two spent in a conference room with an HR trainer. In both cases, the participants are asked to work with others on small and ideally amusing tasks that demonstrate the benefits of working together. In addition, the hopefully fun nature of the exercise, will generate a sense of camaraderie and familiarity among the participants. Team building exercises have successfully built team esprit de corps or group spirit through simple shared experiences.
Formal team building exercises work well at the beginning of the project. Mid-project pizza parties, softball games, laser tag, and Friday night “programmer meetings” at a local pub, can contribute to a well-oiled team.
- Challenging individual tasks. Each team member should be assigned unique challenging tasks.
One of the project manager’s most important jobs is staffing—assigning team members to project tasks. For many project managers staffing consists of two components: (1) examining the task to be performed and (2) finding someone who can do the job. Sort of plugging work holes with people. But there is more to staffing than that. Project managers also need to (3) be aware of the individual’s personality and work history (too heavy, too many boring tasks, not in the team members skill set, etc.) and assign work based on team member personal dynamics as well as skills. And don’t forget development needs. Some tasks should be dead set in the individual’s strike zone—what they do best. But other tasks should stretch the individual, to learn new skills or expand existing ones.
Every project has boring and workaday tasks that need to be completed. Managers should ensure that these less popular tasks are evenly distributed among team members. No one should be assigned only boring tasks or only the more popular or challenging ones.
- Measure, evaluate, and communicate each team member’s performance. The performance of every team member should be objectively assessed and feedback provided to the team member.
In these modern times, project managers are very familiar with HR. There was a time when the personnel department was only involved in hiring and benefits. Now there are a whole range of HR activities that involve the project manager. Have a problem worker? Well HR will require that you document the poor behavior or work. Detailed documentation is necessary before formally chastising or firing a worker. But the good worker? Well HR’s folder on him or her is much smaller. The fact is we spend far more time on the problem child than on the good one. This is a grave disservice to the good worker.
Every team member should know exactly what his or her team leader and project manager thinks of their work. This evaluation should be objective and conveyed to the team member in a timely manner. It is of little use if their only assessment is at the end of the project. The team member should have sufficient time to correct deficiencies and improve performance before the project ends.
- Recognize individual work. IT loves praising work. We have done our share to keep the tee-shirt, coffee mug, and mousepad industry in business. Every milestone—project kickoff, first system test, starting beta etc.—involves another tchotchke. However, users and IT management praise usually stops at the team level. Individual praise is less common.
No one is suggesting that you praise mediocre performance. This is not summer camp where everyone wins a trophy. However, there is a lot of good work going on between star performers and deadbeats. The yeomen on the team should be recognized for their individual contributions and given a little pat on the back for their achievements. You don’t need to award a tee-shirt, but you should recognize individual contributions. Praise is good but can be overdone. The operative word is more recognition than praise. Individual team members should feel that project management knows who they are, what they do, and their contribution to the project.
Fungibility: The reality of the situation
First, fungibility and its associated concepts of person-month and full time equivalent, are useful when estimating the work required to complete a project. However, their value diminishes significantly once the project starts. Actual team members and actual team size are not fungible. Keeping the fungibility notion alive after project planning can be a costly mistake.
Second, recognizing the causes of the fungible fallacy can help the project manager mitigate them, even if they cannot be eliminated. When to use fungible concepts, attention to team structure and size, and the proper treatment of staff can go a long way to minimizing the fungible fallacy.
