EXIN Dynamic Project Management Method Project Manager cheat sheet

DPMM is a dynamic, model-based approach: the project is described by a set of objects (deliverables, activities, resources, conditions, decisions) linked by typed relationships, and the plan is generated from that model rather than hand-drawn as a static chart.

Core object types: Deliverable (a result to be produced), Activity (work that transforms inputs into deliverables), Resource (person, tool, or facility), Condition (a constraint or prerequisite that must hold), and Decision (a choice point that governs downstream paths).

Relationship types are directional and semantically distinct: a deliverable is produced by an activity; an activity requires a resource; an activity is subject to a condition; a decision selects among alternative activity sets.

A deliverable is 'realized' only when its producing activity has completed and all of that activity's conditions are satisfied; an activity cannot start until every required input deliverable is realized and every start condition holds.

The method separates the model (what must be true) from the schedule (when it happens): the same model can be re-planned repeatedly as conditions change, which is what makes the method 'dynamic'.

Decision objects create alternative paths; exactly one branch per decision is active at a time, and changing the active branch is a controlled model change, not an ad-hoc schedule edit.

Conditions are evaluated as boolean predicates; a condition that becomes false invalidates dependent activities and triggers re-planning of everything downstream of the affected node.

The method is iterative and incremental: scope is elaborated in successive cycles, and each cycle re-runs model validation before a new baseline is issued.

Terminology discipline matters on the exam: 'dynamic' refers to model-driven re-planning under changing conditions, not to 'agile' as a branded framework; do not conflate the two.

Planning sequence: identify deliverables top-down, then derive activities bottom-up, then attach resources and conditions, then resolve decisions, then validate the model for orphan nodes and cycles before baselining.

A valid model has no orphan deliverables (every deliverable has a producing activity), no orphan activities (every activity produces at least one deliverable), and no cyclic dependency chains among activities.

Critical path in DPMM terms is the longest dependency chain through activity durations; float equals late start minus early start, and zero-float chains define the critical path.

Change control rule: any change to a deliverable definition, a condition, or an active decision branch requires impact analysis on dependent nodes and re-approval of the affected baseline segment.

Progress is measured by realized deliverables, not by percent-complete of activities; an activity at 90% has delivered nothing and counts as zero realized output.

Role separation: the project manager owns the model and baseline integrity; the owner/sponsor approves baselines and decision branches; team members report activity status and condition changes.

Risk handling: a risk is modeled as a condition that may become false, plus a contingency activity; if the condition fails, the contingency path activates through its decision node.

Escalation rule: a condition change that alters the critical path or the approved decision branch is escalated to the sponsor; changes confined to float are handled by the project manager.

Exam trap: 'more detail is always better' is false - the model should carry only the detail needed to make the decisions and control points the project actually requires.