Project Manager Checklist: 12 Points for Project Management

The Project Manager Checklist: What Actually Matters at Each Phase

Most project management checklists are either too generic to be useful or too granular to be practical. This one is different. It covers the specific actions, decisions, and deliverables that separate well-run projects from the ones that quietly spiral into overtime and scope creep.

The checklist is organized by project phase, with explicit decision points and common failure modes for each stage.

Pre-Project: Before You Say Yes

The most important project management work happens before the project officially starts. Skipping this phase is the single most common cause of project failure.

Feasibility Assessment

• Confirm the project has an identifiable business sponsor who can make decisions and resolve escalations
• Verify the budget is realistic for the stated scope. If the budget was set before the scope was defined, flag this immediately.
• Assess whether the required skills exist in-house or need to be hired/contracted
• Identify hard deadlines vs. preferred timelines. Hard deadlines constrain the plan; preferred timelines are negotiable.
• Check for dependencies on other projects, teams, or external vendors that could create scheduling conflicts
• Review any previous attempts to deliver similar work. Failed predecessors contain valuable lessons about what does not work.

Stakeholder Mapping

Identify everyone who can influence or is affected by the project, then categorize them by their level of authority and interest.

• Decision makers: people who can approve scope changes, budget adjustments, and timeline shifts
• Contributors: people who will do the work or provide inputs
• Influencers: people who can affect the project indirectly through organizational politics or resource allocation
• Consumers: people who will use or be affected by the project's output

For each stakeholder, document their expectations, concerns, and preferred communication frequency. Misaligned expectations are easier to fix at the start than three months into execution.

Project Initiation Checklist

Charter and Scope Definition

• Write a project charter that includes: business objective, success criteria, scope boundaries, key assumptions, and known risks
• Define scope using "in scope" and "out of scope" lists. Explicit exclusions prevent scope creep more effectively than broad inclusion statements.
• Establish the minimum viable deliverable: what is the smallest output that still delivers business value?
• Document assumptions and constraints. Every assumption is a risk that has not been acknowledged yet.
• Get written sign-off on the charter from the business sponsor and key stakeholders

Team Setup

• Confirm resource allocation with functional managers. Verbal agreements are not commitments.
• Define roles using a RACI matrix: who is Responsible, Accountable, Consulted, and Informed for each major deliverable
• Establish team norms: meeting cadence, communication channels, decision-making process, and escalation paths
• Set up the project workspace: task management tool, shared document repository, communication channels
• Schedule a kickoff meeting that covers the charter, timeline, roles, and immediate next steps

Planning Phase Checklist

Work Breakdown Structure

Decompose the project scope into manageable work packages. Each work package should be:

• Assignable to a single person or small team
• Estimable in terms of effort and duration
• Verifiable with clear completion criteria
• Small enough to track progress meaningfully (typically 1-10 days of effort)

A common mistake is creating work packages that are too large. "Build the API" is not a useful work package. "Design the API endpoints for the user management module" is.

Schedule Development

• Sequence work packages based on dependencies and constraints
• Identify the critical path: the longest chain of dependent tasks that determines the minimum project duration
• Add buffer to the schedule. The planning fallacy means estimates are almost always optimistic. Add 20-30% buffer for familiar work, 40-50% for novel work.
• Build in milestones at natural decision points where the project can be paused, adjusted, or cancelled
• Validate the schedule against resource availability. A perfect schedule is useless if key resources are unavailable.

Risk Planning

Identify risks using these categories:

• Technical risks: Can the technology deliver what is needed? Are there integration challenges?
• Resource risks: Will the team be available for the full duration? What happens if a key person leaves?
• Scope risks: How likely is scope change? How well-defined are the requirements?
• External risks: Vendor delays, regulatory changes, market shifts
• Organizational risks: Restructuring, budget cuts, shifting priorities

For each risk, document the probability (High/Medium/Low), impact (High/Medium/Low), mitigation strategy, and trigger event that indicates the risk is materializing.

Communication Plan

• Define status report frequency, format, and audience. Weekly reports for the team; biweekly summaries for executives.
• Establish escalation criteria: what constitutes a problem that needs to be escalated, to whom, and how quickly
• Set up a decision log to track all significant decisions, their rationale, and who approved them
• Create a change request process before changes start arriving. Retroactive change management does not work.

Execution Phase Checklist

Daily and Weekly Management

• Track task completion against the plan. Look for tasks that are "almost done" for more than a few days: they are usually stuck.
• Monitor resource utilization. Underutilization often signals blocked work rather than spare capacity.
• Hold brief daily standups (15 minutes maximum) focused on blockers, not status updates
• Review the risk register weekly. Update probabilities and add newly identified risks.
• Maintain a running issues log with clear owners and target resolution dates
• Track scope changes through the formal change request process. Informal scope additions are the primary driver of budget and schedule overruns.

Quality Management

• Define acceptance criteria for each deliverable before work begins, not after
• Conduct reviews or inspections at milestone points rather than only at the end
• Track defects or rework as a leading indicator of quality problems
• Ensure testing is resourced and scheduled as part of the plan, not squeezed into whatever time remains

Stakeholder Management During Execution

• Deliver bad news early. Stakeholders can handle problems; they cannot handle surprises.
• Keep status reports factual and concise. Use RAG (Red/Amber/Green) status for quick scanning.
• Schedule one-on-one check-ins with key stakeholders to surface concerns that they might not raise in group settings
• Document and communicate trade-off decisions. When scope, time, or cost must flex, make the choice explicit and get sign-off.

Monitoring and Controlling

Performance Tracking

• Compare actual progress against the baseline schedule at least weekly
• Track Earned Value metrics if the project is large enough to warrant it: Schedule Performance Index (SPI) and Cost Performance Index (CPI) provide early warning of overruns
• Monitor team velocity or throughput to detect capacity problems
• Review burn-down or burn-up charts to visualize remaining work against time

Change Control

Every change request should answer these questions:

• What is the change and why is it needed?
• What is the impact on scope, schedule, cost, and quality?
• What happens if we do not make this change?
• Who is requesting the change and who needs to approve it?

Document all approved changes and update the project baseline accordingly. Failing to update the baseline means the project will always appear to be over budget and behind schedule.

Closing Phase Checklist

• Conduct a formal handover of deliverables to the receiving team or operations
• Verify all acceptance criteria have been met and obtain written sign-off
• Close out contracts with external vendors and confirm final invoicing
• Archive project documents in an accessible location
• Release project resources and confirm their return to the resource pool
• Conduct a lessons learned session within two weeks of project completion, while memories are fresh
• Document the lessons learned in a searchable format that future project managers can access
• Update organizational templates and checklists based on what worked and what did not

The Post-Project Review

The lessons learned session should cover these specific questions:

• What did we estimate vs. what actually happened? (Effort, duration, cost)
• Which risks materialized? Which ones did we miss entirely?
• What would we do differently if we ran this project again?
• What processes or tools helped most? Which ones created friction?
• Were stakeholder expectations met? If not, where did the misalignment occur?

Checklist Anti-Patterns

A checklist is only useful if it is actually followed. Watch for these signs that the checklist has become performative rather than practical:

• Items are checked off in bulk at the end of a phase rather than completed as part of the work
• The checklist exists in a template that nobody customizes for the specific project
• Completing the checklist is treated as the goal rather than as a tool for achieving project success
• New items are never added based on lessons learned from previous projects
• The checklist is so long that team members stop reading it carefully

The best project management checklists are living documents that evolve with each project. Treat this one as a starting point and adapt it based on your organization's specific patterns of success and failure.