IT Project Manager 30-60-90 Day Plan: Priorities, Deliverables & Mistakes to Avoid

An IT project manager 30-60-90 day plan should help you answer three questions: What am I responsible for? What is really happening in this project? And what can I improve without disrupting delivery?

During your first 30 days, concentrate on understanding the business outcome, stakeholders, technical landscape and actual project health. During Days 31–60, clarify ownership and strengthen the execution rhythm. By Day 90, you should be able to demonstrate more reliable information, better coordination and meaningful progress against agreed priorities.

This is not a race to introduce new templates or prove that the previous project manager was wrong. You may inherit a healthy project, a troubled migration or an initiative with unclear responsibilities. In every case, begin by listening, checking evidence and understanding who has authority to make decisions.

IT Project Manager 30-60-90 Day Plan at a Glance

Use the following framework to organize your first three months. The phases are practical checkpoints, not rigid deadlines. An urgent deployment or serious delivery risk may require immediate action regardless of the phase.

Period	Primary Goal	Key Actions	Evidence of Progress
Days 1–30	Understand & Assess	Meet stakeholders, review plans, map dependencies, validate project health	Reliable baseline and clear immediate priorities
Days 31–60	Align & Stabilize	Confirm ownership, risks, reporting, decisions and escalation	More consistent execution visibility
Days 61–90	Execute & Demonstrate Value	Resolve agreed blockers, coordinate readiness, review commitments	Credible progress and next-quarter priorities

A practical IT project manager 30-60-90 day plan starts by understanding how the project currently operates before deciding what needs to change. It is a TechTeamSynergy practical onboarding model, not a prescribed PMI methodology. It is consistent with the emphasis on tailoring, value and accountability described in PMI’s PMBOK Guide — Eighth Edition.

If you are still exploring entry into the profession rather than starting an appointed role, the separate guide to becoming an IT project manager covers that career journey.

Before You Change Anything: Understand the Project You Inherited

Your appointment does not mean the project is starting again. For example, the team may already have established a schedule, reporting routine, risk register, steering committee and technical delivery process. Some practices may be effective. Others may be outdated or followed inconsistently.

Your first responsibility is to discover which is which. An unfamiliar process is not necessarily a broken process. Otherwise, replacing established tools or meeting structures too early can interrupt delivery, weaken trust and conceal the underlying reasons for existing problems.

New Project vs. Inherited Active Project

If you join a project during initiation, your early contribution may involve helping the sponsor and relevant leads establish scope, responsibilities, governance and delivery plans.

By contrast, if you inherit an active project, many of these arrangements should already exist. Your challenge is to determine whether they remain useful and whether the team follows them.

For example, an infrastructure migration may have an approved governance calendar but no reliable process for escalating delayed network circuits. Creating another steering meeting will not solve that problem. Clarifying the existing escalation route might.

Treat the existing operating model as something to understand and assess, not something to replace automatically.

Review Existing Artifacts Before Creating New Ones

Locate the documents and systems the team actually uses: the charter or mandate, scope baseline, schedule, latest status report, RAID log, stakeholder information, responsibility mapping, decision history and vendor commitments.

For IT projects, also ask about architecture overviews, test plans, release schedules, change approvals and operational handover requirements.

Do not assume that everything lives in the project-management tool. A vendor may track delivery in its own portal, while security approvals sit in a separate workflow. Therefore, compare information across these sources and identify which record is authoritative for each important commitment.

Reuse valid existing artifacts before creating new ones. After all, a missing spreadsheet does not necessarily mean the team lacks an effective control.

Identify Immediate Commitments and Constraints

Before planning your first month, find out what cannot wait. Perhaps the steering committee meets tomorrow. A security exception expires next week. A network provider has committed to a critical installation date. A production release has only one approved weekend window.

Therefore, ask what is due, who owns it, whether it is genuinely ready and what happens if it slips.

As a result, separate urgent decisions from improvements that can be examined later. initial onboarding plan must never prevent you from addressing an imminent delivery risk.

Your First Week as an IT Project Manager

Your first week in an IT project manager 30-60-90 day plan should establish enough understanding to avoid preventable mistakes. It should not be consumed by reading every historical document or arranging introductory meetings with everyone.

Use this checklist, adapting the order to immediate delivery needs.

Priority	First-Week Action
1	Meet the sponsor and clarify expectations
2	Understand the business objective and success criteria
3	Obtain current plans, reports and project records
4	Identify urgent milestones and commitments
5	Meet essential business and technical stakeholders
6	Compare reported status with available evidence
7	Understand the technical landscape at a high level
8	Observe current meetings and governance
9	Confirm immediate decisions, issues and escalations
10	Agree your next checkpoint with the sponsor

However, if a major deployment, production incident, security decision or contractual deadline is imminent, address the immediate risk first. Complete the remaining onboarding activities around that commitment.

Meet the Sponsor and Clarify Your Mandate

Ask why the project exists, what outcomes matter, what concerns the sponsor and what they expect from you. Clarify your delegated authority. Can you approve schedule changes within an agreed tolerance? Who approves scope changes, additional spending or revised business commitments?

Do not guess. A useful first conversation ends with a shared understanding of your responsibilities, immediate priorities and escalation expectations—not a promise to fix every problem.

Collect the Current Project Information

Ask where the team maintains the live schedule, actions, risks, requirements and decisions. In particular, look for differences between official reporting and working-level records.

If the latest dashboard is green but the technical lead describes an unresolved testing dependency, record that discrepancy for validation. At this stage, you do not need perfect documentation in Week 1. You need to know where reliable information comes from and which gaps matter.

Identify Urgent Risks, Deadlines and Decisions

First, classify immediate concerns by consequence and timing. An architecture decision needed before procurement may be urgent. Reformatting the monthly status template is probably not.

For each urgent item, then establish the owner, required decision, supporting evidence and deadline. Escalate through the appropriate route where necessary.

Learn Who Makes Technical and Business Decisions

Identify the sponsor, business owner, architect, technical leads, security authority, operations owner and relevant governance bodies. For important decisions, establish who contributes, who approves, who may block progress and who accepts the outcome.

Crucially, do not confuse coordinating a decision with owning it. Where decision authority is complicated, the distinction between RACI, RASCI and DACI can help you select an appropriate clarification method.

Days 1–30: Understand & Assess

Days 1–30 of your IT project manager 30-60-90 day plan focus on developing an evidence-based understanding of the project. You should become capable of explaining its purpose, current condition, critical dependencies and decision structure without relying entirely on a dashboard.

Understand the Business Outcome

Start with the result the organization expects. A network modernization project may aim to improve branch connectivity and reduce operational risk. Replacing routers is an activity; achieving acceptable service performance is the business objective.

Next, ask the business owner how success will be evaluated. Identify important scope boundaries, acceptance criteria and constraints. This distinction matters when teams report that tasks are complete but the expected business outcome has not yet been demonstrated.

Review Scope, Schedule and Milestones

To establish the gap, review the current baseline alongside actual progress and remaining work. Are milestones supported by credible estimates? Have approved changes been incorporated? Are resource assumptions still valid? Are supplier and approval lead times represented?

For example, a software implementation may show user acceptance testing beginning Monday while the test environment remains unavailable. The schedule date alone does not establish readiness.

Therefore, discuss discrepancies with the relevant owners before changing commitments or presenting a revised forecast.

Map Stakeholders and Decision Rights

As a starting point, create or validate a lightweight stakeholder and decision map. Include the sponsor, business owner, delivery leads, architect, security, operations, vendors, end users and governance groups where relevant.

Ask five questions:

• Who owns the decision?
• Who provides specialist input?
• Who can prevent delivery from proceeding?
• Who must be informed?
• Who accepts the outcome?

Also identify informal influencers as well as formal approvers. An operations manager may not appear on the project chart yet still control access to a critical maintenance window. Validate what you learn rather than assuming the organization chart tells the full story.

Understand the Technical Landscape

You do not need to become the solution architect. You do need enough context to understand how technology affects scope, sequence, risk and approvals.

Instead, request a walkthrough of the relevant applications, infrastructure, networks, cloud services, environments, integrations and data flows. Ask which components depend on others. Determine which vendors provide critical services and which technical decisions remain open.

For an application deployment, understand whether an identity integration must be available before end-to-end testing. For a network migration, establish whether circuit delivery, firewall approval and site access are independent or sequential constraints.

However, technical specialists must continue to own technical decisions. Your role is to connect their decisions with delivery commitments.

Review Risks, Issues and Dependencies

Examine the existing RAID information: risks, assumptions, issues and dependencies. Specifically, check whether entries are current, significant items have owners, actions are realistic and escalation requirements are understood.

Even so, do not accept a register as complete simply because it contains many rows. Instead, compare it with meeting notes, supplier updates, incident information and stakeholder interviews. Important risks may not yet have been formally recorded.

Where approved tools and organizational policies allow it, AI for project risk management may support information review and pattern identification. Human judgment and accountable owners remain essential.

Establish an Initial Project Health Baseline

Create a concise view of the project’s current condition, using the available evidence. Review business outcomes, scope, schedule credibility, milestones, funding where applicable, risks, issues, decisions, capacity, stakeholders and external dependencies.

In addition, for IT projects, include relevant vendor commitments, testing readiness, security approvals and operational acceptance requirements.

Distinguish three information states:

Information State	What It Means	Example
Reported	What the existing dashboard or plan says	Release marked on schedule
Validated	What responsible owners and evidence support	Test completion and approvals confirmed
Uncertain	What requires further investigation	Production support readiness not confirmed

For example, consider a one-page Initial Project Health Snapshot showing the assessment date, key findings, important uncertainties, urgent decisions and next review.

This is a TechTeamSynergy editorial example, not an official PMI template or scoring standard.

You may discover that the project is healthier than expected—or that an apparently green project carries serious hidden risks. Neither conclusion should be reached without evidence.

Observe the Existing Delivery Rhythm

Attend the meetings needed to understand how work advances. Observe team coordination, reporting, governance reviews, vendor discussions and escalation practices.

Ask which meetings produce decisions and which merely repeat status information. If a team uses Scrum, understand its established accountabilities and events before trying to reshape them. The official Scrum Guide defines those accountabilities; a project manager’s local role should complement, not casually override, them.

For now, make a short list of possible improvements, but postpone non-urgent structural changes until you understand their consequences.

New IT Project Manager: What You Should Know by Day 30

By the end of the first month, you should be able to explain the following, even if several problems remain unresolved.

Area	Day-30 Evidence
Business purpose	Agreed outcomes and success criteria
Scope and milestones	What is committed and what remains uncertain
Stakeholders	Key business, technical and external parties
Decision authority	Owners of important approvals and outcomes
Technical landscape	Main systems, environments and interfaces
Risks and issues	Principal exposures and accountable owners
Dependencies	Critical internal and supplier commitments
Project health	Reported status compared with verified facts
Governance	Existing reporting and escalation arrangements
Immediate priorities	Urgent commitments, decisions and next actions

The objective is not a perfect project. It is a reliable starting position for the next phase.

Days 31–60: Align & Stabilize

During Days 31–60 of your IT project manager 30-60-90 day plan, focus on making the existing execution arrangements dependable. The aim is not greater administrative activity. It is clearer ownership, fewer surprises and more consistent decisions.

Confirm Roles and Ownership

First, address unclear responsibilities that affect delivery. A development team may believe infrastructure owns environment readiness, while infrastructure expects the application vendor to coordinate it. Unless clarified, both teams can report progress while the dependency remains unresolved.

Then, review the relevant responsibilities with the people involved. Use RACI matrix examples for IT projects where a formal ownership view would help. If the project’s existing arrangement already works, retain it.

However, avoid using a RACI exercise as a reason to reopen every role in the organization.

Validate the RAID Picture

Ensure the material risks, assumptions, issues and dependencies are current, owned, actionable and visible. Every critical item should have a useful next step or an explicit reason why action is pending.

Next, separate risks that may happen from issues already affecting delivery. Check whether major assumptions are still credible and whether dependency owners agree with required dates.

Ultimately, the goal is to support decisions, not to maintain a register for its own sake.

Strengthen Reporting and Decision Visibility

A useful status report should answer five questions:

1. Where are we against the agreed commitments?
2. What changed since the previous report?
3. What is at risk?
4. What decision or intervention is needed?
5. Who owns the next action?

Above all, report uncertainty rather than concealing it in a green indicator.

If suitable tools are available, AI project status reporting can help assemble and draft reports from approved information. It should not replace source verification or human approval.

Keep the existing reporting format if it answers the necessary questions effectively.

Confirm Escalation Paths

Clarify which issues the delivery team can resolve, which require functional management and which need sponsor or steering-level intervention.

Then, agree the evidence required for escalation and the expected response times where organizational policy permits.

For example, an unavailable test environment may need a technical service owner; an unapproved increase in funding may require business governance.

Escalation is not failure. Late escalation of a known blocker is often more damaging than raising a well-supported concern promptly.

Improve Meetings and Communication Cadence

Examine whether recurring meetings have a purpose, the right participants and an expected output. A weekly technical dependency review might be essential. A second meeting repeating exactly the same updates may not be.

Instead of adding another ceremony, first agree what information or decision is missing. The existing team communication strategies guide provides deeper guidance on selecting channels, improving meeting quality and reducing unnecessary coordination.

Validate Technical and Vendor Dependencies

In parallel, review material commitments with technical owners and suppliers. These may include network circuits, hardware, software releases, cloud environments, security approvals, integrations, test resources, contractual deliverables and operations readiness.

In particular, confirm the difference between a supplier’s promised date and actual evidence of readiness. If delivery depends on several teams, identify the handoff conditions between them. A migration cannot be described as ready simply because its equipment has arrived.

Address Quick Wins Without Disrupting Delivery

At this point, choose improvements that solve a visible problem and have proportionate consequences. Clarify one disputed owner. Close stale action items. Surface an overlooked supplier dependency. Improve the accuracy of a management report.

In either case, discuss changes with affected stakeholders before implementing them. Replacing the project-management platform, redesigning governance or changing reporting responsibilities can create more disruption than value during this phase.

What You Should Have Established by Day 60

Your second-month checkpoint should demonstrate working controls rather than newly created paperwork.

Control	Expected Evidence
Ownership	Critical responsibilities confirmed
RAID visibility	Material items current and assigned
Milestones	Dates supported by credible assumptions
Reporting	Agreed cadence and reliable source information
Decisions	Open decisions tracked with owners
Escalation	Appropriate channels understood and used
Dependencies	Critical handoffs visible
Actions	Follow-up responsibilities and dates clear
Stakeholder alignment	Main expectations and conflicts discussed

Where an existing practice already achieves these outcomes, confirmation is sufficient.

Days 61–90: Execute & Demonstrate Value

In the final phase of your IT project manager 30-60-90 day plan, improved understanding and coordination should begin to influence execution. Your contribution may be a resolved delivery blocker, a more credible forecast or faster access to the right decision-maker.

Remove Agreed Delivery Blockers

First, review material obstacles with their owners and agree priorities. A network cutover may be delayed because a firewall review is incomplete. You coordinate the required decision, supporting evidence and revised plan; the appropriate security authority makes the security decision.

Instead, track outcomes rather than merely the number of escalation emails sent. Some blockers require organizational support beyond your delegated authority. Make those limits visible early.

Improve Decision Flow

Examine important decisions that remain unresolved. Is the decision owner unclear? Is essential technical evidence missing? Are several governance groups waiting on one another?

Present the available options, impacts, recommendation from the accountable specialists and deadline for action.

Afterward, record the decision and communicate its consequences to affected teams. Better decision flow does not mean bypassing required approvals.

Strengthen Cross-Team Coordination

IT delivery crosses organizational boundaries. Development, infrastructure, networking, security, operations, vendors, business representatives and the PMO may each have different priorities and constraints.

Therefore, use shared milestones and dependency information to help these groups work toward the same outcome. You do not need line-management authority over every contributor. Trust, clear expectations and consistent follow-through are more useful than repeatedly invoking your job title.

For the broader people dimension, see TechTeamSynergy’s guide to leading cross-functional teams through modern leadership.

Validate Upcoming Testing, Releases and Cutover Readiness

For approaching releases or migrations, confirm that the accountable specialists have reviewed the necessary readiness conditions.

These may include environments, test entry and exit criteria, business acceptance, security approvals, change windows, communications, rollback ownership and support handover. In addition, document any missing approval and its impact.

Microsoft’s cloud migration planning guidance illustrates the importance of assessing readiness and coordinating migration sequence and timing. Apply the underlying project-management lesson only where the technical context is relevant.

The PM coordinates readiness evidence. Technical, security, business and operational authorities retain their respective approval responsibilities.

Review Vendor Commitments

Next, revisit promised dates, deliverables, dependencies and acceptance conditions with the relevant suppliers. Also check whether commercial commitments match actual resource availability and implementation readiness.

Where contractual disputes arise, engage procurement, contract management or the authorized commercial owner rather than making unauthorized concessions.

An effective vendor review identifies what the supplier must deliver next, what your organization must provide and which unresolved issue threatens the milestone.

Demonstrate Better Project Visibility

Compare current delivery information with the baseline you established during the first month.

Can stakeholders now identify major risks and owners more easily? milestone forecasts better supported? unresolved decisions being escalated earlier? Are important supplier dependencies more visible?

For this reason, do not claim improvements without a defensible comparison. A project can become more transparent while its overall status remains unfavorable. That transparency helps the organization make better decisions.

Review Progress and Next Priorities With the Sponsor

Finally, at the Day-90 checkpoint, review what you learned, what was validated, which actions were completed and what remains uncertain.

Discuss changes in project health, the most important open risks and the decisions needed from leadership.

Agree the next quarter’s priorities, including delivery objectives, unresolved dependencies, resource concerns and improvement opportunities.

Your review should make it easy for the sponsor to distinguish completed work from progress, forecasts and remaining exposure.

Your First 90 Days as an IT Project Manager: What Good Looks Like

A successful first three months does not necessarily mean that the project is finished or that every issue has been resolved. Instead, look for evidence of greater clarity and control.

Area	Positive Day-90 Evidence
Sponsor confidence	Status and concerns are explained credibly
Risks	Material exposures are known and owned
Decisions	Important decisions have identifiable authorities
Milestones	Forecasts reflect current information
Dependencies	Major cross-team and supplier constraints are visible
Escalation	Required interventions reach the right people
Teams	Ownership and handoffs are clearer
Reporting	Information is more reliable and actionable
Vendors	Commitments and acceptance conditions are understood
Priorities	The next quarter has an agreed direction

A difficult project may still be red at Day 90. If the previous green status concealed unapproved dependencies or an unrealistic schedule, making those facts visible is meaningful progress. It allows leaders to make informed decisions rather than continue operating on incorrect assumptions.

IT-Specific Issues New Project Managers Often Miss

Many IT delivery problems originate outside the tasks visible on the main project schedule.

Architecture, Infrastructure and Integration Dependencies

A deployment may depend on shared network capacity, identity services, firewall rules, APIs or infrastructure owned by another team. Ask technical leads which dependencies are critical, who owns them and what happens if they are unavailable.

Do not approve a technical design simply because it appears to support the project timeline.

Security Approvals, Test Environments and Data

Security and compliance reviews may have mandatory gates and lead times. Test environments may share resources with other projects. Data migration may require quality checks, reconciliation and business validation. Discover these constraints before treating a release date as credible.

The NIST Cybersecurity Framework 2.0 provides recognized guidance on cybersecurity risk governance. It does not assign every project security approval to the project manager.

Change Windows, Cutover and Operational Handover

Infrastructure changes may be allowed only during defined maintenance windows. A cutover also requires agreed ownership of deployment, rollback, communication and operational readiness.

Confirm who authorizes the change and who accepts the service afterward. Scheduling a deployment does not mean the receiving operations team is ready to support it.

Vendor Commitments and Technical Constraints

A supplier milestone may depend on customer-provided access, another provider’s deliverable or internal security clearance. Therefore, make these shared obligations visible.

Distinguish contractual promises from verified readiness, and involve authorized commercial owners when scope or contractual terms may change.

Deliverables: What to Understand, Confirm or Improve

The first 90 days should not produce a large collection of documents simply because templates exist. Use three practical classifications:

Must Understand	Must Establish / Confirm	May Improve
Project mandate and objectives	Clear ownership	RACI or responsibility map
Business outcomes and scope	Current RAID visibility	Stakeholder map
Schedule and milestones	Action follow-up	Dependency map
Stakeholders and governance	Reporting cadence	Communication plan
Technical dependencies	Escalation route	Governance calendar
Risks and issues	Milestone visibility	Vendor coordination
Decision authority	Decision tracking	Change-control flow
Existing plans and constraints	Reliable information sources	Improvement backlog

For example, a functioning decision log may need no changes. If decisions are being made but not communicated to affected teams, the problem may be the communication practice rather than the absence of another log.

If you genuinely need to introduce a responsibility matrix, TechTeamSynergy’s RACI Matrix guide explains how to build one.

Do not create an artifact simply because a template exists. Establish the required control using the lightest approach that works in your environment.

Quick Wins: What to Improve Without Overreaching

Safe Early Improvements

Good early improvements are focused, understandable and agreed with the people affected. Examples include clarifying an owner for a blocked deliverable, correcting outdated status information, documenting an important unresolved decision or improving visibility of a critical supplier dependency.

A quick win does not need to be dramatic. Removing confusion around an approval can prevent several teams from losing valuable time.

Evaluate whether the improvement produces a real delivery benefit rather than merely making your personal workflow more convenient.

Changes That Require Sponsor or Team Agreement

Governance redesign, methodology changes, new project-management tools, major meeting restructuring and reassignment of responsibilities can affect multiple teams.

These changes should follow the organization’s decision and change-control arrangements. Even when a process genuinely needs improvement, consider whether the project can absorb that change during a critical delivery period.

A good first-90-days plan demonstrates judgment about what not to change.

Common First-90-Day Mistakes

Mistake	Why It Hurts	Better Approach
Changing processes too early	Disrupts useful practices and trust	Observe and validate first
Acting as the technical expert	Bypasses specialist accountability	Coordinate the right experts
Ignoring informal decision-makers	Important dependencies remain hidden	Map real influence and authority
Creating too many artifacts	Adds administration without control	Reuse effective records
Accepting dates without validation	Creates unreliable commitments	Check capacity and dependencies
Hiding bad news	Delays decisions and damages confidence	Report risks with evidence
Filling the calendar with meetings	Reduces delivery time	Require a purpose and output
Ignoring dependencies	Produces late surprises	Confirm owners and handoffs
Confusing activity with progress	Conceals poor delivery outcomes	Assess evidence against milestones
Solving everything personally	Creates bottlenecks and weak ownership	Delegate, coordinate and escalate

The most damaging pattern is often a combination: a new PM changes the reporting format, schedules more meetings and announces that the project is under control—without first validating the underlying delivery facts.

Two IT Project Examples

The following scenarios are fictional illustrations. They show how the same onboarding model adapts to different technical environments.

Example 1: An Inherited Network Migration

You take responsibility for a migration covering 25 sites, several network circuit providers, firewall dependencies and limited maintenance windows.

Days 1–30: Review site readiness, provider dates, technical ownership, change approvals and operations acceptance. Discover that several scheduled migrations rely on unconfirmed circuits.

Days 31–60: Confirm dependency owners, establish a credible site readiness view and align provider escalations with the existing governance process.

Days 61–90: Coordinate approved migration readiness reviews, track resolved blockers and present the sponsor with more reliable forecasts.

Your success is not necessarily migrating all 25 sites. It is improving the organization’s ability to make safe, informed delivery commitments.

Example 2: An Enterprise Application Implementation

You inherit a SaaS implementation involving data migration, integrations, user acceptance testing, a security review and a fixed release window.

Days 1–30: Validate business acceptance criteria, integration readiness, test environments, data responsibilities and pending approvals.

Days 31–60: Clarify handoffs between the vendor, internal development team, business testers and security reviewers. Stabilize issue escalation and reporting.

Days 61–90: Coordinate release-readiness evidence, address agreed blockers and help authorized stakeholders make the go/no-go decision.

Here, the most valuable early improvement may be clearer acceptance and release readiness—not faster software development.

IT Project Manager 30-60-90 Day Plan Checklist

Use these 18 checks as a final review. Adapt them to your project’s maturity and immediate needs.

1–30 Days : Understand & Assess

• Confirm the sponsor’s expectations and your mandate.
• Understand the business outcome and scope.
• Review the current schedule and commitments.
• Identify stakeholders and decision owners.
• Map major technical risks and dependencies.
• Record a validated initial project-health baseline.

31–60 Days : Align & Stabilize

• Confirm critical responsibilities and handoffs.
• Validate current risks, issues and assumptions.
• Establish or confirm reliable reporting.
• Clarify decision tracking and escalation routes.
• Confirm major vendor and technical dependencies.
• Agree proportionate early improvements.

61–90 Days : Execute & Demonstrate Value

• Coordinate action on agreed delivery blockers.
• Improve follow-through on important decisions.
• Strengthen coordination across delivery teams.
• Validate upcoming release and handover readiness.
• Demonstrate changes in delivery visibility.
• Review progress and next priorities with the sponsor.

Frequently Asked Questions

What Should a New IT Project Manager Do in the First Week?

Meet your sponsor, understand the project’s business purpose, obtain current delivery information and identify urgent commitments. Speak with essential business and technical stakeholders. Clarify who makes decisions and observe existing governance. Prioritize any immediate deployment, security or delivery risk over routine onboarding activities.

What Should a Project Manager Accomplish in the First 30 Days?

Develop a credible understanding of objectives, scope, milestones, stakeholders, decision rights and technical dependencies. Review existing risks and delivery records, then compare reported status with evidence. The primary result should be a trustworthy project-health baseline and an agreed set of immediate priorities.

What Should an IT Project Manager’s 30-60-90 Day Plan Include?

A practical IT project manager 30-60-90 day plan should include phased objectives, realistic activities, relevant stakeholders and evidence of progress. The first month emphasizes understanding and assessment; the second confirms ownership and execution controls; the third demonstrates delivery improvements and establishes next-quarter priorities. Adapt these checkpoints to the project’s actual condition.

Should I Create a New RACI When Joining a Project?

Not automatically. First determine whether existing responsibilities are already clear and effective. If ownership or approval authority is causing delays, work with affected stakeholders to clarify the specific gap. A RACI may help, but it is not mandatory for every project or decision.

How Quickly Should a New PM Change Existing Processes?

Act immediately where safety, compliance or a critical delivery commitment requires it, using the proper authority. For non-urgent changes, observe the existing process, understand why it exists and consult affected stakeholders. Avoid replacing functioning governance simply because it is unfamiliar.

How Do I Assess the Health of an Inherited Project?

Review objectives, scope, milestones, risks, decisions, dependencies, capacity and relevant technical readiness. Compare dashboards with current evidence and discussions with accountable owners. Record what is reported, what is validated and what remains uncertain. Focus on material gaps rather than inventing a universal health score.

What Should I Show My Sponsor After 90 Days?

Show a credible view of project health, the actions completed, important decisions and changes in delivery visibility. Explain unresolved risks, milestone forecasts, vendor dependencies and what needs leadership attention. Agree the next quarter’s priorities. Do not imply that every challenge must be solved.

How Technical Does an IT Project Manager Need to Be?

Technical understanding should be sufficient to recognize important dependencies, ask informed questions and coordinate specialists. You do not need to design the network, approve security architecture or write application code. Those responsibilities belong to appropriately authorized technical and business owners.

Conclusion: Build Trust Through Better Delivery Evidence

Your IT project manager 30-60-90 day plan should follow a disciplined progression:

Understand → Validate → Align → Stabilize → Execute → Demonstrate evidence.

Start by understanding the project you have inherited. Challenge assumptions respectfully, reuse effective practices and improve the information people need to make decisions.

A successful first 90 days does not mean every problem has been solved. It means the project is easier to understand, easier to govern and more predictable than when you arrived.

Continue Learning