Welcome

AI projects fail in ways software projects don't. Software projects mostly fail on schedule and scope; AI projects also fail on whether the underlying problem is learnable from the data you have, whether the model's behavior at the tails is acceptable, and whether the production system holds up when input distributions drift. This chapter names the eight characteristics that make AI work different and walks through how each one should change your project management practice: scoping, staffing, planning, risk, communication, governance, and operations. Internalizing these differences is what separates project managers who get repeatable results on AI work from those who keep getting blindsided.

Characteristic 1: Data Dependence

Software project outcomes depend on engineering effort. AI project outcomes depend on engineering effort plus the quantity, quality, representativeness, and availability of data. A team can do everything right on the engineering side and still produce a poor model because the dataset cannot support the task: too small, too noisy, missing the populations the system will see in production, or contaminated with leakage from the labels into the features. Practical implications for project management: include explicit data-readiness milestones at the front of any AI project ('we have N labeled examples covering distributions A, B, C, validated against gold standard, with documented coverage gaps'). Treat the dataset as a deliverable with an owner, version history, and quality metrics, not as a precondition assumed to be satisfied. Most AI project failures that the team labels as 'modeling problems' are actually data-readiness problems pushed downstream. Front-load the diagnosis: spend the first one to two weeks of a project on data assessment before committing to a delivery plan.

Characteristic 2: Experimental Uncertainty

Software components can be specified before they are built. AI components have to be measured to be specified. You don't know whether 'classify support tickets by urgency at >85% accuracy' is achievable on your data until you run several experiments with several model architectures. This means project plans cannot commit to AI quality bars before evidence exists for them; they can only commit to running the experiments that will produce the evidence. Plans should be expressed as branching options ('if the kill-switch experiment passes the baseline by ≥10pp accuracy, we proceed with implementation phase A; if not, we redirect to alternative B') rather than linear timelines. Stakeholders trained on software projects find this disorienting. They ask 'when will it be done?' and the honest answer is 'it depends on what we learn from the next two experiments.' Translation work from project manager to stakeholder is part of the job; faking certainty produces worse outcomes than honest probabilistic communication.

Characteristic 3: Probabilistic Outputs

Software outputs are deterministic by default. AI outputs are probabilistic by default, the same input can produce different outputs across runs (in stochastic models) or different outputs across slightly different inputs (in any model). This changes both how you specify acceptance criteria and how you handle errors. Acceptance criteria are quality bands, not binary checks: 'the model produces correct triage suggestions on ≥80% of held-out cases, with ≤5% catastrophic misroutes, evaluated on the standard test set.' Error handling is not just exception paths; it's about what the system does when the model is wrong or uncertain: does it fall back to a human, surface a confidence indicator, route to a different model, or refuse to answer? Designing the human-AI handoff and the failure-mode response is often where the bulk of the engineering work actually lies. The project plan should treat 'design the failure-handling layer' as a major workstream, not as cleanup at the end.

Characteristic 4: Evaluation as Product

Software has tests; AI has evaluations. The distinction matters because evaluations are themselves engineering artifacts that require design, maintenance, and trust calibration. A project's evaluation suite has to cover the failure modes you care about (which means knowing those failure modes: usually requiring domain experts), include held-out data the model has never seen (which means data discipline), produce reproducible scores (which means versioned datasets and seeded runs), and align with downstream business outcomes (which means the eval correlates with what the user experiences). Building this evaluation harness is often 30-50% of an AI project's engineering effort and is the team's most reusable asset across future projects. Project plans that treat evaluation as a final-week task understate it dramatically. Plan for evaluation infrastructure to grow alongside the model from the first prototype through production.

Characteristic 5: Distribution Shift and Decay

Software, once shipped, behaves the same way next year as it does today. AI, once shipped, decays: input distributions shift (users behave differently, products change, the world changes), and the model's performance on the current input distribution may diverge meaningfully from its performance on the training distribution. Project plans must include the post-launch operational layer: a monitoring system that tracks live performance against the evaluation suite, retraining triggers, an on-call protocol for performance regressions, and a periodic review cadence with sponsors. AI projects do not 'finish' the way software projects do; they enter a sustained operational phase that must be staffed and budgeted. Many projects fail not at launch but six to nine months later when nobody owns the decay curve and quality silently drops. Naming the operational owners and SLOs at project initiation prevents this.

Characteristic 6: Explainability and Trust

Most software is treated as a deterministic tool, users either trust it or fix it. AI systems sit in a different trust register because their outputs feel like judgments rather than computations. Users ask 'why did it say that?' in ways they don't ask about a calculator. Even when a model is more accurate than a human expert, users may reject it if they cannot inspect or understand its reasoning. Project planning has to treat explainability as a feature, not a luxury: design the user-facing explanation alongside the prediction; collect user feedback on whether the explanation is useful; iterate on the explanation as fast as on the model. In high-stakes domains (medical, legal, financial, hiring), explainability requirements may dictate model architecture choices, a slightly less accurate but more interpretable model may be the right business decision. Surface this trade-off explicitly to sponsors during scoping rather than discovering it during user testing.

Characteristic 7: Cross-Functional Collaboration

Software projects can succeed with engineers and product managers. AI projects need a wider tent: engineers, ML engineers, product managers, domain experts, data engineers, and often legal/compliance/security from day one. The reasons span every other characteristic on this list, domain experts are needed to define success and recognize failure modes; data engineers are needed because data plumbing is half the work; legal is needed because AI in many contexts triggers regulatory scrutiny that software did not. Plan for the wider team from project initiation, including formal mechanisms for domain experts to spend time on the project (carve-outs from their day jobs, not 'send a question over Slack when needed'). Underestimating the cross-functional time cost is one of the most common reasons AI projects slip, the modeling work moves fast, but the coordination work scales with the number of stakeholders and is rarely budgeted realistically.

Characteristic 8: Talent and Tooling Gradients

Software engineering practice is mature: most teams have well-understood ways of building, testing, and deploying. AI engineering practice is not yet uniform, within the same organization you may have one team using a robust ML platform with versioned datasets and shadow deployments, and another team running notebooks with no evaluation harness. Don't assume the practice level of a given AI team; audit it. Project risk depends on whether the team has the basic ML engineering hygiene to operate reliably (version control, evaluation, deployment automation, monitoring). If not, account for capability-building work in the plan rather than assuming it will be done in parallel without cost. Similarly, AI tooling moves quickly, the framework or platform you adopt today may be supplanted in eighteen months. Build with portability in mind, but don't paralyze the team with over-engineering for hypothetical migrations. The engineering judgment is in spotting which tooling decisions are reversible (most are) and which are foundational (the evaluation suite, the data pipeline).

Key Takeaway

AI projects share the surface of software projects but differ underneath in eight specific ways: data dependence, experimental uncertainty, probabilistic outputs, evaluation as product, post-launch decay, explainability, cross-functional collaboration, and uneven engineering maturity. Project management practice that ignores these differences produces predictable failures: schedule slips that masquerade as scope creep, late-stage 'discoveries' that are really un-asked questions, and post-launch quality decay that nobody owns. Practice that names them up front produces honest plans, healthy stakeholder communication, and projects that ship at known quality bars and stay there. The diagnostic question to ask of any AI project plan you encounter: does it treat data, evaluation, failure-mode handling, and post-launch operation as first-class workstreams with named owners and explicit milestones, or does it treat them as background concerns assumed to be handled? The plans in the second category produce the post-mortems with phrases like 'we underestimated the data work' or 'monitoring was deprioritized.' The plans in the first category produce projects that ship and stay shipped.

What Comes Next

Having seen what makes AI projects unique, the next step is the agile mechanics that work given those characteristics. The next chapter, Agile & Iterative AI Development, walks through which agile practices port cleanly to AI work, which break under uncertainty, and what additions (parallel experimentation tracks, evaluation suites as deliverables, graduation protocols) earn their keep on AI projects.