The Fungible Fallacy: Structural impediments to effective project management

Is IT an art or a science? Practitioners seem to be happy leaving questions like these to philosophers. We do like numbers though. Basically, we like to count things. We count users, lines of code, errors, dollars and, one of the coolest things to count, people. We can calculate how many people are needed on a project, how long it will take them to do it, and even what they will cost, all without knowing who they are. The power of math makes individual team member experience and skills unimportant. At least that is how the process works.

Structural Problem One: Our Way Of Counting Staff Can Be Inaccurate And Misleading

Project managers have traditionally had three jobs. The first project manager job is planning the project, including estimating the costs and time needed to complete the work. Planning is needed to sell the project to the users, gain approval, and obtain necessary funding. The second job, once the project is approved, is acquiring the needed staff. This can be a dicey task because needed staff might be committed or assigned to other projects. IT management often plays the major role in deciding who is on what project, with the project manager delegated to a minor role. The third project management job is overseeing the actual work of building the system. 

Project managers have traditionally had three tools for dealing with project estimating and staffing—headcount, person-months, and full-time equivalents (FTEs). Headcount is the actual number of staff on the project at any given time. A person-month is a measure of effort, not time, and is the amount of work one individual can complete in one month. What is nice about person-month is that it is not only countable but you can apply arithmetic operators to it. For example, 10 person-months is half of 20 person-months. A project requiring 100 person-months can be completed in 10 calendar months if the project is staffed with 10 people and completed in 5 calendar months if staffed with 20 people. 

Full-time equivalent (FTE) expresses how many virtual people will be needed to perform the tasks. For example, if an analyst spends 50 percent of his time meeting with users, 30 percent conferring with team members, 20 percent doing administrative tasks such as writing reports and meeting with project management, then the job could be categorized as one-half FTE meeting with users, three-tenth FTE meeting with team members, and one-fifth FTE doing admin. If the project manager wants to have the analyst work 60 percent with users, then she needs to reassign one-tenth FTE to other staff. 

A partial FTE is just what it sounds like, for example a half-FTE is the equivalent of a half-time person, or two quarter-time people or four eighth-time people, etc. In the analyst example, the total work (meeting with users, conferring with team member, and admin) was assigned to one person—one FTE and a headcount of one. However, if staffing is just a math problem, then the job could have just as easily been staffed by a half-time person for the analysis work, a second person at 30 percent working with team members, and two people at 10-percent each working on admin and training. In total, one FTE and a headcount of four. 

Fungibility

Person-months and FTEs work because of a concept called fungibility. Fungible refers to an asset that can be substituted for another asset of the same kind. Fungible objects have no individuation and are interchangeable with all other objects of the same class. For example, U.S. dollars are fungible. If someone owes you 10 dollars then any 10 dollars (one 10-dollar bill, or two 5-dollar bills, or 40 quarters) will do. 

In terms of people, fungibility means that one staff member equals two half-time staff and four quarter-time staff. Fungibility is the mechanism that allows the IT manager and project manager to easily translate FTEs into person-months. 

Taking the Fun Out of Fungibles: The Planning Problem 

Virtually all project planning takes place before the project manager knows who will be staffed on the project and their skills, experience, and salaries. Yet costs and schedules are needed before funding. Most organizations use a standard (cost) model. It might use a generic cost such as all IT staff have a loaded cost of $10,000 per month. Some models are title specific such as: analysts $11,000 per month, designers $10,000 per month, programmers $8,000 per month, project managers $15,000 per month, etc. Standard models, even title-specific ones, assume that all staff in a given category have the same skill level, the same experience, are equally productive, and are paid the same. However, this is never true. Staff skills, experience, productivity, and salaries vary considerably in the typical organization, making standard models problematic. For example, programmer productivity can vary more than ten-fold within the same organization (See “The Most Important Factor in Project Success? Your Staff,” SD Times, June 2020). Therefore, accurate projected numbers cannot be baked into the plan. 

Conclusion One: Real people are not fungible. Costs generated based on the fungibility of staff are, at best, tentative.

But wait, it gets worse.

Structural Problem Two: Team Staffing, Even When Every Team Member Shares The Same Skills And Work Ethic, Might Be Uncountable

You often hear in a movie or read in a novel the refrain, “Put more men on the job.” The phrase is from some confrontation between management and the foreman trying to make the best of a bad situation. The implication is that by adding bodies to the project it will happen faster or at least get done. 

Almost everyone in IT has heard of Fredrick Brooks who, in his monumental book, “The Mythical Man-Month,” confronts the fallacy of just adding bodies to a job to make it finish sooner. Brooks shows that, in fact, added staff can actually further slow down progress. For example, if a 50 person-month project with a staff of 10 is two months behind schedule, adding five more staff might cause it to become three months behind schedule. The math simply doesn’t work. Why? Many reasons. For example, the existing staff have to stop the critical project work they are doing to get the new staff up to speed. Also, numerous studies show that larger teams require more coordination and communication than smaller teams, with the additional time taken away from project work.

Taking the Fun Out of Fungibles: The Communication Overhead Problem

The need for team members to consult with other team members is called communication overhead and is part of the overall project cost in time and effort—even if it is rarely recognized by IT. Brooks and others point out that as staff are added to a project, the communication overhead soars, with some reporting an exponential increase. All of that additional time and effort must to be accounted for, but usually isn’t. The result? You guessed it—the situation goes from bad to worse. 

Assume a team of 21 staff. Using Brooks’ numbers, a team of 21 requires 210 individual staff interactions. If each team member interacts with every other team member once a week for 10 minutes, then 2,100 minutes are consumed each week, or 87.5% of a normal 40-hour workweek. 

Add this wrinkle. Remember FTEs? According to our math the time required to perform some task should be the same whether one person is assigned full-time or four staff are each assigned 25% of the time. The effort should be the same but, owing to communication overhead, it is not. The four people will require more effort and/or more time than a single person doing the job. The problem with FTEs in general, and partial FTE specifically, is that the reality often does not match the math. 

Conclusion Two: Any team larger than one person has to account for communication overhead and the amount of communication overhead depends on headcount, not FTEs, playing further havoc with the fungibility of staff.

What You Can Do About The Project Planning Problem

It is a grave error is to assume that a person is a person is a person—that staff are interchangeable. Person-month/FTE math only works if staff are fungible and, as we have shown, they are not. So why does IT put so much emphasis on FTEs and fungibility? The answer is that IT has little choice because project costs and schedules are often required months before a project starts. Person-month and FTEs are useful, but only at the right time and in the right context. During project proposal or the early stages of project planning, they are often the only means for providing senior management with a ballpark estimate of project costs and schedules. However, they are only useful as a starting point. As soon as actual staff assignments are known, then the project manager should provide more credible numbers. 

It is important that the tentativeness of the project plan, with its FTE-driven budget, be known for what it is—a first-blush look at costs. The project manager, ideally with the help of IT management and the project champion, needs to: (1) explain to the senior user management that the pre-kickoff project plan reflects standard and not real costs and productivity, and (2) review the project plan shortly after kickoff and possibly adjust it to reflect actual project staffing.

Will senior business management go along with this Day 2 project plan review? Maybe not, but even if they do not, at least the project manager has gone on record raising the issue. At the very least, it should help at your court martial.

What You Can Do About The Communication Overhead Problem

Brooks’ model says that a team of 21 people will spend almost 90% of its time comparing notes and little more than 10% doing real project work. There is a partial solution to this problem however—partitioning.

Imagine the 21 person project consists of one project manager and five sub-teams each of four staff, with one sub-team member designated team leader. Each sub-team member communicates with other sub-team members for 10 minutes per week and each team leader interacts with the other team leaders and the project manager for an additional 10 minutes per week. The weekly communication overhead for a partitioned team is 450 minutes per week or 18.8% of a 40-hour workweek. In this example, partitioning the team produced an almost fivefold reduction in communication overhead.

Some project experts are skeptical of Brooks’ formulas. Not every team member needs to individually communicate with every other team member. However, while Brooks’ numbers might overstate the problem, experience has shown that they are directionally correct. Small teams are more efficient than large teams. Turning a single large team into multiple small teams can reduce costs and improve the odds of the project finishing successfully. However, any team with a headcount greater than one must deal with the communication overhead problem, partitioned or not.

Fungibility: The reality of the situation

There are two fungibility problems for the project manager. First, headcount and FTEs play a major role in determining the resources needed to complete a project. However, until the staffing and the structure of the team are known resource requirements are volatile. Once project staffing is finalized, the project manager should review the project plan to determine whether any staffing decisions affect projected project costs or schedules.

Second, team size and team structure play a major role in the resources needed to complete a project. The culprit is communication overhead: the need to keep all team members informed increases significantly as the project headcount increases, potentially playing havoc with costs and schedules. The good news is that communication overhead can be mitigated by partitioning large projects into multiple smaller sub-projects. The bad news is that while communication overhead can be reduced, it cannot be eliminated.