Days 61-90 as a New Project Manager
Execute with control, sustain communication, and adapt without losing governance
By Days 61-90, the project should be moving from planning into consistent execution.
The project charter is approved and matured. Stakeholder and steering committees are established and cadenced. Roles, decision rights, and governance paths are clearly understood. The milestone plan, RAID log, decision log, communication model, vendor needs, financial baseline, and OCM-related work are visible.
Now the work has to move.
This is where many new project managers discover that execution is not simply making sure people complete tasks. Real project execution includes task coordination, status discipline, communications governance, scope management, risk identification and mitigation, vendor follow-up, financial responsibility, organizational change alignment, and deliverable acceptance.
It also requires adaptability. Plans rarely survive unchanged once work begins. Priorities shift, risks mature, people become unavailable, vendors miss dates, requirements evolve, and decisions take longer than expected. The goal is not to freeze the plan. The goal is to keep the project controlled while the team adapts.
Execution is where the project manager turns the plan into a disciplined operating rhythm.
Use the project schedule (plan) as a living control tool
The project schedule is not finished when it is created.
During execution, the schedule becomes a working control tool. It should show what is underway, what is coming next, who owns each task or deliverable, which dependencies need attention, and where milestones may be at risk.
Review the schedule regularly with the team. Do not only ask, "Is this done?" Ask more useful questions:
What was completed since the last update?
What is due next?
What is blocked?
What dependency could delay this task?
Does the owner still have the capacity to complete the work?
Has anything changed that affects the timeline?
Is the deliverable still aligned with approved scope?
Task execution should connect back to milestones. If the team is busy but milestones are not moving, the project may be active but not progressing.
A good project manager helps the team distinguish between effort and advancement.
Manage execution in traditional and Agile delivery models
Execution may look different depending on the delivery method.
In a traditional or hybrid project, the project manager may use a milestone plan, work breakdown structure, task schedule, dependency map, and status cadence to manage delivery. The focus is on confirming progress against planned deliverables, dates, owners, dependencies, risks, and approvals.
In software development, product, configuration, or iterative delivery environments, execution may run through a product backlog and sprint cycles. The team may plan work in short increments, deliver usable pieces of functionality, review outcomes, and adjust the backlog based on feedback or changing priorities.
At a high level, the project manager should understand how sprint work connects to the broader project:
Which backlog items support the approved project objectives?
Which sprint commitments support the next milestone or release?
What dependencies exist across design, development, testing, security, data, training, or deployment?
Who owns backlog priority and acceptance decisions?
What risks, blockers, or scope changes need escalation outside the delivery team?
How do sprint reviews, demos, release checkpoints, and retrospectives feed the project record?
Agile execution does not remove the need for project control. It changes how some work is planned, sequenced, reviewed, and adjusted. The project still needs governance, stakeholder communication, risk management, scope discipline, financial visibility, OCM coordination, and delivery accountability.
Typically, it is best for the project manager to align with the product manager and scrum master for visibility and communications. Project managers should not get involved with the backlog grooming or sprint cycles. That is the responsibility of the development team and leaders.
The format may change. The fundamentals do not.
Keep status updates cadenced and useful
Status reporting is not paperwork. It is how the project creates visibility, trust, and decision support.
A useful status update answers the questions stakeholders actually have:
What was completed?
What is coming next?
What has changed?
What is at risk?
What is blocked?
What decisions or support are needed?
Is the project on track, at risk, or blocked?
Keep the format consistent. Do not redesign the status report every week. If the format changes constantly, stakeholders have to relearn how to read it. A simple weekly template can work well when it clearly shows progress, delayed tasks, upcoming priorities, risks, issues, and decisions needed.
Accuracy matters more than optimism. A project reported as green while key dependencies are failing is not well managed. It is hidden risk.
Use status to make reality visible early enough for people to act.
Communicate by audience, not by habit
Different players need different levels of communication.
Executive stakeholders usually need concise information focused on progress, risk, financial exposure, trade-offs, and decisions. Sponsors and steering committees need visibility into escalations, scope movement, budget pressure, timeline risk, and priority conflicts. Project team members need task-level clarity, dependencies, blockers, and next actions. Adjacent departments need to know when the project will affect their work. End users need to understand what is changing, when it is changing, and how they will be supported.
Do not send everyone the same update simply because it is easier.
A strong communication rhythm may include:
Weekly team syncs for blockers, priorities, and next actions
Sponsor updates focused on decisions, risks, and escalations
Steering committee updates focused on governance, trade-offs, and major issues
Stakeholder committee updates focused on business alignment and strategic impact
Executive summaries when leadership attention is required
Change-readiness messages for impacted users or business groups
Communication is part of governance. It should help people understand what is happening, what has changed, what decisions are needed, and what is expected of them.
Support OCM activities without confusing roles
Execution is not only about producing deliverables. It is also about preparing people to use, adopt, support, or sustain what the project creates.
Not every project needs a formal OCM workstream. But any project that changes a process, system, role, workflow, customer experience, reporting method, or operational behavior needs some level of change planning and adoption support.
During execution, the project manager should make sure OCM-related work is visible in the plan, risks, status updates, and readiness checkpoints. That may include training development, job aids, communication timing, readiness reviews, support preparation, adoption measures, business transition activities, or go-live support.
The project manager does not need to own all of that work. OCM, communications, business readiness, training, or adoption leads may own the broader engagement activities. They may facilitate town halls, listening sessions, feedback forums, adoption sessions, readiness events, or training-related forums. Project management should support those activities, coordinate dependencies, integrate them into the project rhythm, and escalate risks when adoption work threatens business value.
Do not wait until go-live to think about adoption. A deliverable can be technically complete and still fail if people are not ready to use it.
Manage scope before it quietly expands
Scope management becomes active during execution.
As work becomes visible, stakeholders often identify new ideas, missed requirements, preferred enhancements, and urgent requests. Some may be legitimate. Some may be future-phase candidates. Some may be unrelated to the approved project.
Do not treat every request as a task.
When a new request appears, ask:
Does this directly support the approved objective?
Is it required to meet the defined success criteria?
Can it be delivered within the approved timeline, budget, and resources?
What would be displaced if this is added?
Does this require sponsor approval, steering committee review, or change control?
Scope control is not about saying no to everything. It is about making change visible, intentional, and approved.
For Agile or iterative work, the same discipline applies through backlog management. New ideas may enter the backlog, but they should still be prioritized, reviewed, estimated, and connected to release goals. A backlog should not become a side door for unmanaged scope expansion.
Manage risks, issues, and escalations
Risk management is not a one-time planning activity.
During execution, risks evolve. Some become issues. New risks appear. Old risks become irrelevant. Mitigation owners change. Dependencies move. Vendors miss dates. Decisions lag. Budget assumptions shift. Adoption concerns surface.
Review the RAID log regularly. Focus on items that could affect schedule, cost, scope, quality, adoption, vendor performance, compliance, stakeholder confidence, or business outcomes.
For each important risk or issue, clarify:
What is happening?
What is the impact?
Who owns the response?
What mitigation or recovery action is underway?
When is the next decision or update needed?
Does this need escalation?
Escalation is not failure. It is how governance works when a decision, resource, priority call, or intervention is needed.
A good escalation is clear, calm, and actionable. It explains what happened, why it matters, what has already been tried, what options exist, and what decision or support is needed.
Manage vendors and external dependencies
If vendors are involved, they need active management.
Do not assume vendor work is progressing because a contract exists or a kickoff occurred. Vendor tasks, deliverables, dependencies, invoices, approvals, lead times, service levels, quality issues, and handoffs need visibility.
During execution, track:
Vendor deliverables and due dates
Open questions or information the vendor needs
Contractual or statement-of-work boundaries
Acceptance criteria for vendor work
Delays, risks, or quality concerns
Invoice timing and budget impact
Internal owners responsible for reviewing vendor output
Vendor management is not only procurement. It is delivery coordination. If vendor work is on the critical path, vendor status belongs in the project rhythm.
Maintain financial visibility
New project managers sometimes avoid financial management because they assume it belongs only to finance or the sponsor.
You do not need to become the finance department. But you do need to understand the financial factors that can affect delivery.
Depending on the project, track:
Approved budget
Forecasted spend
Actual spend
Labor assumptions
Vendor invoices
Purchase orders
Change requests with cost impact
Budget risks or funding constraints
Financial surprises can become project surprises. If the project depends on a purchase order, vendor payment, additional labor, license cost, travel expense, or approval threshold, it belongs in your control view.
When cost changes affect scope, timeline, or delivery options, document the impact and escalate through the formal decision path.
Track deliverables through review and acceptance
A deliverable is not complete just because someone worked on it.
During execution, define what done means for each major deliverable. Confirm who reviews it, who accepts it, what criteria apply, and where the final version will be stored or handed off.
For each key deliverable, track:
Owner
Due date
Reviewers
Acceptance criteria
Current status
Open defects or feedback
Approval date
Handoff owner
In Agile delivery, acceptance may happen at the story, feature, sprint, release, or product-increment level. The same principle applies: completed work should be reviewed against agreed acceptance criteria and connected back to the outcome the project is supposed to produce.
This prevents confusion at the end of the project. It also helps the team avoid a common problem: work that is produced but not formally accepted.
A practical target for Day 90
By the end of the third month, execution should feel more controlled.
You should have:
A project schedule, delivery board, or product backlog actively used to manage work
A dependable status-reporting cadence
A clear communication rhythm by stakeholder group
A current RAID log
A decision log that prevents repeated debate
A visible change-control or backlog-prioritization process
Active scope management
Risk and issue ownership
Vendor tracking where applicable
Financial visibility where applicable
OCM or adoption support where the project affects people
Deliverable tracking through review and acceptance
You may still have problems. That is normal. Controlled execution does not mean the project has no risk. It means risks, decisions, changes, progress, and adoption needs are visible enough to manage.
What comes next
The first 90 days are not the whole project management journey. They are the foundation of a repeatable operating system.
Part 4 brings the full model together and shows how to apply the 0-90 day approach across project stages, delivery methods, stage close, and project close-out.
Download the Days 61–90 Project Execution Checklist
Ready to move from planning into consistent execution? Use the New Project Manager Days 61–90 Checklist to help you establish an execution rhythm, manage scope and risks, maintain stakeholder communication, track vendors and finances, support OCM activities, and keep deliverables moving toward acceptance.
Watch the Supporting Webinar
Want to see how the pieces of project management come together when you are handed a new project? The webinar “You’ve Been Handed a Project. Now What?” provides practical guidance on getting started, clarifying expectations, working with stakeholders, organizing the project, and building the foundation for successful delivery..
