PM Checklist for a New Project

First, work out which situation you are in

Every checklist of this kind assumes a situation, and the assumption is usually invisible. A project that everyone already knows is failing gives you a mandate that expires in weeks; a project that is running well and was handed over because the last manager was promoted punishes exactly the moves the first one rewards. Running the wrong playbook is the most expensive mistake available in month one, and it is available on day one.

The five above come from Michael Watkins’s work on transitions, and the useful part is not the taxonomy but what each one does to your first month. In a turnaround, people already agree there is a problem, so consensus is cheap and time is not — you act early and explain later. In a realignment nobody agrees there is a problem, so your first job is not fixing anything, it is assembling enough evidence that a problem exists, and acting before you have it is how a new manager is written off as the person who arrived and broke things.

The dates in the sections below are a convenience, not a law. They exist because probation periods exist and because a plan with no dates is a wish. What the phases actually describe is a ratio: almost all learning at the start, almost all changing at the end, and a month in the middle where the two overlap and most of the work is agreeing things with people. If your situation compresses that — a delivery six weeks after you arrive — keep the order and shrink the calendar. Do not skip the diagnosis; do it in four days instead of four weeks.

Days 1–30: learn how the work actually flows

The output of the first month is a written diagnosis, and the reason to write it is that an unwritten one quietly rewrites itself to match whatever you do next. Three things get investigated: the people, the work, and the tools around the work.

The company and the people in it

Read the onboarding document. If there is not one, you have found your first deliverable and an excellent reason to talk to everybody — writing the document a new joiner needs is the least threatening way in the world to ask thirty questions. Then meet the people: your manager, the sponsor who can cancel the project, the team, the neighbouring teams you depend on, support, and the client or the person who speaks for them.

Ask everyone the same five questions, and write the answers down verbatim. What are the biggest challenges this project faces? Why is it facing them? What is the most promising opportunity nobody is taking? What would have to change for that to be taken? If you were in my position, what would you focus on first? The value is not in any single answer — it is that twelve people answering the same five questions produce a map of where the organisation disagrees with itself, and every unmanaged risk on the project lives somewhere on that map.

Sort the people you met by influence and by interest, and be honest about it rather than polite. The sponsor who has not answered an email in three weeks is still the person who can end the project. The loudest voice at standup is often low influence and high interest, and a new manager who sorts stakeholders by who talks to them most will spend month two being surprised.

The product, the process and the contract

Learn the product as a user before you learn it as a manager: use it, break it, read the last two months of support tickets. Then the business model — who pays, for what, and what would make them stop. Then the backlog and the roadmap, read with one question in mind: is this a plan or a list of everything anybody has ever asked for.

Audit the process by watching it rather than by reading about it. The wiki says Scrum; what matters is whether the retro produces changes, whether the estimate survives the sprint, whether anyone can finish anything without waiting on one person. Sit in every ceremony for two weeks and say nothing except questions.

The five numbers you can only collect now

Everything else on this list can be caught up later. This cannot. Record the five numbers in week one, before you have changed anything and before anybody expects anything of you: how long an item takes from start to done, how many items are open at once, what share of the work was unplanned, how many defects reached users, and how much of what the team committed to actually arrived. Take them from the board and the tracker as they are, however untidy — a rough number collected on day three is worth more than a precise one reconstructed on day sixty.

Two of these deserve a note. Unplanned work is the most diagnostic number on the list and almost nobody tracks it: a team where forty per cent of the week arrives unannounced does not have an estimation problem, it has an interruption problem, and no planning technique will fix it. And the say-do ratio — committed versus delivered — is the one number a business stakeholder actually feels, because predictability is what they were promised and velocity is not something they can use.

Tools, documentation, and what the last manager knew

Get into every system the work touches — the tracker, the wiki, the chat, the repository, the CICI/CDContinuous Integration / Continuous Delivery — automatic build, test and deliveryEvery commit is built and put through the tests automatically (CI), and a build that passes travels to the servers the same way (CD). The point is not automation for its own sake: it is that a breakage shows up in minutes instead of on release day.Full article →All terms, the monitoring, the client’s own portal if there is one — and note which of them is the real one. There is always a gap between the tool the process claims to use and the place decisions are actually made, and on most projects that place is a chat thread. Assess the documentation the same way: not whether it exists, but whether an engineer joining next week could use it, and write down every gap you hit as you hit it. That list is worth more in week three than it will ever be again, because after a month you will have stopped noticing.

If a previous manager is still reachable, the most valuable hour you will ever book with them is not a handover of documents — it is the risk conversation. Ask what they were worried about, what they never got to, who they would not leave alone with a client, and what they would do differently. Write it into a register the same day. A departing manager’s head is a single point of failure with a leaving date on it.

Days 31–60: agree what changes, and with whom

The second month converts a diagnosis into agreements. Almost nothing here is technical and almost all of it is conversations, which is why it is the month that new managers find least satisfying and most decides whether the third month works.

Agree what success means, in writing

Most new managers infer what is expected of them and are measured against something else. Have the conversation explicitly with whoever judges your work, and have it in five parts: what is actually going on here as you both see it (compare your diagnosis with theirs — the gaps are the interesting part); what success looks like at three and six months, in things that can be checked; what resources you need and what you will give up if you do not get them; how they prefer to be kept informed and how often; and what you want to be better at by the end of it.

Then write it down and send it to them. Not as a formality — as the thing that stops day eighty-nine from being a conversation about a target nobody mentioned in month one. If your goals for probation were set by someone else and are the wrong goals, month two is when saying so is still cheap.

Change one thing at a time

The temptation at this point is a redesign: new process, new board, new meeting structure, all in one announcement. It fails for a reason that has nothing to do with whether the new process is better — when five things change at once and delivery improves, nobody knows which change did it, and when it gets worse, everybody blames the one they disliked. Change one thing, let the team see the result, then change the next. It is slower and it is the only version that survives you being on holiday.

An early win is worth having and worth choosing carefully. The criteria are narrow: visible to the people who judge you, finished inside about four weeks, uncontroversial enough that nobody has to lose an argument for it to happen, and connected to something your manager is themselves measured on. A win that fails the last criterion is a personal achievement, which is a different and much less useful thing.

Set the communication up once

Reporting to the team and reporting to the business are two different documents and mixing them produces one that serves neither. The team needs what changed, what is blocked and what is decided; the business needs what it will get, when, what it will cost and what is at risk. Write both, keep them short, and send them on a schedule — the value of a status update is almost entirely in its predictability, because a stakeholder who knows Thursday brings an update stops asking on Tuesday.

Start one-to-ones with everyone on the team if they do not exist, monthly at minimum, and treat the first round as listening rather than as a status check. This is also where the risk work from month one turns into something continuous: by the end of month two you should have a register that somebody other than you has looked at, with owners on the rows that matter and a review attached to a meeting that already happens.

Days 61–90: land the change and name what is next

The third month is where the work becomes visible. The changes agreed in month two go in, the results are measured against the numbers from week one, and the quarter ahead gets named. The trap is the opposite of month one’s: having waited, a manager now wants to show everything at once.

Present the diagnosis and what you did about it, to the team first and the business second — in that order, because a team that learns what you told the client from the client will stop telling you things. Ship the first process improvements rather than describing them. Ask for feedback explicitly and ask for it separately: the team and your manager will not say the same thing in the same room, and the gap between the two answers is the most useful thing you will hear all quarter.

The artefact that ends the ninety days is one page, and it has five parts: what I found, what I changed, what it moved (with the week-one numbers next to today’s), what I am doing next quarter, and what I need in order to do it. One page is not a stylistic preference — it is what gets read by the person who decides whether you get the mandate for the next quarter, and a twelve-slide deck gets skimmed to slide three.

The checklist itself

The three phases as a numbered list, so a line can be referred to. Copy it, delete what does not apply to your situation, and keep the order — if the calendar is shorter than ninety days, compress the phases rather than dropping one.

Days 1–30: Immersion and adaptation

1. 1.Getting to know the company and the team

   1. 1.1Read the onboarding document, or create it if there is none.
   2. 1.2Meet the key stakeholders: management, the team, the clients.
   3. 1.3Study the organisational culture, mission, values and structure of the company.

2. 2.Analysis of the project and the processes

   1. 2.1Learn the product, the key technologies, the business model.
   2. 2.2Get to know the current backlog, the plans, the roadmap.
   3. 2.3Audit the current project management processes (Agile, Waterfall, Hybrid).

3. 3.Tools and documentation

   1. 3.1Get to know the tools in use (JIRA, Confluence, Notion, Slack and so on).
   2. 3.2Assess the quality of the technical and project documentation.
   3. 3.3Identify the gaps in the processes and document them.

Days 31–60: Optimisation and improvement

1. 4.Planning and strategy

   1. 4.1Identify the key problems and the areas for improvement.
   2. 4.2Agree your own goals and KPIsKPIKey Performance Indicator — a number that tracks healthA number chosen to show whether something is going well. The failure mode is built in: once a KPI becomes a target people are rewarded against, it stops measuring what it was picked to measure.Full article →All terms for the probation period.
   3. 4.3Draw up a clear action plan for the coming months.

2. 5.Process optimisation

   1. 5.1Make adjustments to risk management.
   2. 5.2Optimise the rituals of the team’s work (meetings, retros, standups).
   3. 5.3Review and improve the reporting and metrics system.

3. 6.Setting up communication

   1. 6.1Introduce or adapt a reporting system: meetings, dashboards, updates.
   2. 6.2Define the key communication formats for the team and for the business.
   3. 6.3Introduce best practices for working with the team.

Days 61–90: Impact and scaling

1. 7.Implementing changes

   1. 7.1Present the results of the analysis and the optimisations.
   2. 7.2Implement the first improvements in the processes.
   3. 7.3Launch initiatives to raise the team’s productivity.

2. 8.Measuring effectiveness

   1. 8.1Assess progress and get feedback from the team and from management.
   2. 8.2Analysis of the productivity indicators: velocity, cycle time, quality metrics.
   3. 8.3Identify the next improvements for the period ahead.

3. 9.Long-term strategy

   1. 9.1Define the priorities for the next quarter.
   2. 9.2Plan the scaling and the improvement of the processes.
   3. 9.3Propose strategic initiatives for the growth of the project.

Where the ninety-day plan goes wrong

The plan assumes three things that are often not true: that you have ninety days, that you have the authority to change what you find, and that the problem is the process. Each of them fails in a recognisable way.

• A delivery six weeks after you arrive. Stabilise first and diagnose in parallel — but keep the order, and get the baseline numbers in the first three days regardless.
• A brand-new project with no history. There is no listening tour to run; that is a start-up situation, and month one is building the basics rather than learning them.
• No authority to change anything. Then the deliverable is influence, not a plan, and the ninety days are spent earning the right to propose rather than proposing.
• The checklist becomes theatre: every box ticked, no diagnosis written, and month three arrives with nothing to show but a completed list.
• Rituals changed before anyone asked why they exist. The daily that looks pointless is often the only place two teams speak.
• Promising a date in week one to demonstrate confidence. You now own an estimate made before you knew anything, and it will be quoted back to you in month four.
• Making the previous manager the villain. Everyone in the room is calculating what you will say about them, and they are right to.
• Confusing being liked with being trusted. The first is pleasant in month one and worth nothing in month six.

The deepest failure is subtler than any of those. A manager runs the whole ninety days correctly, produces a clean diagnosis, changes what the diagnosis pointed at — and none of it moves, because the constraint was never in the project. Underfunding, a product nobody wants, an organisation whose incentives reward something other than delivery: process work cannot touch any of these, and applying more of it is how good managers spend two years being busy. If the numbers do not move after a genuine attempt, the next question is not which practice to try, it is whether the problem is one a project manager owns at all — and saying that out loud, early, is the more valuable contribution.

When to use it

Related pages

• ManagementRisk ManagementRisk management is deciding in advance what could go wrong, which of those things is worth spending money on now, and who will notice if one starts happening. A risk is not a problem yet, and that is the entire reason it is cheap to deal with. The page opens with the whole map — seven groups and twenty-eight lines to check your own project against — then covers how to size a risk without faking precision, the four responses, the practices that actually move the number, and six public failures with the control that was missing from each.
• ManagementMetrics & KPIA metric is a number with a written definition that a team steers by, and a KPI is one of the few metrics a team or a company has agreed to be judged on. The craft is building a chain from something the team can move this week to something the business needs this year, keeping every number honest under pressure, and reading it without fooling yourself. The page opens with one team’s finished set of metrics, then covers the words and the chain, writing a definition, Goodhart’s law and guardrails, one number at the top and the tree beneath it, reading a number, four numbers that misled their owners, and where it degrades.
• ManagementOrganisational StructuresAn organisational structure is how a company groups its work into units and who reports to whom — which decides who can give a project people, money and decisions. Line, functional and matrix are not management methodologies like Scrum or Kanban. They are the shape of the organisation a methodology has to run inside, and they set how much authority the person leading a project really has. The page opens with every common structure side by side and five questions that tell you which one you are in, then covers the two questions behind every structure, the classic hierarchies, the matrix and its nine known failure modes, project and product teams, Conway’s law, companies that tried to do without managers, and where restructuring turns into theatre.