The Accidental Project Manager: A Field Guide for Your First 90 Days

Why do so many people become project managers by accident?

Most organizations run more projects than they have trained project managers for. A new HR system needs rolling out, an office move needs coordinating, a product launch needs someone to chase twelve departments. The work lands on whoever is closest to it or most trusted to get things done, and that person rarely gets a title change or a course first.

The gap is structural. According to coverage by Consultancy.uk (2021) of the Project Management Institute's Talent Gap report, PMI projected a need for 25 million new project professionals worldwide by 2030, about 2.3 million a year. Many of those roles will be filled by people who learn project management on the job.

If you are one of them, you are in a large and normal group, and the skills are learnable.

What should you do in the first week?

Resist the urge to open a project management tool and start creating tasks. In the first week your job is to understand what you have been handed. Most accidental projects start with a vague request ('can you get the new intranet live by spring?') and a set of unspoken assumptions held by different people.

Your goal is to surface those assumptions and write them down.

• Meet the person who asked for the project (the sponsor) and ask what problem it solves, how they will judge success and what is fixed: date, budget or scope.
• Find out who else has a stake: teams affected, approvers, people who will use the result.
• Collect anything that already exists: emails, slide decks, vendor quotes, earlier attempts.
• Ask your own manager how much of your week the project is supposed to take, and what comes off your plate in return.
• Write a one-page summary of what you learned and send it to the sponsor to confirm.

That last step is the most important. A written summary turns hallway agreements into something people can correct now, rather than dispute in month three.

How do you write a one-page project charter?

A project charter is a short document that states why the project exists, what it will deliver and who is involved. Formal methods describe long charters, but for an accidental project a single page is enough and far more likely to be read. Use this template and fill every heading, even if some answers are 'not decided yet'.

• Purpose: one or two sentences on the problem the project solves.
• Outcome: what will be different when the project is finished, described so someone outside the team could check it.
• In scope: the specific deliverables.
• Out of scope: things people might assume are included but are not. This line saves more arguments than any other.
• Deadline and key dates: the end date and any fixed milestones.
• Budget: money and people time available.
• Sponsor: the person who makes final decisions and unblocks you.
• Team: names and roughly how much time each person gives.
• Known risks: the three things most likely to go wrong.
• How we will communicate: where updates go and how often.

Get the sponsor to agree to the charter in writing, even by email reply. When scope requests appear later, and they will, the charter is your reference point for asking what should move to make room.

How do you clarify who does what without formal authority?

Accidental project managers usually lead people who do not report to them. You cannot order anyone to do anything, so clarity has to do the work that authority would otherwise do. The simplest tool is a responsibility assignment matrix, often called a RACI chart.

In a RACI chart, each deliverable gets four labels. Responsible is the person or people doing the work. Accountable is the one person ultimately answerable for the result and who signs it off.

Consulted are people whose input is needed, with two-way communication. Informed are people kept up to date, with one-way communication. A common rule, described in the Wikipedia overview of responsibility assignment matrices, is that each task has exactly one accountable person.

Draft the chart yourself, then review it with each person named on it. The conversation matters more than the document. You will often discover that two managers each think they own the same decision, or that nobody thinks they are accountable for testing.

Settle those gaps early with the sponsor's help.

What does a usable project plan look like?

A usable plan is a list of deliverables, each with an owner and a target date, ordered so that dependencies are visible. It does not need to be a detailed Gantt chart. For most projects with fewer than ten people, a shared spreadsheet or a simple board in a project management tool is enough, as long as the whole team can see and update it.

Break the work into chunks small enough that each one finishes within one or two weeks. Large items like 'build intranet' hide problems until it is too late, while 'agree on navigation structure with three department heads' tells you quickly whether something is stuck.

Define what done means for each deliverable. The Scrum Guide (2020) describes a Definition of Done as a formal description of the quality standards an increment must meet, which gives everyone a shared understanding of what completed work means. You do not need to run Scrum to borrow the idea.

Writing 'done means reviewed by legal and published on the intranet' prevents the classic problem of tasks that are 90% finished for weeks.

How should you run status updates and meetings?

Pick a fixed rhythm and keep it. A common setup is a 30-minute weekly check-in with the core team and a short written update to the sponsor and stakeholders after it. Consistency builds trust, and people learn where to look for news instead of messaging you individually.

Keep meetings focused on decisions and blockers, not on reading out task lists everyone can see in the plan. Microsoft's 2025 Work Trend Index research found that 57% of meetings in its Microsoft 365 data were ad hoc calls without a calendar invite. A scheduled, predictable check-in reduces the stream of unplanned calls that eat into everyone's day, including yours.

• Overall status: on track, at risk or off track, with one sentence explaining why.
• Done since last update: the deliverables completed, not the activities.
• Next up: what is planned before the next update.
• Risks and issues: what might go wrong or already has, and what you are doing about it.
• Decisions needed: specific questions for the sponsor or stakeholders, with a date by which you need an answer.

Report bad news early and plainly. Sponsors can usually accept a slipped date if they hear about it in week four. They lose trust when they hear about it the day before launch.

A 90-day plan for accidental project managers

The first three months of a project set the habits it will run on. This sequence gives a realistic order of priorities.

1. Days 1 to 10: meet the sponsor and stakeholders, collect existing material, agree on your time allocation, write and confirm the one-page charter.
2. Days 11 to 20: draft the RACI chart, review it with each person, resolve ownership gaps with the sponsor.
3. Days 21 to 30: build the first version of the plan with deliverables, owners, dates and a definition of done for each. Set up the weekly check-in and the written status update.
4. Days 31 to 60: run the rhythm. Track progress against the plan, log decisions in one place, raise risks early and adjust the plan openly when reality changes.
5. Days 61 to 90: hold a short retrospective with the team on what is working and what is not, tidy up the plan, confirm the remaining scope with the sponsor and decide whether the project needs more time or people.

How do you avoid doing two full-time jobs?

The most common trap for accidental project managers is that the project is added on top of an unchanged workload. Coordination work is real work: preparing updates, chasing decisions, resolving conflicts and keeping the plan current can easily take a day a week or more on a modest project.

Ask your manager to agree in writing how much time the project gets and which of your regular duties pause, shrink or move to someone else. Track the hours you actually spend for the first month. If the gap between agreed and real time is large, you have data for a conversation rather than a complaint.

Our guide on preventing team burnout covers the warning signs to watch in yourself as well as your team.

Which skills should you build first?

You do not need a certification to run a good project, though formal courses can help later. The skills that matter most early are practical: writing clear summaries, running short meetings, asking direct questions about scope and ownership, and saying no or not yet without damaging relationships.

Teams also need a climate in which people raise problems early. Google's re:Work research on team effectiveness, which studied 180 teams, found psychological safety, dependability, structure and clarity, meaning and impact to be the dynamics that set effective teams apart. As an accidental project manager, structure and clarity is the area you control most directly, through the charter, roles and plan.

For the people side, see our guides on psychological safety at work and human-centered project management.

Frequently asked questions

What is an accidental project manager?

An accidental project manager is someone who becomes responsible for delivering a project without holding the project manager title or having formal training. It often happens to subject-matter experts, team leads and organized individual contributors who are asked to coordinate a rollout, launch or change. The role usually comes without direct authority over the people involved, which makes clear scope, roles and communication especially important.

Do I need a project management certification?

No. Many projects are run well by people without certifications. In the first months, practical habits matter more: a written charter, clear ownership, a shared plan and a regular status rhythm. If project work becomes a large part of your role, a structured course can help you learn the vocabulary and methods used in your organization and give you a path toward a formal project role.

What is the first thing an accidental project manager should do?

Meet the sponsor and write down what the project is supposed to achieve, what is in and out of scope, what is fixed (date, budget or scope) and who makes decisions. Send that summary back for confirmation. Starting with software or task lists before this step usually means organizing work that nobody has agreed on yet, which causes rework later.

How do I get people to do their tasks if they don't report to me?

Use clarity instead of authority. Agree on ownership with each person using a simple responsibility matrix, make the plan visible to everyone and review it weekly so commitments are public. When someone consistently misses deadlines, talk to them first to understand what is blocking them, and escalate to the sponsor or their manager only with specific facts about impact on the project.

What software should an accidental project manager use?

Use the simplest tool your team will actually open. For small projects a shared spreadsheet or a basic board is often enough. If several projects run at once or many teams are involved, dedicated project or work management software helps with dependencies, workload views and status reporting.

Check what your organization already licenses before buying something new, since adoption matters more than features.

How often should I send project status updates?

Weekly works for most projects. Send a short written update on the same day each week, covering overall status, what was completed, what is next, risks and decisions needed. Increase the frequency during critical periods such as go-live, and reduce it for long, stable phases.

The fixed schedule matters because it lets stakeholders stop chasing you for news.

Sources and further reading

• World faces growing project management talent shortage, Consultancy.uk
• Responsibility assignment matrix, Wikipedia
• The 2020 Scrum Guide, Scrum.org and ScrumInc (Schwaber and Sutherland)
• Breaking Down the Infinite Workday, Microsoft WorkLab
• Guide: Understand team effectiveness, Google re:Work