Your first week as a PM

A great first week starts before you walk in the door. Ask your hiring manager for the project charter, any existing RAID log, and recent status reports. Read them not to memorise details but to form questions - what's missing, what's vague, what seems inconsistent.

Also ask about team structure: who's on the core project team, who are the key stakeholders, and who has been in the role before. If you're replacing someone, ask if they left a handover note. (They probably didn't. That's the first lesson in project management: documentation is always less complete than you'd hope.)

Set up a simple personal onboarding tracker - a document or kanban board with three columns: People to meet, Things to read, Questions to ask. Update it every day and aim to clear it by the end of your second week.

Schedule 30-minute 1:1s with each team member and key stakeholder in your first three days. The goal isn't to gather status - it's to understand what each person cares about, what frustrates them, and what they need from a PM to do their best work.

A useful framework: ask every person three questions. (1) What's going well right now? (2) What's not going well? (3) What can I do in my first month that would make your life easier? Record the answers - patterns will emerge that none of the written documentation revealed.

Skip the impulse to 'prove yourself' by suggesting improvements on day two. Listen first. The fastest way to lose credibility is to recommend changes before you understand why things are the way they are. Most processes that look broken exist because someone was working around a constraint you haven't seen yet.

While you're listening and learning, look for small, low-effort improvements that remove a known frustration. A cluttered kanban board that needs cleaning. A status template that no one reads. A recurring meeting that's lost its purpose. These are quick wins that signal you're paying attention.

One of the highest-leverage early actions: update the risk register. It's almost certainly stale. Adding two real risks and emailing the team with 'I noticed we hadn't captured X and Y - does that feel right?' immediately positions you as someone who protects the project.

Another: clarify decision authority. Ask your sponsor: 'What decisions do you want to make yourself, and what are you happy for me to own?' That one conversation prevents weeks of backing-and-forthing on scope changes, vendor choices, and resource requests.

The most common mistake is over-promising. A new PM wants to be helpful, so they say 'I'll look into that' to every request. Thirty requests later, nothing has moved, and trust erodes faster than if you'd said 'I can do two of those this week - which matters most?'

Another trap: treating the plan as sacred. New PMs often spend their first week building a detailed Gantt chart, only to discover the underlying assumptions were wrong. Build a lightweight milestone plan first, validate it with the team, then add detail iteratively.

Finally: don't hide bad news. If you discover something's off track in your first week, surface it immediately. New PMs worry this makes them look incompetent. In reality, discovering and escalating an issue on day two demonstrates competence. Discovering it and saying nothing until week four is what erodes trust.