ITIL 4 PM PDF cheat sheet

A project is a temporary structure of resources (people, technology, information, partners) created to deliver one or more outputs against agreed objectives; it is a management vehicle, not a practice or a value stream.

ITIL 4 treats projects as organizational structures that enable value co-creation; the project itself does not create value - the outputs it produces must be used by consumers within a value stream.

Output vs outcome vs value: outputs are deliverables such as a new service component; outcomes are the results stakeholders experience; value is realized only when outcomes are perceived as beneficial by the consumer.

Four dimensions model (organizations and people, information and technology, partners and suppliers, value streams and processes) applies to every project; each dimension must be considered for the project to be viable.

Project management is a general management practice in ITIL 4, not a service management practice; it sits alongside portfolio, risk and architecture management as a governance-oriented practice.

A project has a defined start and end, a scope boundary, assigned authority and accountability, and a governance structure; ongoing operational work with no defined end is not a project.

Projects may be run under waterfall, agile, hybrid or iterative delivery models; ITIL 4 is delivery-model agnostic and requires only that the chosen approach fits the work and the organization.

The project manager's accountability is for the project's outputs and for the effective use of the project's resources; accountability for the service outcome remains with the service owner or value stream owner.

A programme is a temporary structure of interrelated projects managed together for shared objectives; a portfolio is the set of all programmes, projects and other work aligned to organizational strategy.

ITIL 4 has 34 management practices: 14 general management, 17 service management and 3 technical management; project management is one of the 14 general management practices.

Each practice is described by purpose, key terms and concepts, practice success factors, key activities, and key roles; the practice guidance is delivery-model neutral and does not prescribe a method such as PRINCE2 or PMBOK.

Portfolio management governs the organization's investment in programmes, projects and products, ensuring they are prioritized, funded and balanced against strategy, risk and capacity.

Risk management identifies, assesses and treats uncertainty; in projects it feeds the business case, the decision to proceed, and the treatment of threats and opportunities throughout the lifecycle.

Service design, service transition concerns and change enablement intersect with projects: a project delivering a new or changed service must pass through change enablement before release into live operation.

Release management, deployment management and change enablement are service management practices that projects interface with at the point of handover; the project produces the release candidate, operations owns it thereafter.

Knowledge management ensures project information is captured, maintained and shared; the service knowledge management system (SKMS) is the typical repository for project and service records.

Supplier management and relationship management are practices the project relies on when partners deliver components; contracts, shared objectives and agreed service levels must be set before work starts.

Practice success factors describe what good looks like for a practice; for project management they include effective sponsorship, clear scope, realistic planning and stakeholder engagement.

A value stream is a combination of the organization's value chain activities and practices that, together, create products and services for consumers; a project typically contributes to one or more value streams rather than being one.

The ITIL 4 service value chain has six activities: plan, improve, engage, design and transition, obtain/build, and deliver and support; project work is distributed across these activities, most often design and transition and obtain/build.

A process is a set of interrelated or interacting activities that transforms inputs into outputs; a value stream is broader and includes the organizational structures, practices and resources needed to realize value.

Project lifecycle stages typically include initiation, planning, execution, monitoring and control, and closure; these map onto value chain activities, not onto ITIL practices one-to-one.

The business case is a core value-stream artifact: it justifies the investment, states expected outcomes and benefits, and is reviewed at stage boundaries; if the business case fails, the project should be stopped or re-scoped.

Definition of ready and definition of done are process rules that govern when work can enter delivery and when an output is complete; they reduce rework and make handover predictable.

Workflow management and visual management (for example a kanban board) make the project's value stream visible; they expose bottlenecks, queues and work-in-progress limits rather than adding control overhead.

Handover to operations is a value-stream step with its own acceptance criteria; a project is not complete until the receiving team has accepted the output, the knowledge has been transferred and support arrangements are in place.

Value stream mapping identifies waste, handoffs and delays between project activities and the surrounding operational practices; improvements to the value stream are managed through continual improvement.

The organizations and people dimension covers structure, culture, roles, responsibilities, competences and the way people communicate and collaborate; it is the dimension most often responsible for project failure.

Key project roles include sponsor (accountable for the business case and outcomes), project manager (accountable for delivery), team members, and stakeholders; the service owner is accountable for the service across its life.

A RACI model assigns responsibility, accountability, consultation and information duties; exactly one accountable party per activity is the standard rule.

Organizational structure shapes project authority: in a functional structure the project manager has little authority, in a projectized structure authority is high, and a matrix structure splits authority between functional and project lines.

A project board or steering committee provides governance: it approves the business case, authorizes stage transitions, resolves escalated issues and can stop the project.

Stakeholder engagement is continuous, not a one-off analysis; stakeholders are identified, analyzed for interest and influence, and engaged with a plan that is revisited as the project progresses.

Team competence and capacity are constraints on the plan; the ITIL 4 guiding principle 'collaborate and promote visibility' supports transparent planning and shared ownership of commitments.

Culture determines whether bad news travels upward; blameless reporting of risk and progress is a precondition for effective governance and for the 'progress iteratively with feedback' principle.

Change management (the people side, not the ITIL practice) addresses resistance and adoption; a project output that users do not adopt produces no outcome regardless of technical quality.

The information and technology dimension covers the information the project needs and the technologies that support it: planning tools, collaboration platforms, repositories and reporting systems.

The service knowledge management system (SKMS) holds the project's records, decisions, risks and lessons; it is the single source of truth for project information that must survive the project.

Configuration management and the configuration management database (CMDB) record the service components a project creates or changes; a project must update the CMDB as part of handover.

Information must be accurate, timely, secure and relevant; the ITIL 4 principle 'keep it simple and practical' argues against measuring and reporting more than decisions require.

Automation of planning, testing, deployment and reporting reduces manual error and shortens feedback loops; it is enabled by the 'optimize and automate' guiding principle.

Data protection, access control and retention rules apply to project information; personal and confidential data must be classified and handled per organizational policy and applicable regulation.

Tooling should support the chosen delivery model: waterfall projects lean on stage-gate and baseline reporting, agile projects lean on backlog, burndown and continuous flow metrics.

Metrics used in projects include schedule and cost variance, scope change rate, defect and incident rates after release, and outcome measures tied to the business case; output metrics alone do not demonstrate value.

The partners and suppliers dimension covers the organizations that design, build, deliver or support project outputs, and the contracts and relationships that govern them.

ITIL 4 distinguishes a supplier (an external organization providing goods or services) from a partner (a supplier with a closer, more strategic and shared-risk relationship); the same organization can be both across different services.

Supplier and partner relationships are managed through the supplier management practice: a single point of contact, agreed service levels, shared objectives and regular performance review.

Contract types shape risk allocation: fixed-price transfers cost risk to the supplier, time-and-materials leaves cost risk with the buyer, and outcome-based contracts tie payment to realized results.

Multi-sourcing introduces integration risk; the organization remains accountable for the end-to-end service even when components are delivered by several partners, so service integration and management is needed.

Shared risk and reward, joint governance and open information sharing are characteristics of partnership-style relationships; they improve outcomes but require more investment in relationship management.

Exit and transition planning must be agreed at contract start; dependency on a single supplier for critical project components is a risk that must be assessed and treated.

Supplier performance feeds the business case and the project's risk register; a supplier failing to meet agreed levels is a project risk, not only a procurement issue.