Continue alignment, build the plan, and test whether the project is realistic
By the end of your first 30 days, you should understand the project, the people involved, the intended outcomes, the major assumptions, and the questions that still need answers.

Ideally, the charter or project brief has been reviewed and approved. The stakeholder map is taking shape, roles are clearer, and scope boundaries are no longer implied. The sponsor, stakeholder committee, steering committee, and execution team should have enough shared understanding to move into planning.

But alignment is not finished at Day 30.

That is the first trap of the second month. New project managers sometimes assume that once the charter is written, everyone is aligned. In reality, alignment has to be tested as the project becomes more specific. People may agree with the objective but disagree about priorities. They may support the timeline until they see the dependencies. They may approve the scope but underestimate the effort. They may say the right people are involved, then later realize a critical decision owner was missing.

Days 31-60 are about continuing alignment while turning the foundation into a workable plan.

This is where the project moves from concept to structure. You help the team define how the work will get done, who will make decisions, what controls will be used, and whether the timeline is realistic.

Reconfirm the charter before planning expands

Use the approved charter or project brief as the anchor for planning.

Before building a detailed plan, walk the sponsor and core team through the key elements again. A good time to do this is in a project-planning kickoff meeting or on "Day 1 of Project Planning."

• What problem are we solving?

• What outcome are we trying to create?

• What is in scope?

• What is out of scope?

• What does success look like?

• What assumptions are still unverified?

• Who owns the major decisions?

• What constraints could affect delivery?

This may feel repetitive, but it prevents drift. Planning exposes gaps that were not visible during initial clarification. A stakeholder may identify a missing deliverable. A technical lead may find a timeline-changing dependency. A finance partner may correct a cost assumption. A vendor may confirm a longer lead time.

That is not failure. That is the value of planning. This is a refresher exercise, not a deep dive. Capture items requiring more time and attention in a parking lot list. Then update the project record when new information changes the baseline. The charter is not a decoration. It is the reference point for the plan.

Continue alignment through the governance structure

During the second month, stakeholder alignment becomes more concrete. Part 1 identified project stakeholders, separated project governance from OCM stakeholder discovery, and established a formal governance structure. Part 2 confirms how those groups participate in planning and decisions.

Use the formal governance model to clarify ownership in the project schedule and project plan:

• Which decisions belong with the sponsor or stakeholder committee?

• Which decisions belong with the steering committee or working managers?

• Which decisions belong with functional leaders, process owners, or technical leads?

• Who needs to approve requirements, scope, budget, timeline, or deliverables?

• Who must be consulted before major decisions?

• Who will provide resources?

• Who will represent business process, operations, or end users?

• Who will manage vendor relationships?

• Who needs communication but not meeting time?

This is where a simple RACI becomes more useful. Use it to identify where ownership is unclear or overloaded. Watch for tasks with many consulted stakeholders and no accountable owner. Watch for major deliverables where the decision owner is absent. Watch for situations where the project manager is accidentally becoming accountable for decisions that belong to a sponsor, stakeholder committee, steering committee, functional leader, or business owner.

A project manager can coordinate decisions. The project manager should not become the default owner of every decision, deliverable, or task.

Bring the team together for structured planning

A good project-planning session is not just a meeting to fill out a schedule. It translates the project objective into deliverables, milestones, tasks, dependencies, owners, timing, and decision points. It should also test whether the timeline is realistic.

Use the charter as the starting point. Then guide the team through the work:

• What major deliverables must be produced?

• What milestones prove meaningful progress?

• What tasks are needed to reach each milestone?

• Who owns each major deliverable or task group?

• What approvals are required?

• What must happen before something else can begin?

• What vendor or external activities must be included?

• What training, readiness, adoption, or communications work is required?

• What budget or procurement steps must happen?

A strong milestone is tied to an outcome, not just activity. "Requirements complete" is stronger than "requirements in progress." "Pilot group trained" is stronger than "training work underway." Good milestones are observable. They create decision points and help stakeholders understand project progression. For software and digital-product projects, they may also connect to backlog priorities, sprint cycles, release checkpoints, testing, deployment readiness, and adoption support.

Adapt planning for software and Agile delivery

Not every project plan looks like a traditional task schedule. If the project involves software development, digital products, system configuration, automation, or technical enhancements, the work may use Agile or Scrum methods.

In that environment, the planning conversation often shifts from building a fully detailed task plan up front to creating a prioritized product backlog. The backlog is the working list of features, user stories, defects, technical tasks, enhancements, and acceptance needs to be delivered over time.

At a high level, the project manager, product owner, technical lead, and delivery team should clarify:

• What outcome the software or product work must support

• Which features or capabilities are required first

• Which items belong in the initial release versus a future phase

• What dependencies exist across design, development, testing, security, data, integration, training, or deployment

• Who owns backlog priority and acceptance decisions

• How sprint planning, reviews, and release checkpoints connect back to the project timeline

Sprint planning should not be treated as separate from project planning. The sprint plan may guide near-term delivery, but the project still needs governance, scope control, stakeholder communication, risk management, financial visibility, release planning, and decision escalation.

For new project managers, the main point is simple: Agile planning still requires structure. The format may change, but the fundamentals do not. The work must be prioritized, sequenced, owned, estimated, reviewed, accepted, and connected to business outcomes.

Build a plan people believe in

A project plan should not be a fantasy document.

It should reflect the work, constraints, and capacity of the people who will deliver. If the plan assumes everyone is available full time, every handoff is immediate, every vendor response is fast, and every approval happens on the first try, the plan is probably not real.

Reality-check the plan with the team:

• Can the team explain why each milestone takes this long?

• Have you accounted for people's other work?

• Are vendors, finance, legal, IT, or leadership approvals included?

• Have dependencies been mapped?

• Have critical path items been identified?

• Has the team added reasonable buffer for unknowns?

• Would the people doing the work say the timeline is achievable?

If the answer is no, document the gap and discuss options. Options may include reducing scope, phasing delivery, adding resources, changing the date, accepting risk, or escalating for a decision. It is better to surface feasibility concerns in Month 2 than to pretend everything is fine until Month 3.

Protect the planning conversation

During this stage, keep planning grounded in the approved project foundation. Separate confirmed facts from assumptions, requirements from preferences, and real constraints from hopeful thinking.

When stakeholders push for a date, ask what trade-offs they are willing to make. When the team identifies risk, make sure it is captured rather than debated away. When a vendor or functional leader gives a dependency date, record who confirmed it and what happens if it moves.

These details make the plan usable when execution pressure increases.

Integrate OCM planning without confusing roles

Planning should account for organizational change management when the project affects people, processes, systems, roles, customer experience, reporting, or operations.

That does not mean the project manager owns OCM. It means OCM-related work must be visible in the plan where needed.

For people-impacting initiatives, identify activities led by OCM, communications, business readiness, training, or adoption leads. These may include audience analysis, change-impact assessment, training planning, readiness checkpoints, adoption support, stakeholder communications, town halls, listening sessions, or feedback forums.

Project management should coordinate these activities into the plan, confirm dependencies, and make sure OCM work is represented in milestones, risks, and communications. OCM should typically facilitate broader engagement forums and adoption activities, with project management supporting as needed.

Create the working control tools

During Days 31-60, establish the simple tools that will help you manage execution later.

At a minimum, create:

• A single safe source and administrator for all project documentation

• A milestone-based project plan

• A RAID log for risks, assumptions, issues, and dependencies

• A decision log

• A communication model

• A status-reporting format

• A change-control path for scope, schedule, budget, or deliverable changes

• A vendor or external dependency tracker if vendors are involved

• A financial baseline if budget, invoices, labor, or procurement matter

• A resource availability calendar for team and operations PTO, training, travel, and out-of-office time

These do not need to be complex. A RAID log no one reviews is not a control. A status report that hides risks is not communication. A plan that is not updated is not a plan. The value comes from rhythm, visibility, and decision support.

A simple model may include:

• Weekly team sync for progress, blockers, and next actions

• Weekly status update for the sponsor

• Bi-weekly status update for the sponsor and steering committee

• Monthly update for the sponsor and stakeholder committee

• Decision meetings when a specific choice is needed

• Steering or sponsor reviews for escalation, scope, budget, and priority issues

• Change-management or readiness updates for impacted users

When communication is predictable, stakeholders know where to look and when to expect information.

Establish the communication model

Communication should not be improvised every week.

Define who needs what information, how often, and in what format. Executives may need a short summary focused on status, risks, decisions, financial exposure, and business impact. The project team may need next actions and dependencies. Adjacent teams may need awareness of impacts. End users may need change, training, or readiness information.

Do not confuse more communication with better communication. The goal is useful communication.

A practical target for Day 60

By the end of the second month, you should have moved into a working delivery structure.

Your target should include:

• Confirmed stakeholder alignment and a refined RACI or ownership model

• Clear use of the formal governance structure for decisions and escalations

• A milestone-based project plan tied to charter outcomes

• Documented dependencies and critical path items

• A working RAID log

• A decision log and escalation path

• A communication cadence by stakeholder group

• OCM, readiness, communication, or training work represented where applicable

• A preliminary change-control process

• A baseline view of project budget, labor, vendor costs, or procurement needs where applicable

• A realistic view of timeline feasibility and trade-offs

This is where project leadership becomes more visible. You are no longer just learning the project. You are helping the team organize the work and test whether the plan can survive contact with reality.

What comes next

Once the plan is in place, the project enters the stage where discipline matters every week.

Execution is not just task completion. It is controlled movement through the plan, supported by cadenced updates, stakeholder communication, OCM coordination, scope management, risk management, vendor coordination, financial visibility, and deliverable tracking.

That is the focus of Part 3: Days 61-90 - Execute with Control.

Helpful Resources

Download the Days 31–60 Project Planning Checklist

Ready to turn your project foundation into a workable plan? Use the New Project Manager Days 31–60 Checklist to guide your planning conversations, stakeholder alignment, governance, project controls, communication cadence, and timeline reality check.

Watch the Supporting Webinar

Want more guidance on what to do after you have been handed a project? The webinar “You’ve Been Handed a Project. Now What?” provides practical guidance on moving from project intake and discovery into stakeholder alignment, scope clarification, planning, and organizing your first few months as a project manager.