Versione Italiana

3C Modeling with FTEC and Logarithmic Dynamics

Model Author

© 2025 Domenico Simone Marsella

All rights reserved. The 3C Model, FTEC, and related formulas are intellectual property of the author.

1. Introduction and Objective

Managing complex projects, especially in IT, requires a clear understanding and balance between three fundamental factors, known as the 3Cs:

From these three pillars stem time planning, budget, and risk management. The purpose of this publication is to provide a model that shows:

2. The 3C Model: Cost, Capacity, Complexity

The heart of the model is based on the regime formula:

\[\frac{\text{Cost} \;\Leftrightarrow\; \text{Capacity}(\text{Complexity})}{\text{Time}} = R\]

Where \(R\) represents the state of "regime" (equilibrium). If Cost, Capacity, and Complexity remain coherent, the project proceeds within the expected timeframe. If something becomes unbalanced, a deviation occurs and time begins to grow non-linearly.

Graphical representation of the 3Cs

Complexity (X) ↑ │ │ ┌───────┐ │ │ │ Capacity (K) <────┼─────┤ R ├────> Cost (C) │ │ │ │ └───────┘ │ ▼ Time (T)

3C Model - Graphical Representation

R Complexity Cost Capacity Time

Under optimal conditions:

In this situation, the project remains in regime. If Complexity turns out to be much higher than estimated, or Capacity is lower, the actual Cost may overrun and/or Time extends.

3. The Regime Formula and Logarithmic Effect

When the ratio between Cost and Capacity, at equal Complexity, becomes unbalanced (deviation \(E\)), time extends in a non-linear manner:

\[T_{\text{eff}} = T_0 + \alpha \,\ln\!\Bigl(1 + \beta\,E\Bigr)\]

Where:

Rationale: In project management, delays and overruns generate overhead, rework, and confusion, which accumulate logarithmically. It's not an immediate explosion (exponential), but a progressively more onerous extension.

4. FTEC Definition

To calculate project Capacity transparently, we introduce the FTEC (Full Time Equivalent Container):

  1. It's a container of 40 weekly hours
  2. It's serialized: different roles (analyst, developer, tester, etc.) don't work simultaneously on the same container, unless there's internal scaling
  3. It includes overhead evaluation: if 4-8 hours are lost weekly in meetings and interruptions, we can set \(E=0\) as 32-36 effective hours

Objective: avoid naive summation of "person-days" (which would inflate capacity), and consider that, in fact, "real time" is singular.

5. Role Serialization and Internal Scalability

Different roles work in sequence within the FTEC:

┌─ FTEC (40 weekly hours) ──────────────────────────┐ │ │ │ ┌─────────┬────────────┬─────────┬─────────┐ │ │ │ BA │ Dev │ QA │ ... │ │ │ │ (10h) │ (20h) │ (10h) │ │ │ │ └─────────┴────────────┴─────────┴─────────┘ │ │ │ └───────────────────────────────────────────────────┘

FTEC - Graphical Representation

BA Dev QA ... (10h) (20h) (10h) FTEC = 40 weekly hours

If you allocate 10 hours to BA, 20 to Dev, 10 to QA in the week, the sum is 40. There's no "parallel" between different roles.

Internal scalability: If you have 2 developers (duplicated Dev role), in that 1-hour slot, 2 Devs work simultaneously, producing 2 "person-hours" of development.

Formally:

\[\text{Person-hours}(i) = c_i \,\times\, T_i\]

where \(c_i\) is the number of parallel resources in role \(i\), and \(T_i\) the clock hours allocated to that role.

6. Cost Estimation in FTEC

Cost of a Role

If role \(i\) has hourly cost \(\rho_i\) and counts \(c_i\) people, and \(T_i\) clock hours are dedicated to it within the FTEC:

\[\text{Cost}(i) = (\rho_i \times c_i) \times T_i\]

Cost of an FTEC

\[\text{Cost(FTEC)} = \sum (\rho_i \times c_i) \times T_i \quad \text{with} \quad \sum T_i \leq 40\]

7. Capacity(Complexity): Mathematical Formalization

Operational Load of Roles (\(H_i\))

A project may require "\(H_i\) person-hours" to complete tasks for role \(i\). For 1 FTEC to be sufficient, we need:

\[\sum_i T_i \leq 40\] \[c_i \times T_i \geq H_i, \;\forall i\]

If these conditions are not met, 2 FTEC, 3 FTEC, etc., are needed. In fact, you can represent the function "how many FTECs are needed" based on complexity (total person-hours).

8. Governance and Architecture: Improving Quality, Not Quantity

Adding governance roles (Architect, PMO/Scrum Master, BA/QA Lead) doesn't increase the 40 weekly hours, but can:

Formally, you can introduce a "Lead" role with time \(T_{\text{Lead}}\) that reduces \(H_{\text{Dev}}, H_{\text{QA}}, H_{\text{BA}}\), improving efficiency. It's a trade-off within the same 40 hours.

9. Graphical Representations

3C Graph (ASCII)

We can imagine a cube diagram where the three axes represent Cost (C), Capacity (K), Complexity (X):

Complexity (X) ↑ | (K)<---- Regime ----> (C) | | Time (T)

Where we position ourselves on the "plane" defined by K and C, and Complexity shifts the "height" of the regime. If Complexity increases at equal Capacity, Cost must rise or Time dilates.

Number of FTECs needed (Step Function)

If the maximum capacity of 1 FTEC (distributing the 40 hours optimally among roles) is, for example, 64 person-hours, then the function that returns "FTEC_needed" based on Complexity results in:

FTEC_needed(complexity) 3 ┤ ┌────────── (≥ 129 person-hours) │ │ 2 ┤ ┌───────┘ (65-128 person-hours) │ │ 1 ┤───────┘ (≤ 64 person-hours) │ └┬─────┬─────┬─────┬─────┬─> Complexity 0 50 100 150 200

Complexity-FTEC Relationship - Graphical Representation

Complexity (person-hours) FTECs needed 1 2 3 (≤ 64) (65-128) (≥ 129)

10. Conclusions

The presented model provides an integrated approach covering several fundamental aspects of project management:

3C Model

The balance between Cost, Capacity, and Complexity is crucial. Any deviation produces a non-linear delay that follows a logarithmic curve, potentially compromising project success if not managed appropriately.

FTEC and Serialization

The introduction of the FTEC concept as a 40-hour weekly container helps avoid the additive overestimates typical of the "person-day" approach. Role serialization, with the possibility of internal scaling for specific roles, offers a more realistic model of the team's actual capacity.

Cost Management

The model provides a clear structure for cost estimation, considering both scenarios with internal teams and mixed situations with external consultants, through the role and FTEC cost formula.

Capacity and Complexity

The mathematical formalization of the relationship between capacity and complexity allows objective determination of when scaling with additional FTECs is necessary, avoiding overload and maintaining work quality.

Role of Governance

The integration of governance and architecture figures represents a strategic investment that, while remaining within the same FTEC container, can significantly improve overall efficiency by reducing errors and overhead.

Logarithmic Effect

Understanding the logarithmic effect on time in case of imbalances emphasizes the importance of maintaining the project in regime, highlighting how small initial deviations can lead to significant temporal dilations in later phases.

In conclusion, this model offers a comprehensive framework for planning and controlling IT projects, avoiding common traps of capacity overestimation and complexity underestimation. Its practical application can significantly improve the accuracy of estimates and resource management.