Skip to content
Question Vault?
Free to readNo accountNo email wallNo invented statisticsNo partial listsCopy or print any set and take it with you

Questions to Ask a Project Manager

For anyone sitting across from a project manager: hiring one, starting work on a project they run, or sounding one out about the career. The questions follow the order such a conversation usually takes, from what the job covers, through how they plan and track scope, schedule and budget, to risk and delays, the people side and the career itself. Each has a note on what a good or a worrying answer sounds like, or what to do with it.

55 questions

Want questions from the whole vault instead? Try the random question generator.

The questions

Each question, and why to ask it

The job

What kinds of projects have you run, and how big was the largest?

Why ask it

Get the size in plain numbers: how many people, how many months, roughly what budget. A software rollout, an office move and a building job are run very differently, so check that their projects resemble yours. If the largest was much smaller than the one in front of you, ask what they expect to change at that size.

Which parts of a project are yours to answer for, and which stay with the sponsor or the team?

Why ask it

The title covers very different jobs. In one company the project manager owns the budget and the result; in another they keep the schedule and chase updates. A good answer draws the line without hesitating, and if it stays fuzzy, ask who gets the phone call when the project is late.

What does a typical day or week look like for you?

Why ask it

Have them count it out: hours in meetings, hours keeping the plan current, hours chasing answers from other people. Anyone weighing the career should notice how much of the week is follow-up. In an interview, a candidate who describes only meetings may be letting the plan look after itself.

Do you work in Agile, waterfall or a mix, and what decides it on a given project?

Why ask it

Loyalty to one method for every job is the worrying answer. A better one starts from the work: how settled the requirements are, how often the client can look at progress, how costly a late change would be. A project where they switched approach partway, and what prompted the switch, makes a good follow-up.

How do you define success for a project?

Why ask it

On time and on budget is the standard reply, and only half of one. Stronger answers add whether the result got used, or whether the client came back for more. Ask how they checked that on their last project and how long after delivery they looked.

Which tools do you use to plan and track the work, and what lives in each?

Why ask it

The software names matter less than what is kept where. The plan should have one current home and decisions another, with nothing important living only in email. If you are joining the project, ask which of them you are expected to update and how often.

How many projects do you run at once, and how do you split your attention?

Why ask it

The number means little without the size of each, so ask for both. What you are listening for is a rule: fixed days per project, or a weekly review that decides where the hours go. 'Whichever is on fire' is honest, and it tells you the quiet projects get little attention until they stop being quiet.

What can you decide on your own, and what needs someone's sign-off?

Why ask it

Try three cases: spending money, bringing in a contractor, moving a date. Authority differs widely between employers, so no amount is the right one. What you are checking is that they know exactly where theirs stops and who holds the rest.

What happens in the first two weeks of a project you run?

Why ask it

This is their real method with the vocabulary taken out. Expect something about who they talk to, what gets written down and when the team first sees a plan. If you are about to work on one of their projects, it is also a preview of what they will ask you for first.

How do you close out a project, and what do you take from it into the next one?

Why ask it

Two things belong in the answer: a handover to whoever runs the result afterwards, and a review of how the project went. The review is the part that gets skipped, because by then everyone has moved on to other work. Have them name one lesson that changed how the next project was planned.

What do people most often get wrong about what a project manager does?

Why ask it

You may hear that the job is taken for note-taking, or that people assume the project manager can give orders. Whatever they pick is usually a frustration they live with, so ask how they deal with it. For a newcomer it also shows how the role is seen where this person works, which may not hold elsewhere.

Planning and tracking

How do you pin down the scope before work starts?

Why ask it

Listen for something written that the client or sponsor agreed to, including a list of what is left out. 'We talk it through at kickoff' is the weak version, since nobody can point to a conversation six months later. If they can share one, ask to see a scope statement from a past project.

How do you build a schedule, and where do the estimates come from?

Why ask it

Find out whether the people doing the work supply the estimates or the manager writes them alone, since a team is more likely to stand behind numbers it gave. Then bring up an estimate they thought was optimistic. Padding it quietly and challenging it openly are very different habits to work under.

How do you put a budget together, and how do you track spending against it?

Why ask it

A solid answer says how often the numbers are checked and what counts as spent: invoices paid, or work already committed. Some project managers never hold a budget at all, which depends on the employer and is no mark against them. Ask who held it, and how they found out when money was running short.

What do you need settled at a kickoff meeting before anyone starts work?

Why ask it

Their list shows what has burned them before: who approves changes, who the single contact on the client side is, what finished means. If you are the client or a new team member, treat it as your preparation list. A kickoff described only as introductions and a slide deck leaves those arguments for later.

How do you break a big project into pieces of work someone can pick up?

Why ask it

Ask how small a piece gets before they stop dividing. A useful rule sounds like 'one owner, one clear finish, a week or two at most'. Pieces that run for months with several names attached are where progress becomes impossible to see.

How do you decide who takes which piece of work?

Why ask it

Matching skill to task is the easy half. The harder half is whether they checked how many hours each person can really give the project, and whether anyone gets work that stretches them. If you are joining the team, this is the moment to say what you would like to pick up.

How much buffer do you put in a plan, and does the client know it is there?

Why ask it

Some managers show the contingency as its own line, others spread it through the tasks, and each has a defensible reason. The reasoning is what you are after. A plan with no spare time in it only works if nothing at all goes wrong, so be wary of pride in a tight schedule.

How do you prioritize when everything is labeled urgent?

Why ask it

The answer to hope for is a forced ranking agreed with whoever is paying, not longer hours. Ask for the last item they moved down the list and who they had to tell. Someone who cannot recall one has probably been saying yes to everything.

How do you make sure the work is good enough before the client sees it?

Why ask it

The check should be in the plan with time set aside for it: a review by someone who did not do the work, a test against the agreed requirements, a trial with real users. When checking is left to the final week, the faults arrive with no time to fix them. Who has the authority to say 'this is not ready' is worth asking outright.

What do you check each week to know whether a project is on track?

Why ask it

Good answers are things you can count: milestones met against planned, hours spent against the estimate, how long open problems have stayed open. 'I check in with the team' is a start, so ask what they look at when the team says everything is fine.

How do you tell whether a task reported as 90 percent done is really close?

Why ask it

A task can sit at 90 percent for weeks, and experienced managers have a way around it. They count only work that is finished and accepted, ask to see the thing, or ask how many hours are left. Someone who takes the number at face value finds out late.

How do you report progress, and what changes when the news is bad?

Why ask it

Ask who receives the report and whether the team sees the same version the sponsor does. A report that stays green until the week it turns red has been managed for comfort. Have them describe the last one they sent that they did not enjoy writing.

Risk and delays

How do you find the risks on a new project?

Why ask it

Look for a habit more than a document: asking the team what worried them on similar work, or reading how the last project of this kind went wrong. A risk register filled in once and never reopened is the usual weak spot. Ask when they last added a line to theirs.

What do you do when a project starts to fall behind?

Why ask it

A strong answer finds the cause first, then lays out options with a price on each: trim scope, add people, move the date. It ends with a recommendation taken to whoever owns the deadline. A plan that amounts to the team working harder leaves the cause where it was.

How do you handle requests for extra work once a project is under way?

Why ask it

This is scope creep, and the defense is a routine, however light: write the request down, cost it in time and money, get a yes from whoever pays. A manager who says they just absorb the small ones is describing how projects end up late with no single cause to point to.

Tell me about a project that went wrong. What would you do differently?

Why ask it

Anyone who has run projects for long has one, so a blank is its own answer. The account to trust names a decision of their own, not only a difficult client or a late supplier. The proof is something they did differently on the very next project.

How early do you tell a client or sponsor that a date is in doubt?

Why ask it

There are two camps: as soon as they suspect it, or once they are sure. An early warning that comes to nothing costs a little credibility, and a late one usually costs more. The story to get is the last alarm they raised that proved unnecessary, and how the sponsor took it.

When there is not enough time or money for everything promised, how do you get a decision on what goes?

Why ask it

The project manager rarely owns this choice, and the good ones know it. Their part is to make the trade plain to the sponsor, what each cut saves and what it takes out of the result, and to name the day by which a pick is needed. Deciding alone, or waiting until the deadline decides for everyone, are the two answers to watch for.

How do you keep risks separate from problems that have already happened?

Why ask it

A risk might happen and an issue already has, and each needs something different: a plan in waiting for the first, an owner and a due date for the second. If the two blur together in their answer, the list they keep is probably a list of worries. The example to request is a risk that came true, and what was ready when it did.

When do you escalate a problem, and who do you take it to?

Why ask it

You want a threshold, such as anything that moves a milestone or needs money they cannot approve. Escalating everything wears out a sponsor, and escalating nothing hides trouble until it is expensive. If you will be on their team, ask whether they would expect you to come to them first.

What do you do when a supplier or another team misses a date you were counting on?

Why ask it

The useful part is what they had done beforehand: a check-in ahead of the due date, a clause in the contract, a second option lined up. Afterwards, listen for how they reworked the plan and who they told. Anger at the supplier with no change to their own practice suggests it will happen again.

Have you ever recommended stopping a project?

Why ask it

Saying a project should end is one of the harder calls in the job, because the manager is arguing against their own work. A yes with a clear account of the evidence is a good sign. A no is fine from someone early in their career; ask instead what would make them raise it.

People

How do you work out who the stakeholders are at the start of a project?

Why ask it

The obvious ones name themselves. Ask about the ones who tend to surface late, such as legal, finance, security, or the people who will run the result after handover. A good follow-up is who they once left off the list and what it cost.

How do you manage stakeholders who want different things?

Why ask it

The sound approach brings the conflict into the open: both parties in one conversation, or the sponsor asked to rule. Promising each side separately is the pattern to listen for, because it only moves the argument to the end of the project. Ask how the last one was settled and who was unhappy.

What do you do when the project sponsor goes quiet?

Why ask it

A sponsor who stops answering may mean the project has dropped down someone's priorities, and that is worth finding out early. What you hope to hear is a direct question put to the sponsor, not a workaround. Carrying on with decisions unmade is the answer that ends in rework.

Tell me about a time you had to say no to a client or a senior person.

Why ask it

The story shows whether they can refuse without wrecking the relationship. Look for a no that came with a reason and an alternative, such as a later date or a smaller version. If every example ends with them giving way, the plan is set by whoever asks loudest.

How do you get work from people who do not report to you?

Why ask it

Many project managers borrow their team from other managers, so this is the center of the people side. Two things should come up: the person's time agreed with their boss up front, and requests kept small, specific and dated. Relying on being liked, or on going over someone's head, are both fragile.

How often do you meet with the team, and what is each meeting for?

Why ask it

Every meeting they name should come with a job: a short one to unblock work, a longer one to go over the plan, a separate one for the client. A single weekly hour in which everyone reports in turn mostly keeps the room waiting. If you are joining, find out which ones you must attend and which you can follow from the notes.

What do you do about a team member who keeps missing deadlines?

Why ask it

The first move should be a private conversation to find the cause: overloaded, stuck, or never clear on what was wanted. Going straight to the person's manager, or raising it in the status meeting, tells you how they would treat you in a bad month.

How do you handle a disagreement between two people on the team?

Why ask it

Ask for a real case and notice whether the dispute was about the work or about each other. Technical disagreements can often be settled with a small test or a ruling from whoever owns the design. For the personal kind, a manager who says it is not their job is telling you it will be left alone until it gets worse.

How do you keep a team going through a long or difficult stretch?

Why ask it

Pizza and praise are pleasant and beside the point. Better answers are about the work itself: shielding people from side requests, marking visible milestones, being honest about how long the hard part will last. Ask what they did the last time the team was visibly tired.

How do you run a project when the team is spread across offices or time zones?

Why ask it

The changes they describe should be concrete: more written down, decisions recorded where everyone can find them, a fixed window when the whole team is reachable. Ask what they do about the person who is never in the room when something gets decided. A manager who has only run teams in one place can say so and tell you what they would set up first.

How would the last team you led describe working with you?

Why ask it

It invites a flattering answer, so ask for the criticism too: what would they say you do too much of? If you are hiring, this is the one to check with a reference. If you are joining their project, it is a polite way to learn their habits before you run into them.

How often do you want updates from the people on your projects, and in what form?

Why ask it

Some want a line in the tracker every day, others a few sentences before the weekly meeting, and guessing wrong makes a new team member look either silent or noisy. Have them describe an update they found useful, which usually covers what got finished, what is next and what is in the way. From a candidate, the answer shows how closely they intend to watch the work.

How do you want people on your projects to bring you bad news?

Why ask it

Meant for someone starting on a project they run. The reply is an instruction, so follow it: straight away or at the weekly meeting, by message or in person, with a proposed fix or without. Then ask what happened the last time someone did, since that tells you whether the invitation is real.

What do you need from the people on your projects that you do not always get?

Why ask it

Expect something small and repeated: an honest estimate, a status update without being chased, a warning the day a task gets stuck. Whatever they name, doing it reliably is the cheapest way to be valued on their team. In an interview, it shows whether they see the team as partners or as a source of delay.

Career

How did you get into project management?

Why ask it

Plenty of project managers came from another job, such as engineering, construction, marketing or administration, after organizing something well. Note which background theirs was, because it shapes the kind of projects they are trusted with. If you are making the same move, ask what they did in the old job that counted as experience.

Which skills matter most in the job, and which did you learn the hard way?

Why ask it

Communication and organization are the stock replies, so let those go by. The second half is where the value is: writing things down, hearing a no early, asking the question that sounds stupid. Those are the ones to practice before you need them.

Is a certification worth getting, and which one do employers in your field look for?

Why ask it

This varies by industry, country and employer, so treat one person's view as a single sample. Ask whether a credential was required for their own job, and whether it changed what they were offered or only got them the interview. Then read the postings for the jobs you want, which is where the requirement is written down.

What is the hardest part of the job?

Why ask it

You may hear about being answerable for a result while other people do the work, or about delivering news nobody wants. Notice whether the hard part they name is one you would mind. From a candidate, an answer with no real difficulty in it suggests either a short career or a guarded one.

What do you like most about the work, and what would you hand off tomorrow?

Why ask it

The pairing keeps the answer honest. If what they enjoy is the finish and what they would drop is the reporting, you have a fair picture of the trade. For a career decision, weigh the second half more, since it is the part you would do every week.

What do project managers you know go on to do next?

Why ask it

Larger projects, a program or portfolio role, running a department, or a move back into the specialty they came from are all possible, and which is usual depends on the employer. Ask what the step up required that their current job did not teach. It is also a tactful way to ask a candidate where they hope to be heading.

How are new tools, including AI, changing the way you work?

Why ask it

Ask what they have handed over, such as meeting notes or first drafts of status reports, and what they still check by hand. The specifics matter more than the enthusiasm. An account of what went wrong when they trusted a tool too far is worth more than a list of product names.

What would you tell someone moving into project management from another role?

Why ask it

Good advice here is concrete: volunteer to run something small where you are, keep a record of what you planned against what happened, sit in on a project review. If the advice is only to get a qualification, ask what they would look for if they were the one hiring a beginner.

How to get straight answers from a project manager

Practical guidance for the conversation itself

Before you sit down

Decide which conversation this is

The same list serves three different meetings. If you are hiring, spend most of the time in Planning and tracking and in Risk and delays, and turn each question into a request for the last time it happened. If you are starting on a project they run, The job and People matter most, especially the three about updates, bad news and what they need from the team. If you are sounding them out about the career, begin with their typical week and go straight to the Career group.

Choose a handful and put the deciding one first

Half an hour holds about six to eight questions once the follow-ups are counted. Take one or two from each group you need, and lead with the one whose answer could change your decision. The rest are spares for when a reply is shorter than you expected.

Ask how it works where they are

Who holds the budget, who signs contracts, which credentials are asked for and even what the title means differ from one employer, industry and country to the next. Treat every answer as a description of one workplace. When it matters to your decision, ask directly: 'Is that how it is done here, or how you have always done it?'

Read whatever already exists

A resume, a project brief or the plan for the project you are joining will answer some of this before you meet. Build on it: 'The plan shows testing in the last two weeks. What happens if the build runs late?' gets further than asking them to describe the plan from the top.

During the conversation

Ask about the last project, not the method

'How do you handle changes to scope?' gets the textbook. 'What was the last change someone asked for, and what happened to it?' gets a client, a cost and an outcome. Nearly every question under Planning and tracking, Risk and delays and People can be put the second way.

Ask to see something

A status report, a risk list or a page of a plan, with the client's name removed, shows more in a minute than a description does in ten. Some employers do not allow this, so accept a no without reading anything into it. Ask them to talk you through what is on the page instead.

Get the size of the story

How late, how far over, how many people, how long it ran. The point is not to catch anyone out. A slip of three days on a two-week job and a slip of three months on a year-long one are different stories, and the bare word 'late' hides which one you are hearing.

If you are joining their project, finish with the practical

Before you leave, know where the current plan is kept, which meetings you are expected at, who to ask when the project manager is away and what they want from you by the end of the first week. These are quick to answer and awkward to ask a month in.

Reading the answers

Vocabulary is not evidence

Terms such as critical path, sprint or change control can be picked up from a course. What they did with them cannot. When an answer is mostly terms, ask what the thing looked like on their last project and who else worked on it.

Listen for 'I' and 'we'

An account that is all 'we' leaves you unsure what this person did, so ask which part was theirs. One that is all 'I' is worth a question about the team. A project manager's results come through other people, and the good ones usually say so without being asked.

Weigh the bad project more than the good one

A project that went smoothly may have had an easy client and a strong team. How someone talks about one that went badly, what they noticed, when they spoke up, what they changed afterwards, tells you more about how they would run yours.

Check it with someone who worked with them

When hiring, if references are part of the process, put one of the same questions to a reference: what happened when a date slipped, how they delivered bad news. When joining a project, a colleague already on the team can tell you how the weekly routine really runs. Where the accounts match, you can rely on them.

More on this topic