IPMA Level D Project Management Summary & Study Notes

IPMA ICB v4.0 — core ideas & competence model 🧭

• What this source covers

  • Defines a global standard for the individual competences required in project, programme and portfolio work.
  • Organizes competences into three interrelated domains and explains how people develop and demonstrate competence in practice.

• Start from first principles: what is being described?

  • A project is a time‑limited, unique endeavor to create a specified result within constraints like time and cost.
    • After this explanation the document uses the term project.
  • Competence means the ability of a person to apply knowledge, skills and attitudes to achieve expected results.
    • After this explanation the document uses the term competence.

• The purpose of a competence baseline (why it exists)

  • Helps individuals and organizations know which behaviours, knowledge and skills matter for success.
  • Supports assessment, education and HR decisions without mandating a single method.
  • After this explanation the document uses the term Competence Baseline and highlights it as a formal reference.

• The Eye of Competence: three domains explained simply

  • Explain before naming: people do projects, projects require method, and projects sit in a wider context.
  • After this explanation the model names the three domains: Perspective, People, Practice (this arrangement is called the Eye of Competence).

Domain 1 — Perspective (what surrounds the project)

• Basic idea: projects exist inside organizations and societies; decisions must align with larger goals.
  • Key activities: align with strategy, respect governance and standards, read the cultural and power context.
• Concrete elements explained then named:
  • Understand organizational strategy and how a project contributes to long‑term goals.
    • After this explanation the standard uses Strategy.
  • Recognize the organizational structures and processes that influence a project (e.g., PMO, reporting lines).
    • After this explanation the document uses Governance, Structures and Processes.
  • Check rules and legal requirements that affect the project (laws, safety, environment, codes of conduct).
    • After this explanation it uses Compliance, Standards and Regulations.
• How to show competence in Perspective (indicators)
  • Can align project objectives with mission and strategy.
  • Can identify and exploit strategic opportunities and manage compliance risks.

Domain 2 — People (human interactions that make or break projects)

• Basic idea: projects are executed by people; interpersonal skills and leadership matter.
  • After this explanation the document refers to the collection of skills as People competences.
• Key subtopics explained then named:
  • Communication: adapt message to the receiver, use visuals, confirm understanding.
    • Term used: Communication Practices.
  • Relationships & engagement: start contacts, build networks, show empathy.
    • Term used: Relationships and Engagement.
  • Leadership: take initiative, provide direction, influence ethically.
    • Term used: Leadership.
  • Teamwork: choose members, support development, delegate, and learn from mistakes.
    • Term used: Teamwork.
  • Conflict & crisis management: anticipate, analyze cause and stage, choose suitable responses (mediation, escalation).
    • Term used: Conflict and Crisis Management.
• Practical examples to reduce confusion
  • Communicating with a virtual team: set clear channels, agree norms, use visuals and check comprehension.
  • Handling a dispute: detect early signs (missed deadlines, tone changes), hold a structured conversation to surface causes.
• Highlighted terms to memorize: project, stakeholder

Domain 3 — Practice (methods and techniques to deliver outputs)

• Basic idea: these are the technical and procedural skills that turn plans into deliverables.

  • After this explanation the document groups these under Practice competencies.

• Examples of practice competences (explained then named):

  • Planning and controlling: create plans, measure deviations, take corrective actions.
    • Tools mentioned: variance analysis, scorecards, milestone trend analysis.
  • Risk and quality management: identify risks, choose responses, plan quality assurance.
  • Resource and procurement management: decide make/buy, manage suppliers and contracts.

• How practice links to People and Perspective

  • Technical methods need stakeholder input (People) and must align to strategy/regulations (Perspective).

• Developing competence: approaches explained then named

  • Experience: apply skills on the job and reflect on outcomes.
  • Education and training: structured learning to gain knowledge and methods.
  • Coaching and mentoring: one‑to‑one guidance to improve behaviour.
  • Simulation and peer development: safe settings to practise and get feedback.

• Who supports competence development

  • Educators, managers, HR, assessors and peers.
  • Organization must provide culture, time, funding and feedback loops.

• Assessment, benchmarking and continuous improvement

  • Assessment uses observable indicators and evidence (work products, behaviours, results).
  • Benchmarking compares against best practices to set improvement targets.
  • Continuous improvement is a learning loop: assess → develop → apply → reassess.

• Quick checklist for using ICB 4.0 in practice

  1. Map project responsibilities to the three domains to spot gaps.
  2. Use observable indicators (examples in the standard) to set development goals.
  3. Combine on‑the‑job experience with targeted training and coaching.
  4. Benchmark practices externally and adapt for context.

• Key terms to memorize (highlighted sparingly)

  • Competence Baseline
  • Eye of Competence
  • project
  • stakeholder

pmbaseline v3.1 — practical project & programme methods 📘

• What this source covers

  • A practitioner's manual of methods, processes and templates for project and programme management.
  • Connects theory (IPMA ICB alignment) to concrete tools: planning, controlling, communication, procurement and organizational forms.

• Start from first principles: what is a project vs a programme

  • Project: a temporary, unique effort to produce a defined outcome; needs planning, teams and controls.
    • After this explanation the manual uses the term project.
  • Programme: a group of related projects managed together to gain benefits and manage dependencies.
    • After this explanation the manual uses programme.
  • Portfolio: a set of projects and programmes selected to meet strategic goals.

• Why projects exist: the Business Case (explain then name)

  • Basic idea: an investment decision requires evidence that benefits outweigh costs over time.
  • After this explanation the manual uses Business Case as the decision foundation.

Project life cycle & sub‑processes (explain before naming)

• Basic idea: a project proceeds from idea → start → execution → close, with specific management activities at each stage.
• The pmbaseline lists these sub‑processes (named after explanation):
  1. Project start / initiation — clarify objectives and authorise work.
  2. Coordination / execution — assign tasks, manage team and deliver results.
  3. Controlling — monitor performance and trigger corrective actions.
  4. Marketing / stakeholder communication — inform and gain acceptance.
  5. Crisis management — detect and respond to serious threats or opportunities.
  6. Close‑down / handover — transfer outputs into operations and capture lessons.

Organizational forms and roles (explain then name)

• Basic idea: how authority is distributed affects decision speed and resource control.
  • Pure project organization: project manager has full authority.
  • Matrix organization: authority shared between line managers and project managers.
  • Influence form (functional): line management retains most authority; projects negotiate for resources.
• Roles to know (explained then named): project sponsor (authorises), project manager (operational lead), project team (deliverers), PMO (support/oversight).

Core methods & tools (explain then list)

• Planning basics: break the work into manageable pieces, estimate time and cost, sequence activities.
  • After this explanation the manual uses Work Breakdown Structure and scheduling methods like Gantt charts.
• Controlling & reporting tools: detect deviations and act.
  • Methods explained then named: variance analysis, milestone trend analysis, project scorecard (traffic‑light visuals), relevance tree method.
• Communication & documentation: use meeting minutes, acceptance protocols and a communication plan to keep clarity and traceability.
• Procurement: decide make vs buy through market analysis; plan tendering, selection and contract management.
• Quality & risk: plan quality criteria, inspect and accept work; identify, assess and respond to risks.

Social & leadership topics (explain then name)

• Project culture and teamwork shape delivery outcomes; leadership and communication influence motivation.
  • Techniques: kick‑offs to set norms, workshops to align, regular feedback and social events to build identity.
• Conflict management: prevent with clear roles and communication; resolve by negotiation, mediation or escalation depending on the conflict stage.

Practical templates and short methods (explained then pointed out)

• To‑Do lists and work packages: small, assigned tasks with deadlines to manage daily execution.
• Meeting minutes: standard fields to capture decisions, actions and owners.
• Acceptance protocols: formal sign‑off when work packages meet agreed standards.
• Communication plan: define audiences, messages, channels and frequency at project start.

Techniques for control & decision support (step explanations)

• Variance analysis: 1) compare actual vs planned; 2) identify cause; 3) select corrective measure; 4) document decision.
• Project scorecard: map objectives to measurable indicators and visualize status (green/yellow/red) for quick decisions.
• Milestone trend analysis: track milestone dates over time to spot schedule drift.

How pmbaseline links to competence (explain then name)

• The manual provides methods that implement the competence domains of the ICB: methods (Practice), people skills suggestions (People), and alignment to business (Perspective).

• Quick action checklist for practitioners

  1. Always start with a clear Business Case and a signed project charter.
  2. Create a WBS and assign owners for each work package.
  3. Set up a communication plan and regular controls (scorecard + variance analysis).
  4. Use documented meeting minutes and acceptance protocols for traceability.

• Key terms to memorize (highlighted)

  • Business Case
  • Project Lifecycle
  • Work Breakdown Structure

Handout: Praxisorientiertes PM 2025/26 — course structure & applied practice 📅

• What this source covers

  • A practical course syllabus, calendar and applied templates for running projects in a classroom/workshop setting.
  • Focuses on hands‑on items: project idea selection, project handbook (PHB), planning, team development, communication and IPMA Level D preparation.

• Course purpose and teaching method (explain then name)

  • Basic idea: teach project management through doing — combine inputs, group projects, reflections and iterative feedback.
  • After explanation the document calls the teaching approach project groups + project handbook (PHB).

• What is a project? (explain before label)

  • Basic idea: a temporary, goal‑oriented, unique and cross‑disciplinary task involving risk and resource constraints.
  • After this explanation the handout uses the term project and highlights it as a temporary organization with its own culture.

• Why use PM? (explain then list benefits)

  • Basic idea: applying PM brings clarity, efficiency, motivation and better control of results.
  • Benefits named: transparency, effectiveness & efficiency, motivation & commitment, steerability.

Course calendar & practical milestones

• The course is structured around weekly modules combining inputs (lectures) and project group work (PGA).
  • Early sessions: project idea selection, context analysis, first project assignment and kick‑off.
  • Mid sessions: detailed planning (WBS, work packages), scheduling (Gantt/MS Project), resource and cost planning.
  • Later sessions: team development, communication plan, controlling, crisis management and project close‑down.
  • Final sessions: IPMA Level D prep, agile methods overview, final presentations and diploma.

Key applied documents the course uses (explain then name)

• Project handbook (PHB): a living manual for the project including scope, schedule, responsibilities and templates.
• Project charter / project assignment: formal, signed short document answering WHY, WHAT, HOW, HOW MUCH, WHEN, WHO.
  • Uses SMART criteria for objectives (explained then named): Specific, Measurable, Achievable, Relevant, Timed.

Practical process: from idea to handover (step sequence)

1. Project idea generation — capture problem and proposed solution.
2. Pre‑project screening — quick cost/benefit and investor search.
3. Create project charter — list goals, scope, milestones, roles and signatures.
4. Plan work packages and schedule — build WBS, assign owners and estimate.
5. Execute and control — run tasks, track progress, record issues in To‑Do lists.
6. Acceptance and handover — use acceptance protocol to transfer outputs to users.
7. Close and lessons learned — write final report and archive PHB.

Templates & examples from the handout (explain then show uses)

• Project definition template: contains background, goals, deliverables, milestones, budget and signatures.
  • Use to make expectations explicit and to obtain formal authorisation.
• Example: outage data center project — shows how goals, non‑goals, phases and resources are recorded.
• Meeting minutes template: capture participants, decisions, action owners and deadlines for traceability.

Risk, culture and team development (explain then name)

• Risk: identify early, do a cost/benefit of responses, and update risk register regularly.
• Project culture: consciously shape norms via mission statements, social rules and team rituals.
• Team phases: form → storm → norm → perform; apply targeted interventions at each phase (e.g., role clarification early, conflict coaching during storm).

Questions the handout suggests to keep teams focused (explained then listed)

• Why are we doing this project? — clarifies purpose and assists the Business Case.
• What changes after the project? — defines success and benefits.
• Which plans do we need at which level of detail? — chooses between high‑level and work‑package level plans.
• Who does what next? — keeps execution crisp with owner assignment.

Practical tips from the course material

• Always get a signed project assignment before significant work.

• Use SMART objectives to avoid vague goals.

• Keep the PHB updated; it is your single source of truth for the project.

• Run regular short meetings with an agenda and minutes to maintain momentum.

• Key terms to memorize (highlighted)

  • Project Charter
  • SMART
  • Business Case