Partners and Suppliers in Project Management
This domain tests how projects depend on external organizations and how those dependencies are contracted, integrated and exited. Questions often involve accountability across a multi-supplier environment.
Core concepts
The supplier management practice maintains relationships and contracts; the project consumes them. Decide build, buy or reuse against capability, cost, risk and time. Contract forms range from fixed price to time and materials to outcome-based, each shifting risk differently. SLAs and OLAs set expected performance; acceptance criteria define what the project will accept.
Good practice
- Define scope, interfaces and acceptance criteria before signature.
- Keep a single point of accountability inside the project even when many suppliers deliver.
- Record supplier dependencies and risks in the plan and risk register.
- Run joint governance and performance reviews with escalation paths.
- Agree data ownership, security obligations and confidentiality.
- Plan exit and transition assistance from the start.
Worked example
A project buys a SaaS module. The contract fixes acceptance criteria, the service level, and an exit-assistance clause. The project manager records the vendor dependency in the schedule and the risk register, holds a joint steering meeting, and confirms that the vendor will hand over configuration data at exit. When the vendor misses a test window, the escalation path is invoked rather than the schedule being silently re-baselined.
Traps
Treating the contract as the relationship; signing without an exit plan; assuming a supplier's SLA guarantees your business outcome; leaving accountability unclear across multiple suppliers; discovering data-ownership gaps only at closure.