Project Manager Interview Questions

"I started as an analyst in an operations team. Every time we had a system change, I ended up being the person who kept the list of who was doing what and chased the loose ends, and I realised I enjoyed that more than the analysis itself. My manager let me run a small reporting upgrade, then a move of our support team onto a new ticketing process. Since then I've run four projects end to end, the largest with about twelve people across three teams over eight months. I owned the plan, the risks, the budget tracking and the weekly updates to the sponsor. What I want next is bigger cross-team work, where the hard part is getting several groups to land one thing together."

"I've seen a lot of projects with talented people still land late, and it was rarely because someone couldn't do their part. It was because two teams assumed different dates, or a decision sat with nobody for three weeks. That coordination gap is the part I like fixing. I get real satisfaction from seeing the whole picture and clearing the path so specialists can do what they're good at. I don't want to lose touch with the work, though. I still read the technical designs, sit in on key reviews and ask the team to walk me through anything I don't understand, because a project manager who can't follow the work can't spot trouble early either."

"The biggest was moving three regional offices onto one new finance system. It ran for about a year with around twenty people from finance, IT and an outside vendor. I owned the schedule, the budget tracking, the risk log and the monthly steering meeting, while the vendor's lead owned the configuration and our finance lead owned the process design. The first site went live one week late, because the data migration rehearsal showed more bad records than we expected. We added a second rehearsal for the other two sites, and both went live on their planned dates. If I did it again, I'd book two rehearsals from the start instead of treating the second one as a fix."

"On a warehouse system rollout, integration testing was meant to take three weeks, and by the end of week one we'd closed far fewer test cases than planned. That was on the critical path, so every day there moved go-live. I sat with the test lead and found the cause: the test environment kept going down, so testers were waiting half the day. I got the infrastructure team to give us a dedicated environment, split testing into two parallel streams, and asked the sponsor to move three reports that weren't needed on day one into a second release. I told the sponsor the same week that we were at risk and what I was doing about it. We went live nine days late instead of the five weeks we were heading for."

"I wouldn't say yes or no in the room. I'd ask what's driving the earlier date, because if it's a trade show, maybe only part of the product needs to be ready. Then I'd go back to the schedule with the team. A month can only come from the critical path, so I'd look at what's on it. Usually the honest answer is that same scope, same team and a month earlier doesn't fit, so I'd come back with options. We could deliver the core features on the earlier date and the rest later. We could add people or pay for overtime on the critical tasks, if the work can actually be split. Or we could overlap some phases, which saves time but raises the risk of rework. The sponsor picks, and I write down what they chose."

"First I'd find where the money is going. I'd compare what each work package has cost so far with how much of it is actually finished, because an overrun usually comes from a few places: estimates that were too low, rework, higher rates than planned, or small changes nobody costed. Then I'd build an honest forecast of the final cost from how we've really been performing, not from hoping the second half goes better. I'd tell the sponsor this week rather than wait for them to spot it, and I'd bring the cause, the new forecast and options. We could use the contingency reserve if the overrun comes from a risk we'd planned for, move some scope to a later release, change how the rest of the work is done, or ask for more budget. I'd say which one I recommend, and whatever they choose goes through change control so the baseline stays honest."

"The critical path is the longest chain of dependent tasks from start to finish. Its length is the shortest time the project can take, and any delay on it delays the end date. Say task A takes three days. B takes five days and C takes two, and both need A to finish first. D takes four days and needs both B and C. There are two paths: A, B, D is three plus five plus four, twelve days. A, C, D is three plus two plus four, nine days. So the critical path is A, B, D at twelve days. C has three days of float, so it can slip three days without moving the finish. That tells me where to watch closely and where I have room."

"Both shorten the schedule, but in different ways. Crashing means adding resources to tasks on the critical path, like extra people or paid overtime, so those tasks finish sooner. The cost is money, and it only works when the work can actually be split, since some tasks don't go faster with more people. I'd crash the tasks that give the most days back for the least extra cost first. Fast-tracking means doing tasks at the same time that were planned one after another, like starting build before design is fully signed off. That costs little money but adds risk, because if the design changes, some of the build gets redone. With both, I only touch the critical path, and I recheck after each change, because another path can become critical."

"Earned value compares three numbers at the same date. Say the whole project is budgeted at a thousand hours. By today, the plan said we'd have done four hundred hours of work, so planned value is four hundred. The work actually finished was budgeted at three hundred hours, so earned value is three hundred. We've actually spent three hundred and seventy-five hours. The schedule index is earned over planned: three hundred over four hundred, which is 0.75, so we're behind. The cost index is earned over actual: three hundred over three hundred and seventy-five, which is 0.8, so we're getting less work per hour than planned. If that continues, the estimate at completion is a thousand divided by 0.8, which is twelve hundred and fifty hours."

"I was running a rollout of a new customer database for a sales team. Every demo produced two or three more requests, like new fields or an extra report, and people assumed they were small. Individually they were, but together they were adding weeks. I started logging every request, estimating it with the team and taking a short list to the sales director every Friday with the impact on the date next to each item. Seeing it written down changed the conversation. She approved two changes that really mattered, and we put the rest into a phase two list she owned. We launched on the original date, and most of the phase two list was quietly dropped later because nobody missed it."

"I wouldn't start with the developer. When someone senior asks you for something, it's hard to say no. I'd find out how much time it took, what work got pushed back, and whether it needs testing or touches anything risky. Then I'd put it through change control after the fact, so it's visible and properly tested or taken out. I'd have a quiet word with the manager, not to tell them off, but to explain that side requests make our dates unreliable, which hurts them too, and to show them how quickly a request can go through the proper way. With the team, I'd agree that any request from outside the plan comes to me first, and I'll be the one who says not yet."

"Anyone can raise a change, but it goes into the change log with who's asking, what they want and why. Then I work out the impact with the team: effort, what it does to the schedule and whether it touches the critical path, cost, new risks, and testing. The decision goes to whoever holds that authority. We agree limits at the start, so small changes might be my call and anything that moves a milestone goes to the sponsor or a change board. If it's approved, I update the scope, the plan and the baseline, and tell everyone affected. If it's rejected, the requester hears why. Either way, it's recorded, so months later nobody argues about what was agreed."

"On a website redesign, the head of marketing kept reopening designs she'd already approved, which cost us about two weeks across the first month. Instead of escalating, I asked her for a coffee and asked what was worrying her. It turned out she'd been burned before by a launch that looked nothing like the mock-ups, so she didn't trust the early sign-offs. I changed how we worked with her. We showed her real, working pages every week instead of big design reviews every month, and each sign-off was a short written note of what she'd agreed. The reopening stopped, she became one of our strongest supporters, and she presented the launch to the leadership team herself."

"Six weeks before launch of a customer app, our security review failed on how we stored login tokens. Fixing it properly meant a delay of about three weeks, and the sponsor had already announced the date to the board. I asked for thirty minutes with her the same afternoon rather than waiting for the monthly meeting. I opened with the headline, then showed what failed and why launching as it was would be a real risk to customers. I brought three options: delay three weeks and fix it properly, launch on the announced date to our own staff only while we fix it, or cut two features to win back a week. She chose the staff launch, so she could still show something on the date, and later thanked me for not letting her find out from someone else."

"I'd stop looking at the colours and look at the evidence behind them. Which deliverables are actually finished and accepted, not just ninety percent done. Whether milestones were met with a real sign-off. How many defects are open and whether that number is climbing. Whether the teams that depend on each other agree on dates. Then I'd talk to the people doing the work one-to-one, not in a group meeting, and ask what worries them. If I find trouble, I'd change the status honestly and tell the sponsor. And I'd look at why nobody reported it. Usually people have learned that amber gets punished, so I'd make a point of thanking the first person who raises one."

"At kick-off I list everyone who pays for the project, approves it, does the work, uses the result or has their job changed by it. Then I ask the sponsor and each team lead who I've missed, because the forgotten people are often the ones who block you later, like security, legal or the team that supports the system after go-live. Next I place them on a simple grid of power and interest. People with high power and high interest I manage closely, with regular one-to-ones. High power but low interest, I keep satisfied with short summaries. End users usually have high interest but less power, so I keep them informed with demos and updates. I also note who's likely to resist and talk to them early. All of that becomes a communication plan: who gets what, how often, in which format and from whom. I revisit it at each phase, because people's interest changes."

"I keep it to one page, and the first line is the overall status with a sentence explaining why. If it's amber, I say what would make it green. Then progress against the key milestones, what's planned for the next two weeks, the top three risks and issues with their owners, and any decisions or help I need, with a name and a date against each. The asks matter most, because that's what makes a sponsor read to the end. For different audiences I change the depth, not the facts: the steering group gets the one-page view, and the team gets the detail. I send it the same day every week, and if something serious happens midweek, I don't wait for the report."

"I ran an internal tool to replace a spreadsheet the claims team used. We delivered on time and on budget, and three months later most of the team was still using the spreadsheet. The honest cause was on me. I'd treated the team lead as the voice of every user and never watched the people doing the work day to day. The tool was slower for their most common task, so they went around it. Now I define success as people using the thing, not just delivering it, and I put two or three real users into reviews from the first month. On my next project that caught a similar problem in week three, when it was cheap to fix."

"In the first few days I'd read everything: the charter, the plan, the risk and issue logs, the last few status reports and any change requests. Then I'd meet the sponsor to hear what success means to them, and have short one-to-ones with the key stakeholders and each person on the team. I'd ask the team what's really going on, because they usually know before any report shows it. By the end of the first week I'd compare real progress with the plan. I wouldn't change how the team works straight away unless something is clearly broken. By the end of the second week I'd go back to the sponsor with my honest view, and if the plan no longer holds, a proposal for a new baseline."

"I look at how well we know the requirements and how expensive change is. If the requirements are clear and stable, or change is very costly, like a data centre move or anything with regulatory approval steps, a phased waterfall plan works well. If we're not sure what users need and we can show them working pieces often, agile works better, because we learn as we go. But you need someone from the business who can make product decisions quickly. A lot of my projects end up hybrid. The organisation wants fixed milestones, a budget and a go-live date, so I plan those phases up front, and inside the build phase the team works in short iterations with regular demos. The mistake is picking one because it's fashionable."

"First, I don't leave it all to the end. I hold short reviews at each major milestone, because by closing people have forgotten the details or moved on. In the session I make it clear we're looking at how the work was set up, not who got something wrong, otherwise the useful stories never come out. I ask what went well, what didn't, and what we'd do differently, and I push for specifics. Each real lesson becomes an action with an owner, like adding a second data rehearsal to our standard plan template. Then at the kick-off of every new project, I read the lessons from similar past projects with the team. If a lesson doesn't change a template, checklist or habit, it's just a note."

"On a billing system upgrade, I noticed in planning that only one engineer understood the old interface to our payment provider. Everything she knew was in her head. I logged it as a key-person risk with high impact, and we agreed a response with her manager. She paired with a second engineer for two afternoons a week, and they wrote a short runbook for the interface together. About two months later she had an unplanned leave of three weeks, right in the middle of testing. Because the second engineer had already worked on the interface with her, testing carried on with only a couple of days lost. Without that, we'd have stopped completely."

"First I'd get the facts from the vendor: why it's late, how confident they are in the new date, and whether any part could arrive earlier. A late vendor often gives an optimistic new date, so I'd ask what the new date depends on. Then I'd check my own schedule. If the work waiting on it has at least three weeks of float, the end date doesn't move. If it's on the critical path, the whole project moves unless I act. I'd look at re-ordering work so the team can do other tasks first, testing with a partial delivery, or finding another supplier for part of it. I'd also check the contract for what we're owed. It goes in the issue log, and the sponsor hears about it within a day, with options."

"Each entry describes the risk clearly, ideally as a cause and an effect, like: because the vendor is new to us, the interface may arrive late, which would delay testing. Then it has a probability and an impact, usually on a simple scale of one to five, an owner who's actually responsible, the planned response, and a trigger that tells us it's starting to happen. To prioritise, I multiply probability by impact and look at the highest scores first, and I also consider timing, since a risk that could hit next week beats a bigger one six months out. The usual responses are to avoid it, transfer it, for example through a contract, mitigate it by making it less likely or less damaging, or accept it with a fallback plan. I review the top risks with owners every week."

"On a process change project, half my team were operations staff whose real bosses were shift managers with their own targets. In the first week I met each shift manager and agreed exactly how many hours a week their person would give us, written down, so nobody was guessing. I kept tasks small and clear so they could be done between other work, and I shared a simple weekly view of who had done what. When someone did great work, I told their manager in writing, not just the person. When someone fell behind, I asked what was getting in the way before anything else. We finished on time, and two of those people asked to join my next project."

"First I'd find out exactly what they were working on and how much of it sits on the critical path, because that tells me the real cost of losing them. Then I'd talk to the other project manager to understand why, since their need might be more urgent than mine. If we can't agree, it goes to whoever sets priorities across both projects, and I'd go with facts: losing this person moves our date by four weeks, or costs us this much extra effort. The options I'd put forward are sharing them part-time, getting a proper handover to someone else, bringing in a backfill, or accepting a new date. Once a decision is made, I update the plan and tell my stakeholders the same day."

"I want a team where someone can say I'm stuck or this won't make the date without worrying about it, because early bad news is the most useful thing on a project. I also want everyone clear on what they own and what matters most this week. When deadlines get tight, my job is to absorb the pressure from above rather than pass it straight down. I keep priorities to a short, clear list, cut meetings that aren't needed, and make trade-off calls quickly so people aren't waiting. If extra hours are needed, I ask rather than assume, keep it short, and I'm there too. And when the project lands, I make sure the sponsor knows exactly who did what."

"The triangle says three things are tied together on a project: scope, which is what we deliver, time, and cost. Quality sits in the middle and depends on all three. If you change one side, at least one other side has to move, or quality quietly takes the hit. So if someone wants more features, either the date moves, the cost goes up because we add people, or something else comes out. I find it really useful in change conversations. Instead of saying no, I say yes, and here's what it means: two extra weeks, or one more developer, or we drop this other feature. That makes the requester part of the decision instead of fighting with me about it."

"The usual answer is five stages: initiating, planning, executing, monitoring and controlling, and closing. Strictly, those are groups of activities rather than fixed phases, and a real project's phases depend on the work, like design, build and rollout, but the five make a good map. Initiating produces a charter, which says why the project exists, what it roughly covers and who the sponsor is. Planning produces the project plan with a baseline for scope, schedule and budget. Executing is where the team produces the actual deliverables. Monitoring and controlling isn't really a separate step, it runs alongside execution the whole time, comparing progress with the baseline and handling changes. Closing produces formal acceptance, the handover to whoever runs the result, released resources and lessons learned. Knowing the output of each phase helps me see if a project skipped something, like starting to build with no signed-off charter."

"A plan covers what we're delivering and what's out of scope, the work broken down, a schedule with milestones, who does what, the budget, the main risks, how we'll communicate, how changes will be handled and how we'll know each deliverable is accepted. To build it, I'd start from the brief and turn the goals into deliverables. Then I'd run workshops with the team to break those down into work packages and get estimates from the people who'll actually do the work. After that I'd sequence the work, find the critical path and check the dates against the deadline. I'd review the draft with key stakeholders, fix what they catch, and then agree it with the sponsor as the baseline we measure against."

"A work breakdown structure is a tree that splits the whole scope of the project into smaller and smaller pieces of deliverable work. The top is the final result, the next level might be major parts like design, build, data migration and training, and the bottom level is work packages. It should cover everything in scope and nothing outside it, which makes it a good check that nothing's been forgotten. I stop breaking down when a piece can be estimated with reasonable confidence, has one clear owner, and is small enough that I'd notice within a status cycle if it slipped. A common rule of thumb, often called the eight-eighty rule, is that a work package takes between eight and eighty hours of effort, so roughly a day to two weeks."