EXIN Dynamic Project Management Method Foundation cheat sheet

A project goal states the intended end result (output and outcome), while a project result is the tangible deliverable that contributes to it.

The project objective is expressed in scope, time, cost and quality; these four are the classic constraints that DPMM treats as interdependent.

A goal must be justified by a business case: the expected benefits must outweigh the estimated costs and risks.

SMART is the standard test for goal formulation: Specific, Measurable, Acceptable, Realistic, Time-bound.

Output is what the project delivers; outcome (effect) is the change the output produces in the user organization, usually realized after handover.

Project success is judged on three levels: result (did we deliver), goal (did the effect occur) and process (did we work effectively).

Scope creep is uncontrolled growth of deliverables; it is detected by comparing baseline scope with requested changes.

If the client cannot state a measurable goal, the project manager records it as an assumption and escalates it as a decision point before planning is baselined.

The project context covers stakeholders, the parent organization, the environment (market, law, technology) and the project's own history.

A stakeholder is anyone who can affect or is affected by the project; DPMM distinguishes internal (team, sponsor) from external (client, supplier, regulator).

The sponsor (client/principal) owns the business case and approves the project mandate; the project manager owns the delivery.

A project exists inside a permanent organization; the project organization is temporary and dissolves at handover.

Environmental factors (PEST: political, economic, social, technological) can invalidate the business case and must be reassessed at phase boundaries.

The business case is a living document: review it at each decision point, not only at the start.

A program is a set of related projects steered for shared benefit; a portfolio is the total set of investments of the organization.

Context analysis output feeds the risk register and the stakeholder list, so both are updated whenever the context changes.

DPMM is process- and people-oriented: it prescribes what to decide and when, not a rigid sequence of technical steps.

Principles apply at any scale; the method is tailorable, so a small project can use a lighter set of products and roles.

Decision points are mandatory: the project may not pass a phase boundary without an explicit go/no-go decision by the authorized role.

Roles and responsibilities are separated from persons; one person may hold several roles in a small project, but accountability must be explicit.

The method is result-driven: every activity must be traceable to a product or decision that adds value.

Working agreements and transparency are principles, not optional extras: information is shared with those entitled to it.

Continuous improvement (plan-do-check-act) applies to the method itself: evaluate the process at the end of each phase.

Deviation is managed by exception: report only when tolerances are exceeded, so management attention stays focused.

Agility is the ability to respond to change while keeping the goal in view; it is a mindset supported by short cycles, not a synonym for Scrum.

Iterative delivery produces increments; each increment is inspected and adapted, so feedback replaces prediction where uncertainty is high.

Empirical control rests on three pillars: transparency, inspection and adaptation.

A timebox is a fixed maximum duration; if the work is not finished, scope is reduced, not the timebox extended.

Agile and plan-driven approaches are a continuum; DPMM allows hybrid tailoring, e.g. phase-based governance with iterative execution.

Self-organizing teams decide how to do the work; the project manager guards the boundary and removes impediments.

Value is delivered early and incrementally; prioritize backlog items by business value and risk, not by ease.

Retrospectives close each cycle: identify what to keep, what to change, and assign a concrete action with an owner.

Core DPMM roles: client/sponsor, project manager, team members, and where applicable a steering group and quality assurance.

The steering group (project board) takes decisions at decision points and is accountable for the business case.

The project manager is accountable for the project result, the plan, progress reporting and issue and risk management.

The team member is accountable for delivering the assigned products to the agreed quality within the agreed time.

Quality assurance is independent of the project manager; it checks that the method and agreements are followed.

A RACI matrix maps roles to activities: exactly one Accountable per activity, at least one Responsible, and Consulted/Informed as needed.

Line management supplies people and maintains the permanent competencies; the project borrows capacity for a limited period.

Escalation path: team member to project manager, project manager to steering group; escalation occurs when tolerances are threatened.

Plan hierarchically: project plan (phases, decision points, products) then phase plan, then detailed activity or sprint plan.

Product breakdown first, activity planning second: define what must be delivered, then how.

A milestone has zero duration and marks a verifiable state or decision point; it is not an activity.

Critical path is the longest chain of dependent activities; its length equals the shortest possible project duration, and slack on it is zero.

Estimate with at least one technique (analogy, expert judgment, three-point/PERT, or parametric); document the basis of the estimate.

PERT expected duration = (optimistic + 4 x most likely + pessimistic) / 6.

Rolling-wave planning: detail is planned only for the near phase; later phases stay at a coarse level until more is known.

The baseline is the approved plan; changes to it go through change control, and actual-versus-baseline variance is reported.

Quality is fitness for purpose as defined by agreed requirements, not the highest possible specification.

Quality assurance is process-oriented and preventive; quality control is product-oriented and detective (tests, reviews, inspections).

The quality plan names each product, its quality criteria, the review technique and the responsible role.

Review types by formality: peer review, walkthrough, technical review, formal inspection; formality rises with product risk.

A review is only effective if the reviewer is independent of the author and works against explicit criteria.

Cost of quality = prevention + appraisal + internal failure + external failure; external failure is the most expensive category.

Definition of Done: a product is complete only when it meets its agreed criteria and is accepted by the authorized role.

Quality findings are recorded as issues and closed only after verification; unverified fixes count as open.

An issue is a problem that has already occurred and needs action now; a risk is an uncertain future event.

Issue log fields: identifier, description, raised by, date, owner, priority, action, status, closure date.

Priority is set by impact on goal, time, cost and quality, not by who raised the issue.

Every issue has exactly one owner and a target resolution date; unowned issues stay open indefinitely.

Escalate an issue to the steering group when resolving it exceeds the project manager's mandate or tolerances.

Change requests are a category of issue: assess impact on scope, time, cost and risk before approval.

Close an issue only after the resolution is verified and affected stakeholders are informed.

Trend analysis of the issue log (count and category over time) is a leading indicator of quality problems.

Risk = probability x impact (qualitative score); expected monetary value = probability x monetary impact (quantitative).

Risk process: identify, analyze, plan response, implement, monitor and control; repeat it at every phase boundary.

Response strategies for threats: avoid, transfer, mitigate, accept; for opportunities: exploit, share, enhance, accept.

A risk owner is accountable for the response; a risk actionee executes it. Both are named in the risk log.

Residual risk remains after the response; secondary risk is created by the response itself. Both must be logged.

Risk appetite is the willingness to accept risk; risk tolerance is the measurable deviation allowed before escalation.

Risk triggers (early warning indicators) are defined in advance so the response can start before the risk occurs.

A risk becomes an issue when it materializes; it then moves to the issue log and is managed there.

Phases run: initiation, definition/planning, execution, closure; each boundary is a decision point with a go/no-go.

Initiation output: project mandate, business case, global project plan and the project organization.

Definition output: detailed phase plan, product specifications, quality plan, risk and issue logs, stakeholder analysis.

Execution is steered by progress reports against the baseline; exceptions are reported only when tolerances are exceeded.

Closure includes product acceptance by the client, a final report, lessons learned and release of resources.

Each process has defined inputs, activities, outputs and the role accountable for the output.

Products are the backbone: a process is complete when its required products exist, are reviewed and are approved.

Tailoring is itself a documented process step: record which products and roles are combined or omitted and why.