Project Manager

Purpose of this page

This page defines the scope, accountability and boundaries of the Project Manager role at Agile Collective.

Use it when:

• roles feel unclear or overlapping
• responsibility is drifting or being silently reassigned
• a PM feels overextended or under-supported
• a project is experiencing friction around scope, risk or ownership

What the PM role is for

At Agile Collective, the PM’s core purpose is to make delivery possible, calm and deliberate.

You are responsible for ensuring projects:

• have clarity of intent
• move forward at a sustainable pace
• surface risks and decisions early
• stay aligned with budget, scope and capacity
• remain humane for the people doing the work

You are not expected to control everything. You are expected to notice what needs attention and bring the right people into the conversation.

Primary accountability

The PM is primarily accountable for delivery coordination and smooth running once the project becomes operationally real (from Initiation onwards).

This includes maintaining clarity, momentum and alignment across people, plans and decisions.

What the PM owns

Ownership here means: you are responsible for ensuring these things are done well and visibly, not necessarily doing all of them personally.

The PM owns:

• the overall plan and delivery timeline
• the budget and tracking of spend against it
• delivery cadence and ceremonies (planning, stand-ups, reviews, retrospectives)
• recording, tracking and communicating delivery decisions
• operational client communication and reporting
• escalation of delivery risks, constraints and dependencies
• the internal kick-off and client kick-off at Initiation
• the risk and dependencies log
• the Statement of Work, held throughout all phases. (The Sponsor approves changes; the Discovery, Design and Technical Leads contribute within their domains)
• backlog adherence: board health, definition of ready, and alignment with agreed scope
• actively reporting project status to the Projects Coordinator so that the portfolio view stays accurate

What the PM coordinates (but does not own)

The PM supports work led by others, including:

• Discovery, Design and Technical leadership
• Backlog population and refinement, owned by the Design and Technical Leads within their domains. The PM may support this if explicitly agreed at the start of the project
• resourcing discussions with the Projects Coordinator / resourcing function
• financial context in collaboration with Finance and the Projects Coordinator
• Sprint inputs, including estimation sessions and capacity planning in collaboration with Technical and Delivery leads
• Scope management, in collaboration with the Sponsor and relevant leads, ensuring changes are documented, impact assessed, and decisions made explicitly
• handover into Support and Account Management

In these areas, the PM:

• ensures the conversation happens
• ensures information flows
• ensures decisions are recorded
  …but does not unilaterally decide outcomes.

What the PM is not accountable for

To avoid ambiguity and role creep, the PM is not accountable for:

• designing the delivery approach or methodology from scratch
• UX, design, content or technical decisions
• commercial negotiation or contract sign-off
• long-term client relationship ownership
• carrying unresolved scope, commercial or political risk alone
• creating or refining backlog tasks within the Design or Technical Lead's domain, unless explicitly agreed

When issues arise in these areas, the PM’s role is to surface them early and involve the appropriate role (Sponsor, Leads, Account Manager, Delivery oversight).

If you ever feel like you’re holding something alone, raise it.

Key working relationships

The PM works most closely with:

• Projects Coordinator — shared Initiation ownership, portfolio visibility, admin and resourcing checks.
• Project Sponsor — scope thinking partner and SoW approver, available at key touch points.
• Discovery Lead — learning, prioritisation and definition
• Design Lead — solution quality, coherence, and ownership of design tasks in the backlog
• Technical Lead — feasibility, architecture, technical risk, and ownership of technical tasks in the backlog
• Backlog Steward — backlog readiness and board health, where this role is held by someone other than the PM
• Account Manager — relationship continuity and future opportunities. Needs to be kept informed when scope is under pressure or other project issues arise
• Delivery team members — day-to-day delivery, risks and dependencies
• Delivery Circle — process improvements and delivery strategy (as needed)

Day-to-day: what you’ll typically do

In practice, you’ll find yourself:

• reviewing proposals, assumptions and risks at the start of delivery
• facilitating planning, reviews, retrospectives and key conversations
• coordinating across design, technical and delivery roles
• supporting clients to understand constraints, priorities and trade-offs
• tracking progress against budget and scope without creating unnecessary overhead
• helping teams maintain clarity and momentum, especially when things feel messy
• keeping the Projects Coordinator informed of project status and any changes that affect the portfolio
• being the person who says:
  “Let’s pause and make this decision explicit.”

Success indicators

A PM is doing well at Agile Collective when:

• the project has a plan that people trust
• the project feels purposeful rather than frantic
• decisions move forward instead of being repeatedly debated
• risks surface early rather than emerging as crises
• stakeholders feel informed and confident in their decisions
• the team can make progress without constant PM intervention
• the company has a clear picture of what is in flight, where the pressure is, and what needs attention
• the PM is working at a pace that is sustainable over time

Detailed Success Indicators

1. The project has operational clarity The team understands what the goal is, what work is next, what decisions have been made, and what risks exist. People can move forward without confusion or repeatedly revisiting the same questions.

Signals:

• Sprint goals defined before sprint start (100% of sprints)
• Tasks have a clear owner and acceptance criteria (>90%)
• Key risks documented and updated at least once per sprint

What this measures - The PM's ability to structure the work and maintain a shared understanding of the project.

2. Stakeholders have the information needed to decide Clients and stakeholders feel informed, prepared, and able to make decisions without surprises.

Signals:

• Status updates sent on the agreed cadence (100%)
• Stakeholder questions acknowledged within 1 business day
• Significant project changes communicated within 2 business days

What this measures - The PM's reliability in maintaining clear information flow and stakeholder alignment.

3. The project does not depend on the PM The project runs through shared systems and visibility, not personal knowledge or constant PM intervention.

Signals:

• Key project artefacts, risks, decisions, and plan maintained in a shared workspace visible to the whole team
• When the PM is absent, ceremonies run and the project moves forward without interruption
• At onboarding moments, a new team member or stakeholder can get up to speed using shared documentation without needing to ask the PM

What this measures - The PM's ability to build a resilient project structure that can operate without them being the bottleneck.

4. Delivery risk is visible and actively managed When things go off track, it shows up early. The PM ensures slippage, blockers, and scope changes are surfaced quickly, assigned a response, and communicated to the right people before they become bigger problems.

Signals:

• Blockers logged and assigned within 1 business day of being raised
• When milestones are at risk, a revised plan shared with stakeholders within 2 business days
• Scope changes documented and impact assessed before work proceeds (>90%)

What this measures - The PM's ability to maintain visibility over delivery risk and respond before issues escalate.

5. Decisions move forward and hold Decisions are made at the right time, with the right people involved, and with enough clarity that they don't need to be reopened. The project is not held back by unresolved questions or repeated debates.

Signals:

• Open decisions older than an agreed threshold flagged and assigned an owner
• Decisions documented with rationale, alternatives considered, and people involved (>90%)
• Decision log reviewed and updated at least once per sprint

What this measures - PM's ability to facilitate timely, well-informed decisions and prevent decision drag or rework.

6. The conditions for team collaboration are in place Ceremonies are productive and the team has a regular space to surface issues, reflect on how they are working, and follow through on improvements.

Signals:

• Ceremonies run to a clear agenda and produce documented outcomes (>90%)
• Retrospectives held every sprint with actions logged
• Retrospective actions followed up by the next sprint (>90%)

What this measures - The PM's attention to how the team is working, not just what they are delivering.

7. The portfolio health is visible to the rest of the company When holding more than one project, the PM ensures that key information about the portfolio is available and up to date. Stakeholders have what they need to assess how projects are progressing, where the pressure points are, and what requires attention without having to ask.

Signals:

• A portfolio-level summary covering project status, timeline, budget, risks, and capacity is maintained and shared with relevant stakeholders on a monthly basis
• Competing priorities, resource conflicts, or blockers with cross-project impact are flagged proactively before they create risk
• Context across active projects is documented and accessible, not held only in the PM's head

What this measures - The PM's ability to give the organisation a reliable, honest picture of portfolio health and support informed decision-making at a company level.

8. The PM's workload is sustainable The PM is actively managing their own capacity across projects in a way that is sustainable over time. Pressure is named and addressed rather than absorbed silently.

Signals:

• Workload reviewed at least once per sprint, with capacity concerns raised proactively
• The PM is not consistently working beyond agreed hours without flagging it
• When workload becomes unmanageable, it is surfaced in the Delivery Circle before it affects delivery or wellbeing

What this measures - The PM's ability to sustain good work over time without burning out or becoming a single point of failure across the portfolio.

Things to watch out for

1. Silent scope drift

Scope expands through conversation rather than agreement.
Decisions are implied rather than recorded.

Signals

• “We’ll just add this.”
• Budget pressure appears suddenly.
• The team feels unclear about what’s in or out.

Response Make scope and trade-offs explicit. Revisit Definition.

2. The PM becomes the decision-maker

You are informally deciding UX, technical or commercial trade-offs because no one else is taking responsibility.

Signals

• Leads defer to you.
• You are answering questions outside your accountability.
• Decisions are made without Sponsor involvement.

Response Pause and bring the appropriate role back into the conversation.

3. Risk is known but not escalated

You see a problem forming but hope it will resolve itself.

Signals

• “Let’s see how the next sprint goes.”
• Avoiding a difficult client conversation.
• Budget variance not yet discussed.

Response Surface early. Escalate before crisis.

4. Emotional overload or hidden strain

You are holding complexity alone.

Signals

• You are the only person tracking the real risk (often the budget!).
• You are working harder than the structure requires.
• You feel responsible for “making it work” regardless of conditions.

Response Involve Sponsor, Delivery leadership or Account Management.
The structure exists to share weight.

5. Backlog Drift

The backlog no longer reflects agreed scope. Tasks are being added informally, or the board has grown beyond what was agreed and funded.

Signals

• Stories appear without a clear link to agreed scope.
• The Design or Technical Lead is adding tasks without the PM being aware.
• The backlog has grown but budget has not changed.

Response Revisit scope with the Sponsor. Make the trade-off explicit before work begins.

6. Process rigidity

Ceremonies continue, but they are no longer serving the work.

Signals

• Meetings feel performative.
• Delivery slows but rituals remain unchanged.
• The team disengages.

Response Adjust cadence or format deliberately. Process is a tool, not doctrine.

Escalation triggers

The PM should escalate when:

Budget

• Forecast variance exceeds agreed tolerance
• Scope additions are requested without agreed trade-offs
• Commercial assumptions prove incorrect

Escalate to the Sponsor and Projects Coordinator. Keep the Account Manager informed where variance may affect the client relationship or future work. It should be raised at the Project Portfolio Review.

Delivery risk

• Critical dependency blocked for more than one working week
• Repeated missed commitments across two consecutive sprints
• Technical feasibility becomes uncertain
• Definition checkpoint conditions are not met

Escalate to the Sponsor. Involve the relevant Design or Technical Lead where the risk sits within their domain. Keep the Projects Coordinator informed. If the risk points to a team health or process issue, bring it to the Delivery Circle. It should be raised at the Project Portfolio Review.

Scope & direction

• Client priorities shift materially after Definition
• Sponsor authority is unclear or contested
• Outcomes become politically sensitive

Escalate to the Sponsor and Account Manager together. Keep the Projects Coordinator informed, as scope changes can affect resourcing and sequencing across projects. It should be raised at the Project Portfolio Review.

Team health

• Delivery pace becomes unsustainable
• Conflict between roles affects progress
• The PM is acting as a single point of failure

Escalate to the Delivery Circle in the first instance. Keep the Sponsor and Projects Coordinator informed where the issue is affecting or likely to affect delivery. It should be raised at the Project Portfolio Review.

What escalation means

Escalation means:

• making the issue visible
• clarifying trade-offs
• involving the right authority
• deciding deliberately

It does not mean:

• assigning blame
• withdrawing responsibility
• abandoning delivery

Escalation protects delivery. It does not undermine it.

Last updated: 1:32pm, 15th April 2026