Project management fundamentals

A project, in the sense of international standards, is a temporary endeavor undertaken to create a unique product, service, or result. This definition, formulated in similar terms by the PMI (Project Management Institute) in the PMBOK Guide and by the IPMA (International Project Management Association) in its Individual Competence Baseline, covers as well an apartment move as a space program. What distinguishes them is not their nature but their complexity. A project's complexity is not reducible to its size. It results from the combination of several factors. - **The number of actors to synchronize.** The more contributors there are, coming from different organizations, the more coordination becomes an issue in itself. Beyond a few dozen contributors spread across several entities, synchronization can no longer rely on informal exchanges. - **The density of dependencies between activities.** A project where each activity depends on several others to start forms a dependency network whose reading requires dedicated tooling. The number of activities alone does not predict complexity, it is the number of links between them. - **The level of technical or contextual uncertainty.** A project that uses mature technologies in a stable environment is simple, even if it is large. A project that must integrate an emerging technology, or that evolves in a shifting regulatory context, carries an uncertainty that changes everything: requirements move, estimates become fragile, decisions must be revised along the way. - **The duration of commitment.** A long project undergoes effects that a short project ignores: team turnover, evolution of organizational priorities, cumulative inflation, obsolescence of initial technical choices. Beyond one or two years, these effects become structuring. A project becomes complex as soon as two or three of these factors combine. There is no one-size-fits-all threshold, but a robust principle: as soon as a project exceeds one person's mental grasp of the whole, it must move to dedicated tools and disciplines. This is the shift this site addresses.

Project management is structured around seven major domains that echo each other. None functions in isolation: what is decided in one domain has consequences in the six others. These seven domains are covered in depth in the thematic hubs of this site. **Scope and requirements.** The prerequisite of any management: without a mastered scope, neither schedule nor budget carries any value, because no one knows what they deliver. This domain covers the initial definition of scope, the structuring of requirements, the management of scope changes during the project, and the discipline of progressive freeze of requirements. **Dependencies and scheduling.** Scheduling a project is not about drawing a timeline, it is about mapping a network of dependencies between activities and milestones. This domain covers the concepts of critical path, schedule buffers, dependency matrix, and the methods that make it possible to steer the project's trajectory rather than endure it. This is linXera's signature domain. **Stakeholders and coordination.** A project involves several distinct types of actors: the client, internal management, partners, critical suppliers. Each has its own power asymmetry and its own implicit game. This domain covers the identification and differentiated coordination of these actors, rather than a generic communication plan. **Project team and team dynamics.** The project team is a temporary hierarchy, distinct from the organizational hierarchy that provides the resources. This domain covers the structuring of the project chain (PBS, RAM, OBS), the span of control principle, and the theme-based team dynamics with its downward and upward flows. **Workload and cost management.** A project budget is not a sum, it is a spending curve compared to the schedule. This domain covers the structuring of the budget into distinct envelopes (base cost, contingency reserve, management reserve, change budget), the time-phasing of costs, and the decision of cost allocation. **Risk and opportunity management.** The line between risk and opportunity often comes down to a baseline cursor. This domain covers the distinction between randomness, uncertainty, and risk, the construction of mitigation plans that are actually followed, the sizing of contingency reserves, and the distinction between contingency reserve (protects cost) and schedule buffer (protects duration). **Steering and reporting.** Project reporting can be a steering tool or an administrative ritual. This domain covers the distinction between steering, reporting, and governance, the selection of predictive over backward-looking indicators, and the early detection of drift. These seven domains are not independent silos, they intersect constantly. A scope variation impacts the schedule, budget, and risks. A risk evolution triggers budget arbitrations. Steering reads the state of all domains simultaneously. This interconnection is what makes a project demand an overall reading, not just an expertise domain by domain.

Some terms recur constantly in project management. Knowing them allows you to read any content in the domain, including the hubs of this site, without stumbling on specialized vocabulary. **Scope.** What is committed to be delivered as part of the project. Distinct from the client's need (which may be broader) and from the actual work to be done (which also includes derived non-contractual artifacts). **WBS (Work Breakdown Structure).** Hierarchical decomposition of the work to be done, organized by deliverables. The contractual WBS specifically decomposes what is committed to the client. **Milestone.** A dated event that marks a significant state of project progress: validation of a step, delivery of a lot, engaging decision. A milestone has no duration, unlike an activity. **Deliverable.** Concrete result produced by the project: document, physical product, service, work item. A deliverable can be contractual (owed to the client) or intermediate (necessary for producing a contractual deliverable). **Critical path.** Sequence of activities linked by dependencies whose cumulative duration determines the project's end date. A delay on an activity on the critical path mechanically pushes back delivery. **Baseline (reference plan).** Validated version of the schedule, scope, and budget against which progress and variances are measured. The baseline can be formally revised but does not change according to daily drift. **Buffer.** Time margin explicitly reserved to absorb uncertainty, distinct from the implicit margins of the calendar. The project buffer protects the final delivery date ; feeding buffers protect the junctions of the critical path. **Contingency reserve.** Budget envelope dedicated to absorbing extra costs linked to the materialization of identified risks. Distinct from the base cost and the management reserve. **EAC (Estimate at Completion).** Projection of the project's final cost, obtained by adding the cost already committed to date and a credible estimate of the remaining work. Useful when derived from a serious modeling, useless if reduced to a linear extrapolation. **Change request.** Formalized request to modify the committed scope, with an impact assessment on scope, schedule, and cost. Mandatory gate for any scope evolution after initial validation. This base lexicon is complemented by a broader glossary planned as a satellite article. Each thematic hub develops in depth the concepts that fall within its domain.