09.15 Enterprise Project Management Handbook Executive Overview

Enterprise Framework

Enterprise Project Management A Framework for Visibility, Accountability, and Strategic Execution

Why? We built this handbook to give every project — regardless of size — a consistent, trusted structure for delivering results.

Our mission: provide the framework, visibility, and accountability necessary to execute strategic initiatives by aligning people, resources, and goals.

Five Guiding Principles Resourcing Match resources to the project's complexity Visibility Asana is the single source of truth for all project work Accountability The Project Manager sets structure; departments own functional execution

Refinement We continuously evolve our methods, tools, and practices Communication Raise risks, issues, and blockers early — a no-surprise culture

2

What Qualifies as a Project A project is a temporary, organized effort with a defined purpose, clear objectives, and an expected outcome that supports a business need.

3 Defining Traits

Temporary Has a defined start and a defined end — it is not ongoing operational work.

Outcome-Focused Delivers a specific, measurable result that can be evaluated against success criteria.

Not every task is a project — the handbook helps teams make that distinction consistently.

Business-Aligned Directly supports a strategic or operational need — tied to an organizational goal.

What’s Changing Six updates to how projects enter, report, and receive support — less administrative effort, more consistency.

1

2

3

Intake

Status Reporting

Tiered Support

White glove support guides every project submission from the first request through qualification.

Status updates are generated directly from Asana content — the separate status update form is retired.

Project support and artifacts are delivered by tier, matching rigor to project complexity.

4

5

6

Common Language

Meeting Sweeps

Monthly Project Meetings

Shared terms for phases, roles, and artifacts keep every team describing project work the same way.

Recurring sweeps capture decisions, actions, and blockers from meetings directly into Asana.

A standing monthly forum reviews status, risks, and priorities with owners across the portfolio.

Asana remains the single source of truth — these changes remove duplicate reporting, not accountability.

Executive Overview | September 2026

4

Project Lifecycle and Phases Every project moves through six defined phases — from confirming the need exists to closing the record and capturing lessons learned.

Setting Expectation:

Fulfilling Expectation:

Phase 1 – Intake: Determine whether the request qualifies as a project, aligns with organizational priorities, and requires PM support before resources are committed. Key artifacts may include the intake form, business need, and sponsor identification.

Phase 4 – Execution: Deliver project outcomes while maintaining visibility, accountability, risk management, and governance. Key artifacts may include status reports, the RAID and decision log, action items, and escalation records.

Phase 2 – Initiation: Define the business problem or opportunity and confirm sponsorship before detailed planning begins. Sponsors align on desired outcomes, success measures, and the foundation for moving forward. Key artifacts may include the project brief, problem statement, objectives, defined done, initial risks, and assumptions.

Phase 5 – Completion: Confirm the organization is ready to move into implementation, launch, transition, opening, or another major milestone. The focus is organizational readiness and decision quality. Key artifacts may include the readiness assessment, sponsor approval, and operational handoff.

Phase 3 – Planning: Create a delivery-ready project plan that establishes how the work will be executed, monitored, and governed. Key artifacts may include the approved project plan, communication plan, project workspace, and kickoff readiness materials.

Executive Overview | September 2026

Phase 6 – Closure: Formally close the project and ensure knowledge, decisions, and records are retained for future use. Key artifacts may include the project closeout report, lessons learned, final status report, and archived records.

4

Roles and Accountability Four clearly defined roles — from executive sponsor to project team — eliminate ambiguity and keep every project anchored to the right level of decision authority.

Visibility

Role

Key Responsibilities

Strategic

Executive Sponsor (CEO/VP)

Sets strategic direction and ensures enterprise alignment across the project portfolio

Executive

Project Owner (Department VP/Director)

Owns business outcomes, priorities, and trade-off decisions; approves funding and resources; resolves escalations

Project Manager

Integrates timelines, risks, dependencies, decisions, and cross-functional communication into one coherent narrative

Operational

Execution

Project Team/Assignee (Support Departments)

Carry out deliverables, update task status, and raise risks/issues/dependencies early.

Why It Matters

RACI Framework RACI responsibilities are mapped to each project phase — ownership is never assumed, always assigned.

Executive Sponsor

Project Owner

Project Manager

Project Team

Intake

A

R

C

N/A

Initiation

C

A

R

I

Planning

A

C

R

I

Execution

I

A

R

R

Review / Stage Transition

I

A

R

C

Closure

I

C

R/A

I

Phase

Definitions:

Decision authority is always clear — no ambiguity over who acts

R – Responsible: The person or team assigned to complete the task or process.

In Asana, this is typically the assignee responsible for getting the work done.

Each tier has distinct scope — strategic, business, operational, execution

A – Accountable: The person answerable for the task or process being completed correctly. The person responsible or assignee reports to this person for the outcome.

Accountability is built into the structure, not assumed from seniority Role clarity reduces escalation friction and accelerates decisions

C – Consulted: Stakeholders or subject matter experts who provide input before or during the work but are not solely responsible for completing the task.

I – Informed: Individuals or groups who need to receive updates, outputs, or awareness of progress, decisions, or results 5

Tiered Support Framework Not every project needs the same level of support — the Tiered Framework matches PM engagement to project complexity, ensuring the right resources go to the right work.

Tier

Tier 1: Lead

Tier 2: Partner

Project Size

Characteristics

Minimum Support

Visibility

Big, organization-wide projects that need the most structure, visibility, and project leadership.

High impact work that touches many teams, carries more risk or complexity, and needs executive awareness.

All Project practices and documents are used, tailored to the work.

Regular executive updates, sponsor checkins, and reviews.

Cross-functional projects that need structure, coordination, project collaboration.

Meaningful business impact, multiple departments involved, moderate complexity or risk, and clear project ownership.

Project documents are used, but processes are tailored to the work.

Leadership stays informed through weekly updates and planned sponsor reviews.

Tiering Decision Factors •

Functional/operational impact, including departmental, cross-functional, enterprise, and end-user impact.

•

Strategic importance and executive visibility.

•

Level of complexity, dependency management, and outcomes.

•

Risk level, including schedule, budget, operational, safety, compliance, or brand risk

Discovery Discussion • What problem are we trying to solve?

• What outcome are we trying to achieve?

• Who has authority to make key decisions or approve tradeoffs?

• Who needs to be involved, consulted, or informed?

Tier 3: Support

Smaller or department-focused projects need simple, practical project guidance.

Limited business impact, lower risk, and usually managed within one/two department.

Basic project documents are still used, but the process stays simple to the work.

Department leaders and the project team stay informed based on team needs.

The PM raises awarenes s as needed.

• What key milestones, deadlines, readiness dates, or external commitments must be considered?

• What risks, dependencies, assumptions, or constraints could affect successful completion?

• What information, approval, or budget is needed before planning can begin?

6

Communication Management Our communication model is built on a four-step cycle that turns every meeting into clear action — no decisions lost, no tasks forgotten.

Four-Step Communication Cycle

Communication Cadence by Role Activity

Frequency

Owner

Purpose

Task Updates

As needed

Project Team/Assignee

Keep activities, blockers, dependencies, and comments current.

Status Update

Weekly

Project Manager

Provide leadership an overview of progress and readiness.

Project Status Meeting

As needed

Project Manager/Sponsor

Provide visibility and decision readiness for the project team.

PM Portfolio Review

Monthly

Project Managers, Team, and Sponsors

Overview of Project visibility, accountability, bandwidth, and milestones for the next 30 days.

Sponsor CheckIn

Biweekly / As Needed

Project Manager / Sponsor

Direction, risk review, and escalation handling.

Executive Briefing

As Requested

Project Manager / Sponsor

Support major tradeoff or Support decisions.

Go / No-Go Review

Milestone/Change Based

Functional Manager/Project Team

Confirm readiness before major milestones or launch events.

5-Minute Meeting Sweep — Run After Every Meeting

• Discuss: Does anything need follow-up, clarification, or quick alignment?

• Direct: Was guidance, a tradeoff, priority, risk response, escalation outcome, or roadblock resolution provided that should be captured?

• Do: Does any task, owner, due date, blocker, or status update need to be captured in Asana?

• Document: Does any meeting note, vendor detail, background information, or supporting file need to be saved with the project documentation?

7

Escalation Path When issues exceed a project manager's authority, a clear escalation path ensures risks surface quickly to the right decision-maker.

Project Team/Task Assignee

Project Manager

Identifies issue or risk

Assesses scope and authority

Department Head / Project Sponsor Resolves functional decisions

Executive Sponsor Final authority on strategic issues

When to Escalate

Escalation Procedure

• A decision is needed and the decision owner is unclear, unavailable, or outside the team’s authority.

• Confirm the impact: Clarify how the concern may affect scope, schedule, budget, operations, safety, compliance, quality, stakeholder commitments, or readiness.

• A timeline, milestone, or launch date is at risk and cannot be recovered by the project team.

• A resource conflict, capacity issue, or competing priority is delaying progress.

• Dependency, vendor action, approval, or handoff is blocking the next step.

• A scope, budget, safety, compliance, operational, or brand impact may require sponsor or executive direction.

• Stakeholders are not aligned on priorities, expectations, direction, or ownership.

• The same issue remains unresolved after reasonable follow-up through the normal communication cadence.

• Identify the concern: Confirm whether the item is a risk, issue, blocker, dependency, decision need, or resource concern that could affect delivery.

• Attempt normal resolution: Use the project cadence, task comments, meeting follow-up, or direct alignment with the responsible owner before escalating, when timing allows.

• Escalate with a clear ask: Raise the item to the Department Head, Project Sponsor, or next appropriate leader when the team cannot resolve it within its authority, resources, or timing. Include the decision, approval, resource, priority call, or direction needed.

• Document and follow through: Record the concern, impact, owner, due date, decision, and outcome in the appropriate project system, then track the agreed action until the issue is resolved or closed.

Escalation is not failure — it is promoting accountability .

8

Best Practices and Tools The handbook standardizes the artifacts every project must produce — and the tools every team must use — so quality and visibility are never optional.

Artifacts by Tier  Must Have: This item must be completed, maintained, or used for the assigned support tier. It is considered a baseline expectation for project visibility, accountability, decision-making, compliance, or successful delivery.

 Should Have: This item, when added to the project, improves clarity, or helps manage complexity, but it may be scaled or simplified based on project size, risk, and stakeholder need.

 Could Have: This item may be used at the discretion of the Project Manager, Sponsor, or project team when it supports better coordination, documentation, or decisionmaking. It is not a “Must Have” unless project conditions change or leadership requests it.

9

Why This Matters for the Organization The framework exists to change outcomes — effort goes where impact is highest, risks surface early, decisions rest on evidence, and knowledge outlives the project.

Capacity used well

Fewer surprises

Better decisions

Knowledge that stays

Tiering directs project management effort to the work with the most impact and risk.

Risks, blockers, and material changes surface early through a known escalation path.

Leaders decide at defined gates with intake, plan, risk, and readiness evidence in hand.

Decisions, lessons, and records are preserved at closure and reused on the next initiative.

“You can’t hit the target without aiming first — preparation is the foundation, and without it, success is just a distant dream.”

More rigor only when needed — a consistent path that turns priority ideas into delivered outcomes.

Executive Overview | September 2026

10

Now for our Regular Scheduled Programming ASANA PORTFOLIO REVIEW