Project team & team dynamics

The success of a project depends on the synchronization of a large number of actors, on interdependent activities, within a constrained time frame. This synchronization is not spontaneous. It requires arbitrations, elevation, an overall reading that no actor taken in isolation can produce. Without clear authority to hold this synchronization, a project drifts into cacophony, like an orchestra without a conductor. **Two distinct chains that should not be confused.** On a project, two managerial chains coexist, and confusing their perimeter is one of the most frequent causes of dysfunction. The **organizational chain** is the permanent hierarchy of the company. Its mission is to develop and maintain skills pools in quality and quantity, to define the professional standards that guarantee efficiency and reproducibility, and to provide resources to the projects that express the need. It is a provider of resources. The **project chain** is a temporary hierarchy, constituted for the duration of the project, which uses the resources provided by the organizational chain to deliver the commitments made to the client. Its mission is operational management: framing, arbitrating, synchronizing, reacting to contingencies. The resources it uses depend hierarchically on it only for project usage; their career development, their training, their functional evaluation remain in the organizational chain. **Why consensus decision-making does not work at the project level.** The Theory of Constraints (TOC, formalized by Eliyahu Goldratt) recalls a simple principle: the sum of local optima does not produce the global optimum. Each contributor, left free to make their choices, will naturally optimize their own perimeter, their own workload, their own technical constraints. Nothing guarantees that these local optimizations converge toward the project's delivery on time and on budget. There must be a body that arbitrates at the project level, accepting to degrade certain local optima to preserve the global optimum. **A word on agile methods.** This hierarchical framework does not oppose agility, it applies at a different scale. Agile methods propose a flat organization within teams called squads, whose optimal size is around six people. What works with six people on a self-sufficient cross-functional team no longer works in configurations of 30 to 150 people typical of large projects, where cross-team coordination becomes the dominant challenge. Moreover, the agile stance aims to maximize the value created by teams over a given time interval, which is not the same stance as an end-of-term delivery on a scope contractually committed. The two models respond to distinct contexts and sometimes combine (a project can adopt agile methods within its technical squads while maintaining a project hierarchy at the level of the whole). A large project managed as a flat squad rapidly reaches its ceiling: cross-cutting decisions get stuck, no one carries the arbitrations between teams, synchronization becomes a permanent negotiation without a body that decides. This is a project crash scenario documented since the 1970s and regularly replayed.

The constitution of the project team is not done by distributing names on an improvised organization chart. It follows a logical chain in three steps, which goes back up from the need to be delivered toward the structure that will deliver it. **Step 1: the PBS (Product Breakdown Structure) defines what must be produced.** The PBS decomposes the final product into components, sub-components, and intermediate deliverables, down to a level of granularity that makes the required skills visible. At this step, one identifies the domains of expertise to mobilize (mechanics, software, systems, quality, testing, industrialization, etc.) and estimates the workload volumes per domain. Without this base, everything else is built on sand: one cannot structure a team to deliver something that has not been decomposed. **Step 2: the RAM (Responsibility Assignment Matrix) attributes responsibilities.** The RAM crosses the PBS deliverables with the project roles and specifies, for each deliverable, who is responsible, who contributes, who is consulted, who is informed. This matrix precedes the hierarchical structure: it first describes who does what, before describing who manages whom. Without it, the hierarchy is written without clearly knowing what it has to carry, which gives management lines coherent on paper but unable to answer the simple operational question "who delivers this precise component". **Step 3: the OBS (Organization Breakdown Structure) formalizes the project hierarchy.** The OBS groups the responsibilities identified by the RAM into coherent perimeters, entrusted to intermediate managers (work package leads, technical leads, coordinators) who each carry a team. This structure materializes the project chain and allows the decision flows to circulate. **The span of control principle: how many people can a manager truly manage?** A manager, at any level of the project chain, has a bounded management capacity. This limit has been studied since the work of Vytautas Graicunas in 1933 on organizational relationships, extended by Lyndall Urwick in "The Manager's Span of Control" (Harvard Business Review, 1956). The exact bound varies with context, but a robust principle emerges: the more the processes and activities that the manager oversees are standardized, the higher the number of collaborators they can steer. Conversely, the less the activities are standardized (typically in R&D, in innovative projects, in expert cells), the more the management capacity is reduced. A project manager who must arbitrate unprecedented situations daily cannot usefully manage more than a few direct contributors; beyond that, they become a bottleneck. The solution is to create intermediate levels in the OBS, each with its own decision latitude. **Three attributes per level of the project chain.** Each manager of the project chain, from the project manager to the intermediate manager, is granted three things at the moment of OBS constitution: a responsibility perimeter (which part of the project they carry), a steering granularity (at what level of detail they descend), and a decision latitude (which decisions they can take alone, which must be escalated). An OBS where these three attributes are not explicitly defined for each position produces either managers who micromanage above their level, or paralyzed managers who escalate everything, or both at the same time.

A project chain, even well structured, produces nothing if it is not driven. Team dynamics is the concrete mechanism through which downward flows (framing, order, arbitration) and upward flows (state, analysis, proposal) effectively circulate in the project hierarchy. Without structured dynamics, the OBS remains an organization chart on paper. **Upward dynamics and downward dynamics.** Each manager of the project chain, at their level, participates in two dynamics logics. The upward logic: they participate in the bodies organized by their superior manager (the project manager for a work package lead, the program manager for a project manager), where they report on the state of their perimeter, present their analyses, formulate their arbitration proposals. The downward logic: they organize and lead themselves the bodies with their own N-1, where they frame the priorities, transmit the arbitrations, receive the escalations. Each intermediate level is therefore both driven (from above) and driver (toward below). **Team dynamics is structured by themes, not by a unique catch-all meeting.** A frequent mistake consists in concentrating all team dynamics in a generalist weekly project meeting, where planning, risks, staffing, finances, and quality are discussed in turn without anything being truly treated in depth. On a project, each theme has its own dynamics and deserves its dedicated body, with its own adapted cadence. The typical themes that structure the dynamics of a complex project: - **Planning and progress**, generally weekly, fast cadence because slippages are detected early. - **Risks and opportunities**, generally monthly, slower cadence because the review implies revisiting the risk register and analyzing evolutions. - **Staffing and resource management**, generally bi-monthly or monthly, cadence dependent on the assignment cycles in the organizational chain. - **Financial management**, generally monthly, aligned on accounting closings. - **Quality and compliance**, generally monthly or quarterly depending on the project's maturity and the normative criticality. - **Major milestone reviews (PDR, CDR, intermediate reviews)**, at irregular cadence, aligned on the planning milestones. **An explicit escalation framework.** A well-driven project chain has explicit escalation rules: what type of decision can be taken at what level, in what delay a point not decided must escalate to the higher level, what topics trigger immediate escalation to the project manager or the sponsor. Without these rules, difficult decisions bog down at the wrong levels, or escalate too late, when the decision latitude has already narrowed. The principle is simple: the more the decision commits resources, delay, or budget beyond the decision latitude of a level, the more it must be brought quickly to the level that has the authority to decide. These internal bodies articulate with the external bodies treated in the Stakeholders & coordination hub (project committee, client steering committee, partnership governance bodies). Internal dynamics feeds external dynamics: what escalates in the project chain becomes the material for reporting to stakeholders.