clement13.net
Original photo: Un nid-de-poule rempli d'eau dans la chaussée, avec une mitaine perdue
Description
Un nid-de-poule rempli d'eau dans la chaussée, avec une mitaine perdue
Source
Miguel Tremblay · original page
Licence
PD Public domain
Original photo, unretouched. The background is a version of it stylised by the site.

Pitfalls and good practices in project management (cross-functional summary)

You will have a catalog of 57 pitfalls grouped into six families, each with symptom, cause, remedy, and a link to the file that covers it in depth.

Guide≈ 17 min readCheckedCheck doneFacts, figures and references were checked against the sources cited in the page.Written with AI assistance; sources are cited at the bottom of the page. An error? Report it via clement13.net.Reading
In brief
  • You will have a catalog of 57 pitfalls grouped into six families, each with symptom, cause, remedy and a link to the file that covers it in depth.
  • You will have 34 good practices numbered and usable as team principles.
  • You can launch a project with the startup checklist and review it with the review checklist (quarterly or in committee).
  • You will have a section dedicated to data / BI / datamart projects, where most pitfalls are amplified by the nature of data (irreversibility, volume, accuracy).

This file is a summary and does not replace the in-depth files: each pitfall links to the chapter that explains it. The /5 ratings are expert assessments (see RATING) for a team of 4 to 12 people, BI/datamart project of 6 to 18 months.

On this page
  1. 1. How to read this catalog
    1. 🟢 Novice — what is a pitfall?
    2. 🟡 Practical — format
    3. 🔴 Expert — why a catalog rather than a recipe
  2. 2. Family A: framing, value, and scope
  3. 3. Family B: method and organization
  4. 4. Family C: estimation, planning, and steering
  5. 5. Family D: team, stakeholders, and communication
  6. 6. Family E: quality, delivery, and operations
  7. 7. Family F: data, BI, and datamart specifics
  8. 8. The 34 good practices
    1. 🟢 Novice — the foundations
    2. 🟡 Practical — day-to-day
    3. 🔴 Expert — maturity
  9. 9. Project kickoff checklist
  10. 10. Project review checklist
  11. 11. Special data project checklist
  12. 12. Severity and Frequency: Where to Focus Your Efforts
  13. 13. See also

Level: 🟢→🔴

1. How to read this catalog#

🟢 Novice — what is a pitfall?#

A pitfall is a mistake that seems reasonable at the time and whose effects show up later. They are recognized by their symptom (what is observed), understood through their cause (the mechanism), and addressed with a remedy (the action that changes the situation). Pitfalls combine: unclear scoping (A1) creates unrealistic estimates (C1), which feed an unrealistic schedule (C3), which leads to sacrificed quality (E1).

🟡 Practical — format#

Each line: ID | Pitfall | Symptom | Cause | Remedy | Learn more. The ID (A1…F15) makes it easy to reference in retrospectives (“we are currently falling into pitfall C4”). Links point to Project Management Fundamentals, Scrum in Practice, Scrum Applied to Data, BI, and the Datamart, Predictive Methods (waterfall, V-model, spiral, RUP, PMBOK, PRINCE2, Merise, CMMI), Agile and Lean Methods (Manifesto, Kanban, XP, Lean, Shape Up, DSDM, SAFe, DevOps…), Methods Specific to Data Projects, Choosing Your Method and Hybridizing, CI/CD: Continuous Integration and Continuous Delivery, CI/CD for data: foundations, datamarts, pipelines, and reports, AI for Project Management (General Then Data).

🔴 Expert — why a catalog rather than a recipe#

No method protects against every pitfall; they shift the risks. Predictive methods expose you to the pitfall of late change; agile to the pitfall of no vision; “all-tool” approaches to the pitfall of form without substance. Expertise means knowing the failure modes of the chosen method and putting targeted safeguards in place (see Comparison of Project Management Methods). This catalog should therefore be read against the method in use: which pitfalls does yours encourage?

2. Family A: framing, value, and scope#

ID Pitfall Symptom Cause Remedy Learn more
A1 Unclear objective Everyone describes the project differently; endless debates about “what is in scope” Rushed framing, absent sponsor Objective statement + measurable success criteria validated in writing Project Management Fundamentals
A2 Solution before problem The tool (or technology) is chosen before defining the need Trend effect, commercial pressure Describe the problem and expected value first; the tool is a conclusion Project Management Fundamentals
A3 Value never measured Delivered on time, no one uses it Success defined by delivery, not by usage Define an adoption or benefit indicator, track it after delivery Project Management Fundamentals
A4 Scope drift (scope creep) Every week, one “small request” No arbitration mechanism Single backlog, decision-making PO, addition = removal or postponement Scrum in Practice
A5 Phantom sponsor Decisions drag on, blockers are not removed Sponsor appointed but not engaged Short steering ritual with dated decisions; defined escalation Project Management Fundamentals
A6 Requirements frozen too early 200-page specifications obsolete at delivery time Predictive method applied to an uncertain need Frame uncertainty (spike, prototype), break down, validate early Predictive Methods (waterfall, V-model, spiral, RUP, PMBOK, PRINCE2, Merise, CMMI)
A7 Requirements never written down Dispute over what was requested Excessive trust in verbal communication Written, validated, versioned acceptance criteria Scrum in Practice
A8 One-day business case The budget gets canceled midstream Benefit assumptions not revisited Review the business case at each milestone; stopping is a legitimate decision Project Management Fundamentals
⚠️ Pitfall

Symptom: the project “succeeds” according to plan but the business keeps using its spreadsheet. Cause: what was requested was delivered, not what was needed (A3 + A7). Remedy: measure usage at 30 and 90 days, and include a real user on the acceptance testing team from the start.

3. Family B: method and organization#

ID Pitfall Symptom Cause Remedy Learn more
B1 Method imported without context “It doesn't work here” Copying a model (Spotify, SAFe) without adaptation Start with the problem, not the framework; experiment and inspect Agile and Lean Methods (Manifesto, Kanban, XP, Lean, Shape Up, DSDM, SAFe, DevOps…)
B2 Ceremonies without empiricism Status dailies, retros with no action, reviews with no feedback Rituals applied out of habit Reaffirm the objective of each event; remove what inspects nothing Scrum, the framework (Scrum Guide 2020)
B3 Permanent ScrumBut “We do Scrum, but…” for everything Unacknowledged adaptations Name the gaps, assess their cost, own them or correct them Scrum in Practice
B4 Uncontrolled Wagile Waterfall framing, sprint-based development, late final acceptance testing Predictive governance pasted onto agile execution Deliver increments that can be acceptance tested; continuous acceptance testing Choosing Your Method and Hybridizing
B5 Agile = no plan No vision, no roadmap, everything is “emergent” Confusion between adaptation and improvisation Product Goal, objective-based roadmap, regularly revised plan Scrum, the framework (Scrum Guide 2020)
B6 Predictive = change forbidden Changes become contractual conflicts Rigid contract and governance Change clauses, management reserve, reassessment milestones Predictive Methods (waterfall, V-model, spiral, RUP, PMBOK, PRINCE2, Merise, CMMI)
B7 Over-process More time spent documenting the project than doing it Oversized method Adjust ceremonies to size and criticality Comparison of Project Management Methods
B8 Brutal method switch Disoriented team, productivity dropping One-shot transition to a new framework Progressive path, coaching, transition indicators Choosing Your Method and Hybridizing
B9 “Mailbox” PO Decisions escalate to a committee, velocity is blocked Product Owner without authority Clear mandate, availability, access to sponsor Scrum, the framework (Scrum Guide 2020)

4. Family C: estimation, planning, and steering#

ID Pitfall Symptom Cause Remedy Learn more
C1 Estimate = commitment A range becomes a firm promise Forecast/commitment confusion Give ranges, name them, separate target and forecast Scrum in Practice
C2 Estimation by the absent Sizing done by a lead without the team Desire for speed Collective estimation, with those who will deliver Scrum in Practice
C3 Schedule without buffer Everything slips at the first uncertainty Optimism, Hofstadter's law Explicit buffers, pessimistic scenario, control milestones Project Management Fundamentals
C4 Velocity as objective Points inflate, value stagnates Measure turned into target (Goodhart) Use velocity for internal forecasting, never as performance Scrum in Practice
C5 Comparing teams Competition over points, cheating Management by indicator Compare trends specific to each team, not levels Scrum in Practice
C6 Reassuring burndown The curve goes down, delivery fails Measurement of work done, not delivered value Track flow and acceptance-tested increments Scrum in Practice
C7 Forgotten dependencies A delivery is blocked by a source or another team Missing mapping Map early, treat dependency as a tracked item Scrum Applied to Data, BI, and the Datamart
C8 Multitasking and overload Everything is “in progress,” nothing is finished No work-in-progress limit Limit WIP, finish before starting Agile and Lean Methods (Manifesto, Kanban, XP, Lean, Shape Up, DSDM, SAFe, DevOps…)
C9 Steering by green status Everything is green until it explodes (“watermelon” effect) Fear of reporting a problem Weak-signal culture, objective color criteria Project Management Fundamentals
C10 False steering data Inconsistent dashboards After-the-fact entry, diverging definitions Shared definitions, automatic feed from the tool Project Metrics and Reporting

5. Family D: team, stakeholders, and communication#

ID Pitfall Symptom Cause Remedy Learn more
D1 Hero and single point of failure One departure paralyzes the project Knowledge concentrated in one person Pairing, cross-reviews, living documentation, rotation Scrum in Practice
D2 Psychological insecurity No one reports problems Shooting the messenger Respond to bad news with thanks; address root causes Fundamentals
D3 Forgotten stakeholders Opposition discovered at delivery No stakeholder mapping Map stakeholders during framing, minimal communication plan Fundamentals
D4 Email-based communication Lost decisions, competing versions No single source of truth Decisions logged in a single register Scrum in Practice
D5 Siloed team Each role works in sequence, with hot potato handoffs Function-based organization Cross-functional team and vertical increments Scrum and data
D6 Diluted part-time team Everyone at 20% across five projects Allocation by “fractions” Stable allocation, few projects per person Scrum in Practice
D7 Ignored resistance to change Tool delivered, not adopted No change management Involve users, train, measure adoption Data project matrix: adoption
D8 AI use without a framework Data leaks, unreviewed text Spontaneous adoption without a policy Usage policy, governed tool, review AI and Project Management

6. Family E: quality, delivery, and operations#

ID Pitfall Symptom Cause Remedy Learn more
E1 Quality sacrificed for schedule Debt that slows every following Sprint Schedule pressure, missing DoD Non-negotiable Definition of Done, debt tracked in the backlog Scrum, the framework (Scrum Guide 2020)
E2 Acceptance testing at the end of the project Massive defects discovered late Testing postponed to the final phase Test continuously; acceptance testing by increments Predictive Methods (waterfall, V-model, spiral, RUP, PMBOK, PRINCE2, Merise, CMMI)
E3 Manual delivery Deployments differ from one environment to another Oral process, personal scripts Reproducible pipeline, promotion between environments CI/CD: Continuous Integration and Continuous Delivery
E4 Tests that test nothing Always green, defects in production Tests without useful assertions, cosmetic coverage Behavior-based tests, mutation or review, quantified non-regression CI/CD: Continuous Integration and Continuous Delivery
E5 No planned rollback A failed deployment lasts for hours Rollback never rehearsed Rehearsed rollback plan, rollback or roll-forward defined CI/CD: Continuous Integration and Continuous Delivery
E6 “Done” without operations Delivered but not monitored, undocumented Operations out of scope Operations in the DoD; handoff to run prepared CI/CD: Continuous Integration and Continuous Delivery
E7 Diverging environments “It works on my machine” No parity Infrastructure described as code, parity measured CI/CD: Continuous Integration and Continuous Delivery

7. Family F: data, BI, and datamart specifics#

In a data project, data is not inherently replayable, its defects propagate silently, and its accuracy is the product. Hence a separate family.

ID Pitfall Symptom Cause Remedy Learn more
F1 Underestimated source quality Wrong figures, impossible reconciliations No profiling before design Profiling and data spike during framing Scrum and data
F2 “Toy” test dataset Everything passes on 1,000 rows, everything fails on 100 million Data volume not tested Volume tests, pipeline time measurements CI/CD for data: foundations, datamarts, pipelines, and reports
F3 Non-idempotent processing Duplicates or gaps after replay No replay-oriented design MERGE/targeted purge, deterministic keys, double-run tested CI/CD for data: foundations, datamarts, pipelines, and reports
F4 Forgotten historization Impossible to reproduce a past figure Overwritten dimensions (type 1) without thought Decide type 1/2 by attribute; test reproducibility Methods Specific to Data Projects
F5 Diverging business definitions Two reports, two “revenues” No glossary or single semantic layer Validated single definition, single measure in the model Data project matrix: governance
F6 Business acceptance testing skipped Figures challenged after production go-live Acceptance testing limited to “the report displays” Acceptance test protocol on figures, reconciliations, written sign-off Scrum and data
F7 Silent source drift Column renamed or type changed upstream, empty reports No data contract Data contracts, schema checks, alerting CI/CD for data: foundations, datamarts, pipelines, and reports
F8 “Impossible” rollback Corrupted data has already propagated No backup or reversibility Snapshots, additive deployments, replay from source CI/CD for data: foundations, datamarts, pipelines, and reports
F9 Personal data in testing Production copy in test environments Convenience Anonymization, synthetic datasets, limited production rights Data project matrix: security
F10 Security and RLS forgotten A user sees figures from another scope Security handled at project end Permissions in acceptance criteria, role-based tests BI matrix: RLS
F11 “Pixel-perfect” report on a shaky model Beautiful screens, wrong measures Visualization prioritized Model and measures first, visuals second BI matrix: semantic model
F12 Cascading column rename Client reports break No impact analysis Lineage, gradual deprecation, model versions Data project matrix: metadata
F13 Full load every time Processing window explodes with volume No incremental strategy Incremental loading, partitioning, continuous measurement BI matrix: performance
F14 Dependency on a key person The only person who knows the model is absent Undocumented knowledge Schema-derived documentation, cross-review Data project matrix: metadata
F15 Data migration treated like copy-paste Losses, duplicates, unexplained discrepancies No reconciliation Reconciliation at every step, repeated replays before cutover Methods Specific to Data Projects
🧪 Example

An SFA datamart fed nightly: the source adds one column and changes another column’s type. The load does not crash (implicit conversion), but amounts are truncated. Combined pitfalls: F7 (no contract), F6 (acceptance testing compared nothing), F8 (bad data is already consumed). Countermeasure: blocking schema check at input, total reconciliation at output, and the ability to replay the prior day.

Total: A (8) + B (9) + C (10) + D (8) + E (7) + F (15) = 57 listed pitfalls.

8. The 34 good practices#

Grouped by intent. Each one is a verifiable principle, not a slogan.

🟢 Novice — the foundations#

  1. Write the objective in one sentence and the success criteria with numbers (or verifiable observations).
  2. Name an available sponsor and product decision-maker (PO), with real authority.
  3. Map stakeholders before writing the first ticket.
  4. Define “done” (DoD) collectively, and stick to it.
  5. Limit work in progress: finish before starting.
  6. Deliver small and often: increments ready for acceptance testing at regular intervals.
  7. Keep a single register of decisions and risks, dated, with owners.
  8. Make work visible: a board everyone reads, updated effortlessly.

🟡 Practical — day-to-day#

  1. Estimate in ranges, collectively, and distinguish forecast from commitment.
  2. Forecast by flow (cycle time, throughput) as soon as history exists.
  3. Refine the backlog continuously, and keep only a small amount “ready” (quality is better than volume).
  4. Split into vertical slices (from source to report), not technical layers.
  5. Treat debt explicitly: ticket, estimate, regular capacity quota.
  6. Run retrospectives that produce one to three actions tracked through to closure.
  7. Plan buffers and a pessimistic scenario in any binding plan.
  8. Set up systematic code and SQL script review, including AI-assisted work.
  9. Automate deployment and make it identical across environments (CI/CD).
  10. Trace each deliverable: ticket, version, author, reviewer (traceability by default).
  11. Measure usage after delivery, not just delivery.
  12. Document what can be derived automatically (schema, release notes) and regenerate at each version.

🔴 Expert — maturity#

  1. Choose the method by dimension (size, uncertainty, regulation, contract, maturity, data nature) rather than by trend (Choosing Your Method and Hybridizing).
  2. Know your method’s failure modes and put targeted safeguards in place.
  3. Reduce dependencies rather than coordinate them: teams aligned to value streams.
  4. Use cost of delay to prioritize, not the intuition of the loudest voice (Project Management Fundamentals).
  5. Delay irreversible decisions and buy options (spikes, prototypes) while uncertainty is high.
  6. Measure flow (DORA and equivalents) to learn, never to rank people.
  7. Treat indicators as hypotheses: if a measure becomes a target, challenge it (Goodhart).
  8. Cultivate psychological safety: bad news reported early is a team success.
  9. Use AI as a challenger, not a decision-maker, with a charter, safeguards, and gain measurement (AI for Project Management (General Then Data)).
  10. Design for replay and reversibility: idempotence, snapshots, additive deployments (CI/CD for data: foundations, datamarts, pipelines, and reports).
  11. Manage data contracts and model versions as public interfaces.
  12. Have business validate the numbers, using a written protocol and reproducible reconciliations.
  13. Separate run from build by explicitly naming what moves to operations and under what condition.
  14. Review the method every quarter: what worked for 5 people may hinder at 12.
✅ Good practice

A good practice is only good in a context. For each one, ask: what problem does it solve for us today? If the answer is “none,” do not apply it (pitfall B7).

9. Project kickoff checklist#

Review before the first sprint or first phase. Any “no” box is a risk to name, not necessarily a blocker.

Value and framing

  • [ ] An objective sentence is written and shared.
  • [ ] Observable success criteria (usage, benefit), not only delivery criteria.
  • [ ] An identified, available sponsor who knows their obligations.
  • [ ] A written “in / out” scope.
  • [ ] A business case, even brief, and the rule for reviewing it.

Organization

  • [ ] A product decision-maker (PO or equivalent) with authority.
  • [ ] A named team, stable allocation, and clear roles (MOA/MOE clarified).
  • [ ] A chosen method and justified for the context (Choosing Your Method and Hybridizing).
  • [ ] A Definition of Done and, optionally, a Definition of Ready (common practice, absent from the Scrum Guide).
  • [ ] A single place for the backlog, decisions, and risks.

Risks and constraints

  • [ ] A pre-mortem or a risk list with owners.
  • [ ] External dependencies mapped (sources, teams, vendors).
  • [ ] Regulatory and security constraints known.
  • [ ] An explicit buffer budget (time, cost).

Delivery

10. Project review checklist#

Use every quarter or at each milestone. Each question calls for evidence, not opinion.

Theme Question Expected evidence
Value Are the objective and expected benefits still valid? Reviewed business case, usage figures
Scope What have we added, removed, postponed since the last milestone? Change log
Flow Are cycle time and throughput changing? Where are the waits? Flow board, blocked items
Quality How many escaped defects? Is the DoD being met? Defects by version, DoD review
Debt Is known debt growing or shrinking? Debt tickets, share of capacity
Risks Do major risks have an owner and a dated action? Up-to-date register
Team Are workload, psychological safety, and skills healthy? Retrospectives, interviews
Stakeholders Are expectations aligned? Any surprises? Feedback in reviews, surveys
Delivery Are deployments reproducible and reversible? Deployment log, rollback test
Method Which practices still help? Which ones hinder? Retro actions, team feedback
Cost Actual vs planned; forecast at completion? Budget tracking

The Maturity Matrix — IT Project Management (PI) and Maturity Matrix — Data Project Management (PD) matrices provide a graduated version of this review, with verifiable milestones.

11. Special data project checklist#

For a datamart, warehouse, or reporting project. Add to the two previous checklists.

Sources and contracts

  • [ ] Each source has an owner, a schema contract, a frequency, and an availability window.
  • [ ] Data profiling has been done (nulls, duplicates, value domains, volumes).
  • [ ] Schema drift detection is automated and blocking.

Design

  • [ ] The grain of each fact table is written in one sentence.
  • [ ] History-tracking rules are decided attribute by attribute.
  • [ ] Business definitions (active customer, revenue...) are unique, validated, versioned.
  • [ ] Surrogate keys and join rules (nullability) are documented.

Processing

  • [ ] Each process is idempotent: replayed twice, it gives the same result.
  • [ ] A recovery strategy after interruption is written and tested.
  • [ ] Processing time is measured at representative volume.
  • [ ] Processes are logged (start, end, rows, errors).

Quality and acceptance testing

  • [ ] Control queries (counts, sums, reconciliations) run at every load.
  • [ ] A business acceptance testing protocol on figures exists, with expected values validated in writing.
  • [ ] A non-personal test dataset exists, representative in shape and volume.

Security and compliance

  • [ ] Personal data identified, minimized, protected; legal basis and retention periods known.
  • [ ] Role-level security (RLS) is tested by profile, not just configured.
  • [ ] Test environments do not contain non-anonymized production data.

Delivery and operations

  • [ ] Delivery via pipeline or versioned package, compatible with the previous version.
  • [ ] Rollback or replay plan from the source.
  • [ ] Monitoring of freshness, volumes, and anomalies, with an alert owner.
  • [ ] Data dictionary and lineage regenerated at each version.

Adoption

  • [ ] Key users are trained; an adoption indicator exists.
  • [ ] A support channel and a change request process are defined.
🤖 AI

These checklists are good material for an assistant: provide the project file and ask “which boxes are not covered by these documents?” for an initial diagnosis. The verdict remains human (see AI for Project Management (General Then Data)).

12. Severity and Frequency: Where to Focus Your Efforts#

Expert assessment of pitfall families, for a team of 4 to 12 people on a BI/datamart project. These are subjective orders of magnitude, not statistics.

Family Frequency Severity Detectability Comment
A — Scoping, value 4/5 5/5 2/5 Root cause of “delivered but useless” failures; detected late
B — Method, organization 4/5 3/5 3/5 Visible in retrospective if it is honest
C — Estimation, steering 5/5 3/5 3/5 Very common, rarely fatal on its own
D — Team, communication 4/5 4/5 2/5 Weak signals are human, not quantified
E — Quality, delivery 4/5 4/5 4/5 Defects eventually become visible; automation helps
F — Data specifics 4/5 5/5 1/5 Silent errors: the wrong number looks right

Reading guide: families A and F combine the highest severity with the lowest detectability: these are the ones that justify active controls (scoping review, number reconciliations). Family C is the most frequent but the least fatal: a good target for quick wins.

💡 Expert tip

Choose three pitfalls to monitor per quarter, based on your method (B), your data context (F), and the latest incident. A catalog of 57 pitfalls is an encyclopedia; three tracked pitfalls are an action plan.

13. See also#

✻ Written by Claude Sonnet 5.5