i

Description

Un plan d'aménagement général d'une ville, dessiné avant le chantier

Source

BJGunnaban · original page

Licence

CC0 Public domain

Original photo, unretouched. The background is a version of it stylised by the site.

Project Management Fundamentals

You will be able to define a project, its life cycle, its constraints (the triangle, then the “quadruple constraint”), and its roles, without academic jargon.

In brief

• You will be able to define a project, its life cycle, its constraints (the triangle, then the “quadruple constraint”), and its roles, without academic jargon.
• You will be able to distinguish predictive and adaptive steering, and choose based on the level of uncertainty (Cynefin framework).
• You will be able to reason in terms of value, risk, and stakeholders, and not only schedule and cost.
• You will understand what changes for an IT project, then for a data / BI / datamart project, where data quality is the real deliverable.
• This file is the common foundation: Scrum, predictive methods, and agile methods all build on it.

On this page

1. 🟢 Novice — What is a project?
   1. Succeeding: three levels of success
2. 🟢 Novice — The life cycle of a project
   1. Product life cycle vs. project life cycle
   2. The three main ways to sequence phases
3. 🟢 Novice — Triangle and quadruple constraint
   1. What the triangle means in practice
   2. The agile variant: fix time and cost, vary scope
4. 🟢 Novice — Roles
   1. MOA and MOE, Francophone vocabulary
   2. Responsibility, authority, accountability
5. 🟡 Practical — Predictive or adaptive
   1. Hybrid approaches
   2. Predictive or adaptive: a 5-question test
6. 🟡 Practice — Value and Benefits
   1. Business case
   2. Prioritize by value
7. 🟡 Practice — Manage Risk
   1. The four classic responses
   2. Criticality
   3. Agility is risk management
8. 🟡 Practice — Stakeholders and Communication
   1. Communicate: minimal plan
9. 🟡 Practice — Specifics of IT projects
   1. The historical observation
   2. Ingredients of modern IT maturity
10. 🟡 Practice — Data project specifics in brief
11. 🔴 Expert — Uncertainty, Cynefin, and method selection
    1. The “cone of uncertainty”
    2. Stacey and the complexity zone
12. 🔴 Expert — The triangle is a useful lie
    1. The three laws that defuse illusions
13. 🔴 Expert — Delay economics, cost of delay, and real options
    1. Cost of Delay
    2. Delay decisions, buy options
    3. Little's Law and flow
14. 🔴 Expert — Laws and biases that shape projects
    1. Psychological safety
15. AI contribution
16. See also

Level: 🟢→🔴

🟢 Novice — What is a project?#

A project is a temporary effort (identifiable start and end) that produces a unique result (a product, a service, a change) within given constraints. Two words matter: temporary (as opposed to operations, which are recurring) and unique (even if we have already done “something comparable,” the context, team, and data differ).

This common-sense definition matches those in standard frameworks (PMBOK from PMI, PRINCE2, ISO 21500/21502). You do not need to cite them to work: remember that a project is justified (why?), bounded (what, how far, with what?), and ended (how do we know it is finished?).

A project exists only if it has a sponsor (who pays and decides), a verifiable objective, and a team. Without an identified sponsor, it is an “initiative” that will drift; without a verifiable objective, you will never know whether it succeeded.

Succeeding: three levels of success#

A project can succeed at three independent levels:

1. Management success: delivered on time, on budget, within scope. Measurable at closure.
2. Product success: the deliverable works, is used, and is high quality. Measurable at delivery and after.
3. Business success: expected benefits are realized (better-controlled sales, time saved, better decisions). Measurable months later.

A datamart delivered on time (success 1) that no one trusts (failure 2) produces no benefits (failure 3). The reverse also exists: a “late” project that changes the business. Mature project management measures all three.

🟢 Novice — The life cycle of a project#

Every project goes through phases, explicitly or not: we decide to do it, prepare it, execute it, put it into service, and close it. Methods differ in how these phases are sequenced, not in whether they exist.

Monitoring is not a phase but a cross-cutting thread. Likewise, change management (training, adoption) starts at scoping, not at acceptance testing.

Product life cycle vs. project life cycle#

We must distinguish:

• the project life cycle (from idea to closure);
• the product life cycle (design → operations → evolution → retirement) — often much longer.

A project is one episode in a product’s life. Ignoring the “operations and retirement” phase during design is the classic source of debt: you deliver quickly, then pay for ten years. This “total cost of ownership” view justifies including support, monitoring, documentation, and a retirement plan for old versions from the scoping stage onward. For delivery and operations practices, see CI/CD and its counterpart CI/CD for data: foundations, datamarts, pipelines, and reports.

The three main ways to sequence phases#

Method details are in Predictive Methods (waterfall, V-model, spiral, RUP, PMBOK, PRINCE2, Merise, CMMI) and Agile and Lean Methods (Manifesto, Kanban, XP, Lean, Shape Up, DSDM, SAFe, DevOps…).

🟢 Novice — Triangle and quadruple constraint#

The iron triangle (or project management triangle, “iron triangle”) sets out three interacting constraints: scope (what is delivered), schedule (when), cost (with what resources). Changing one moves at least one other. Quality sits at the center: sacrificing it is the hidden adjustment variable.

The PMBOK later expanded this to six constraints (scope, schedule, cost, quality, resources, risk): people sometimes speak of a “quadruple constraint” by adding quality; agile offers a useful variant (see below).

What the triangle means in practice#

The agile variant: fix time and cost, vary scope#

The agile triangle reverses the dogma: schedule (the timebox) and cost (team size) are fixed, and scope is allowed to vary by ordering it by value. Quality is non-negotiable (the Definition of Done is a floor). This is the deeper meaning of a sprint: the least useful 20% of scope drops first, not quality.

🟢 Novice — Roles#

Whatever the method, you find the same functions, even if methods name them differently. Distinguishing function from title avoids sterile debates (“project manager” versus “Scrum Master”).

MOA and MOE, Francophone vocabulary#

In France, people speak of MOA (maîtrise d'ouvrage: the client, who expresses the need and validates) and MOE (maîtrise d'œuvre: who delivers). The gap between the two is a major source of misunderstandings: MOA “throws requirements over the wall,” MOE delivers, and acceptance testing reveals the gaps. Agile methods reduce this divide by integrating a business representative into the cycle (Product Owner, users in reviews), which is exactly the benefit sought. In a BI context, the data Product Owner (see Scrum Applied to Data, BI, and the Datamart) plays this bridge role.

Responsibility, authority, accountability#

Three words not to confuse. Responsibility (doing), authority (deciding), and accountability (“being answerable”) must align. A project manager accountable for outcomes but without authority over scope or team is in an untenable position. Scrum resolves this by naming a single Product Owner with authority over content (and accountable for value), and a self-managed team responsible for how to deliver. The RACI model (Responsible, Accountable, Consulted, Informed) formalizes the same idea in table form: only one “A” cell per row.

🟡 Practical — Predictive or adaptive#

Approaches sit on a continuum between two poles.

Neither pole is “good.” A regulated building construction project is run predictively; a sales-force application with unknown usage is discovered adaptively. The real danger is a method mismatched to uncertainty: detailed planning on unknown ground, or improvising on a regulated, irreversible topic.

Hybrid approaches#

In real companies, you almost always mix: predictive framing and annual budgeting at the top, iterative execution at the bottom (sometimes called “water-scrum-fall” when it is imposed rather than chosen). The useful question is not “pure or hybrid?” but “where do I put predictability and where adaptation?”. The details are in Choosing Your Method and Hybridizing and the Comparison of Project Management Methods.

Predictive or adaptive: a 5-question test#

1. Is the need stable and well understood on both sides? (yes → predictive)
2. Is the technical solution known and already proven? (no → adaptive)
3. Is the cost of an error discovered late prohibitive (regulatory, physical, irreversible)? (yes → predictive in those areas)
4. Are users available for frequent feedback? (no → adaptive will not deliver its benefits)
5. Does the funder accept value-driven steering rather than scope-driven steering? (no → plan for a predictive governance layer)

🟡 Practice — Value and Benefits#

Value is what justifies the project. It is not the delivered scope: it is the benefit achieved by those who use what is delivered.

A team that tracks only outputs optimizes activity; a team that tracks outcomes optimizes usefulness. This is the shift agility proposes: moving from a feature factory to an outcome-oriented team.

Business case#

A business case answers: what problem? what benefits (quantified or qualitative)? at what total cost? what risks? what is the “do nothing” alternative? It must be reviewed at milestones: a project whose justification has collapsed must be able to be stopped without shame. PRINCE2 makes this a principle (continued business justification). For budget steering and team-side value, see the matrix Budget, Value, and Benefits (VAL).

Prioritize by value#

Several tools, to be combined with critical thinking:

• MoSCoW (Must / Should / Could / Won't): simple, but everything becomes “Must” without firm trade-offs.
• Cost of Delay and WSJF (Weighted Shortest Job First) = cost of delay ÷ duration: handle first what loses the most value per unit of waiting time.
• Value × confidence ÷ effort (ICE/RICE variants): useful, but initial numbers are estimates; do not give them a precision they do not have.
• Kano: distinguishes basic, expected, and delighting needs.
• Story mapping: view the user journey to decide “the smallest increment that makes sense.”

🟡 Practice — Manage Risk#

A risk is an uncertain event that, if it occurs, has an effect (positive or negative) on objectives. A risk is not an issue: an issue is already here (you address it), a risk is probable (you anticipate it). Confusing the two creates “risk registers” that are actually issue lists.

The four classic responses#

Criticality#

Criticality = probability × impact, on simple scales (1 to 5). Prioritize by descending criticality; do not exceed about fifteen actively tracked risks. A risk is alive: name an owner, a review date, a trigger (warning signal), and an action.

Agility is risk management#

Short iteration is the best response to design risk (building the wrong product): you discover it in two weeks rather than two years. By itself, it does not address architecture, security, or compliance risk, which require explicit guardrails (spikes, reviews, constraints in the Definition of Done). The risk chapter of the matrices is in Risk Management (RSK).

🟡 Practice — Stakeholders and Communication#

A stakeholder is any person or entity that can affect the project or be affected by it. Identify them, understand their expectations, decide what to do with them.

The power × interest grid (Mendelow) is the most common:

Communicate: minimal plan#

The goal is transparency: the earlier a gap (delay, quality concern) is reported, the less it costs. A project that is “all green” until the last month almost always hides unreported information (the “watermelon syndrome”: green outside, red inside). Useful indicators are presented in Project Metrics and Reporting. The corresponding matrix theme is Stakeholders and Communication (PAR).

🟡 Practice — Specifics of IT projects#

An IT project has traits that set it apart from a construction or manufacturing project: it produces an intangible object, copyable at zero cost, continuously modifiable, whose complexity is invisible (code cannot be seen, it is read).

The historical observation#

Survey reports on project failures (such as the Standish Group's CHAOS Report) strongly shaped the debate, but their methodology is contested. They should be cited cautiously: the key idea is that large projects planned all at once with fixed scope fail more often than small projects delivered in stages, which is supported by other sources (including the experience behind the Agile Manifesto). So we should avoid relying on a precise percentage.

Ingredients of modern IT maturity#

• Small batches: smaller batch, less risk, more feedback (Lean principle).
• Automation: repeatable builds, tests, deployment.
• Fast feedback: at every level (tests, code review, sprint review, monitoring).
• End-to-end ownership: “you build it, you run it” (DevOps vision).

Research by the DORA team (Accelerate, and the annual “State of DevOps” reports) showed that deployment frequency, lead time for changes, change failure rate, and time to restore service are indicators correlated with organizational performance. These are the “four key metrics”; see CI/CD for how to use them.

🟡 Practice — Data project specifics in brief#

A data project (datamart, warehouse, reporting) shares everything above, but the deliverable is a set of numbers that must be trustworthy. Details are in Scrum and data and Methods Specific to Data Projects. In short:

🔴 Expert — Uncertainty, Cynefin, and method selection#

The Cynefin framework (Dave Snowden) classifies situations by the relationship between cause and effect, and prescribes an appropriate way to act. It is valuable for selecting a method because it reminds us that there is no universal method: there are problem types.

Reading for project management:

• Clear / complicated: predictive methods and detailed planning work; expertise is enough, you can estimate, standardize, automate.
• Complex: agility (experiment, inspect, adapt) is the right tool — this is Scrum's territory, whose foundation is precisely empiricism.
• Chaotic: stabilize first (crisis management), then analyze.

A single project contains all four domains in different places. Scrum does not eliminate the complicated (expertise is still required), it frames the complex.

The “cone of uncertainty”#

Boehm illustrated (and McConnell popularized) the idea that uncertainty on cost and duration is very wide at the very beginning of a project and narrows as you move forward. The exact shape and numerical factors are debated and context-dependent; the robust message is: an estimate made before exploration is a wide range, not a commitment. Committing to a single number during framing is a governance act, not a measurement.

Stacey and the complexity zone#

The Stacey matrix combines degree of agreement on the need and certainty about the technical approach. When neither is established, you are in “complexity,” and prescriptive methods fail. This framing justifies investing in discovery (workshops, prototypes, spikes) before committing to scope.

🔴 Expert — The triangle is a useful lie#

The iron triangle is an excellent teaching tool and a poor predictive model:

1. Scope is not homogeneous. Twenty requirements do not have the same value: in the vast majority of cases, a small fraction carries most of the value (common order of magnitude, not a law). Talking about “scope” as a block hides the essential trade-off.
2. Quality is not a continuous variable. There is a floor below which no value is delivered (wrong numbers, failed security). And internal quality (maintainability) influences future lead time: sacrificing it borrows from the future at a high rate.
3. Schedule and cost are not independent of scope through a linear law: the relationship is non-linear (Brooks's law, coordination costs, Parkinson's law).
4. The triangle ignores value and risk, even though they are what justify the project.

The alternative is a “diamond” or a richer view: value, risk, quality, duration, cost. In an agile framework, you steer delivered value per unit of time and residual risk, while schedule and cost are fixed by design.

The three laws that defuse illusions#

The critical chain method (Goldratt) draws a consequence from this: individual margins are removed and pooled into a project buffer, whose consumption is monitored. It is presented in Predictive Methods (waterfall, V-model, spiral, RUP, PMBOK, PRINCE2, Merise, CMMI).

🔴 Expert — Delay economics, cost of delay, and real options#

Cost of Delay#

Don Reinertsen (The Principles of Product Development Flow) argued that the most overlooked economic factor in development is cost of delay: value lost per unit of delay time in a delivery. From this he derives WSJF:

Three cost-of-delay profiles illustrate the diversity:

Delay decisions, buy options#

The real options approach applies financial logic to project decisions: an irreversible choice made early is paid for through lost flexibility; postponing until the last responsible moment (last responsible moment, an expression popularized by the Lean/agile community) preserves options at lower cost. This is not indecision: it's deciding when information is best, before the cost of waiting exceeds the cost of being wrong.

Concretely for data: choosing a fact table's granularity or a dimension's surrogate key is costly to reverse (all consumers depend on it) — do it early but with full awareness. Choosing a report's visual is inexpensive to change — you can delay and iterate.

Little's Law and flow#

Little's Law (queueing theory) links the quantities of a system in steady state:

Direct consequence: to shorten lead time without changing throughput, you must reduce work in progress. Starting more things slows each one down. This is the mathematical foundation for Kanban WIP limits and Scrum's preference for limited-scope sprints. See Agile and Lean Methods (Manifesto, Kanban, XP, Lean, Shape Up, DSDM, SAFe, DevOps…).

🔴 Expert — Laws and biases that shape projects#

Psychological safety#

Amy Edmondson's work on psychological safety (the belief that people can speak up, report an error, or express doubt without being punished) and Google's “Aristotle” project are often cited to show that the quality of team interactions matters more than team composition. In practice: a project manager who punishes bad news gets green status reports until collapse. Team culture is measured in the matrix Team and Collaboration (EQU).

AI contribution#

Example prompts:

• “Here is the context of our project [anonymized summary]. List ten risks we did not mention, ranked by probability and impact, and for each one an early warning signal.”
• “Review this business case like a skeptical CFO: which assumptions are unsupported?”

What AI does not replace: judgment about value, trade-offs among stakeholders, accountability for the decision, and knowledge of your history and culture. It must not receive unauthorized confidential data. Watch out for hallucinations (plausible but false facts, references, or numbers) and hidden debt (plans produced without team ownership). See AI for Project Management (General Then Data).

See also#

• Logical next step: Scrum, the framework (Scrum Guide 2020) then Scrum in Practice.
• Other approaches: Predictive Methods (waterfall, V-model, spiral, RUP, PMBOK, PRINCE2, Merise, CMMI), Agile and Lean, Comparison of Project Management Methods, Choosing Your Method and Hybridizing.
• Cross-functional pitfalls: Pitfalls and Good Practices in Project Management (Cross-Functional Synthesis).
• Measure your practice: Maturity Matrix — IT Project Management (PI), Scoping and Vision (CAD), Planning and Estimation (PLA).
• Terms: Glossary; how to read ratings: Rating: Reading Ratings, Scores, and the Legend.
• Tools: Planning, Azure DevOps / TFS.

✻ Written by Claude Sonnet 5.5