Project Manager interview questions and answers

A typical project goes through five phases. In initiation we define why the project exists, create the business case and charter, get a sponsor and identify the key stakeholders. In planning we break the scope into deliverables, estimate effort, build the schedule and budget, identify risks and agree how we will communicate. In execution the team does the work, and I coordinate people, vendors and dependencies. Monitoring and control runs alongside execution: we track progress against the plan, manage changes, risks and issues, and report status. Finally, in closing we hand over the deliverables, get formal acceptance, release resources and run a lessons learned session so the next project benefits. In agile projects these steps repeat in short cycles, but the same ideas still apply.

I start identifying risks at the beginning of the project with the team and key stakeholders, using past lessons learned and brainstorming. I record them in a risk register. For each risk I estimate the probability and impact so we can focus on the most serious ones. Then I plan a response. We can avoid the risk by changing the plan, mitigate it to reduce its chance or impact, transfer it, for example through a contract, or accept it with a contingency reserve. Every important risk gets an owner who watches it and acts if it happens. I review the register regularly, usually weekly with the team and monthly with the sponsor, because risks change during the project. When a risk actually happens, it moves to the issue log.

I first list the stakeholders and understand what each one needs to know. A sponsor wants a short summary of progress, risks and decisions, while the team needs detailed task information. From this I make a simple communication plan: who gets what information, how often and through which channel. For example, a weekly one-page status report for the sponsor, a fortnightly steering meeting, daily stand-ups for the team and a shared project dashboard. I keep reports short and clear, using red, amber and green status honestly. If there is bad news, like a delay, I share it early together with a recovery plan, rather than waiting for the next meeting. I also check with stakeholders from time to time that the communication is still useful.

Waterfall, or predictive, delivery moves through phases in order: requirements, design, build, test and deploy, with a detailed plan up front. It works well when requirements are clear and unlikely to change, such as building an office fit-out or a regulatory system with fixed rules. Agile delivery works in short cycles, like two-week sprints, delivering small working pieces and getting feedback often. It suits projects with uncertain or changing requirements, such as a new customer app. In practice many organisations use a hybrid. For example, a bank may plan budget, compliance milestones and infrastructure in a predictive way, while the software team delivers features in sprints. I choose the approach based on how stable the requirements are, the risks and how the organisation works.

I compare actual progress with the approved baseline plan. I track the key milestones and the critical path tasks closely, because a delay there moves the end date. I also track the budget, comparing what we have spent with what we planned for the work done. For larger projects I use simple earned value measures like SPI and CPI. In agile teams I look at sprint burndown or burnup charts and velocity trends. All of this goes into a dashboard in a tool like Jira or Smartsheet. But I never rely only on the tool. I talk to the team every day, because people often know about problems before they show up in the numbers. If something is off track, I act early and report it honestly.

A project is a temporary effort with a defined start and end that creates something unique, such as launching a new mobile app. A program is a group of related projects managed together because coordinating them brings benefits you could not get separately. For example, a digital banking program might include the app, a new payments platform and staff training. A portfolio is the full set of projects and programs an organisation or department invests in to meet its strategic goals. Portfolio management decides what to fund, what to pause and how to balance risk and capacity. In short, projects focus on deliverables, programs on combined benefits and portfolios on doing the right work overall. As a project manager I need to understand where my project fits, because it affects priorities, resources and who makes key decisions.

A good project management plan explains how the project will be delivered, monitored and controlled. It starts with the scope baseline, meaning the scope statement, WBS and WBS dictionary. Then it includes the schedule with milestones and dependencies, and the budget with a cost baseline and reserves. It sets out how we will manage risk, quality, communication, stakeholders, procurement and change control, plus who is responsible for what, often shown in a RACI. I always tailor it to the project. A small internal project might need a few pages, while a large regulated project needs much more detail. The plan is a living document: baselines change only through change control, but the supporting plans are updated as we learn. Most importantly, the team and sponsor should know it and agree with it, not just have it stored somewhere.

A Scrum Master is accountable for the Scrum Team's effectiveness. They coach the team and organisation in Scrum, facilitate events when needed and help remove impediments, but they do not assign tasks or own delivery dates, because the team is self-managing. A project manager is accountable for delivering a project's objectives within agreed constraints such as scope, time, cost and quality. That often includes budgets, vendor contracts, risk management, reporting and governance across many teams or departments. In practice, the two roles overlap in places, for example both care about removing blockers and keeping stakeholders informed. In a hybrid organisation, a project manager might coordinate several Scrum teams, contracts and a fixed launch date, while each team's Scrum Master focuses on how well the team works. The key is to be clear who owns which decisions.

I start by asking whether a meeting is the right tool at all; sometimes a short message or shared document works better. If it is, I set a clear purpose, such as making a decision or resolving a blocker, and share an agenda in advance with any pre-reading. I invite only the people needed to decide or contribute, and I let others read the notes. During the meeting I keep to the timebox, steer side topics to a parking lot and make sure quieter people get a chance to speak. Before we finish, I read back the decisions and the actions, each with an owner and a due date. I send short notes the same day and track the actions in our tool, such as Jira or a RAID log. I also review recurring meetings every few weeks and cancel or shorten those that no longer add value.

I start from the approved scope statement and list the main deliverables, for example design, software, training and data migration. Then, with the people who will do the work, I break each deliverable down into smaller parts until I reach work packages that can be estimated, assigned to one owner and tracked, often around one to two weeks of effort. I follow the 100% rule, meaning the WBS includes all the work in scope and nothing outside it, and each level fully adds up to the level above. I focus on deliverables, not activities, at the upper levels. For each work package I write a short WBS dictionary entry with a description, acceptance criteria and owner. The WBS then becomes the base for estimating, building the schedule, assigning responsibilities and spotting scope creep, because anything not in it needs a change request.

Prevention starts with a clear scope statement, a work breakdown structure and acceptance criteria that the sponsor and key stakeholders sign off. I also agree on a change control process at the start, so everyone knows how changes are handled. When someone asks for something new, I log it as a change request. With the team I assess its impact on schedule, cost, quality and risk. Then the right person, usually the sponsor or a change board, decides whether to approve it, reject it or swap it for something else of similar size. If approved, I update the baseline plan and inform everyone. This does not mean refusing all changes; projects often need them. It just means every change is visible and decided consciously.

I would first have a private conversation to understand what is happening. I would describe the specific gap with examples, like two tasks finished late and with errors, and then listen. The cause might be unclear requirements, too many parallel tasks, missing skills or a personal issue. Based on that, we agree a plan together: maybe clearer task breakdown, pairing with a senior colleague, training, or moving some work to someone else for a while. I make expectations and dates clear and check in regularly, giving positive feedback when things improve. In many organisations the project manager is not the line manager, so if the problem continues, I involve their line manager in a fair and documented way. Throughout, I keep the conversation respectful and focused on the work.

I start by breaking the work into small, clear pieces using a work breakdown structure, because small tasks are easier to estimate. I always involve the people who will do the work, since their estimates are more accurate and they feel ownership. I use historical data from similar projects where possible, which is analogous estimating. For uncertain tasks I use three-point estimates with optimistic, most likely and pessimistic values. In agile teams we use story points and the team velocity to forecast. Then I map dependencies and the critical path, and add contingency for known risks rather than padding every task. I share estimates as ranges with assumptions, not single fixed numbers, and I refine them as we learn more during the project.

I share bad news as soon as I am fairly sure about it, because early warning gives the sponsor more options. I prepare before the conversation. I explain the facts clearly: what happened, why, and the impact on dates, cost or scope. I avoid blaming people. Then I present two or three options, for example accept a two-week delay, reduce scope for the first release, or add a specialist at extra cost, with the risks of each, and I give my recommendation. I finish by saying exactly what I need from the sponsor, such as a decision by Friday or help with another department. Afterwards I confirm the decision in writing and update the plan. Sponsors usually respect honesty with a plan much more than late surprises.

I identify dependencies early in planning and show them clearly in the schedule and risk register. For each one I meet the other team to agree what exactly we need, by when and who owns it, and I confirm it in writing. I try to understand their priorities too, because our need may not be their top priority. I build a good relationship with their lead and set regular short check-ins. Where possible I reduce the dependency, for example by agreeing an interface early so my team can work with a mock version. I also prepare a contingency in case it slips. If a date is at risk, I escalate early and calmly through the agreed route, with facts about the impact, rather than waiting until it is too late.

Earned value management combines scope, schedule and cost into one view. Planned value is the budgeted value of work scheduled to date, earned value is the budgeted value of work actually completed, and actual cost is what we spent. From these I calculate cost variance, EV minus AC, and schedule variance, EV minus PV, plus the indexes CPI and SPI. For example, a CPI of 0.9 means we get 90 cents of value per dollar. I then forecast with EAC, such as BAC divided by CPI if the trend continues, and ETC and VAC. EVM only works with a clear baseline and objective ways to measure progress, such as 0/100 or milestone rules, not guesses. I also check the critical path, because SPI can look fine while critical tasks slip. I use EVM trends to start conversations early, not just to fill reports.

Any change to agreed scope, schedule, cost or another baseline is raised as a change request, whoever asks for it. I then work with the team to analyse the impact on scope, time, cost, quality, risk and resources, and suggest options, such as doing it now, later or not at all. The decision goes to the right authority, which may be me for small items within agreed thresholds, the sponsor, or a change control board for larger ones. Once a decision is made, I update the baselines and plans, tell the affected people and record everything in the change log. I keep the process proportionate, because a heavy process for tiny changes pushes people to bypass it. On agile projects, the Product Owner handles backlog changes, but changes to fixed dates, budgets or contracts still need formal control.

The main factor is how well we can define the scope. If the scope is clear and stable, a fixed price contract makes sense because the seller carries the cost risk, though they will price that risk in and changes become formal. If the scope is uncertain, such as research or a new technology, a cost-reimbursable contract like cost plus fixed fee or cost plus incentive fee is more realistic, but we need strong oversight because we carry more risk. For staff augmentation or small, unclear work, time and materials works well with a not-to-exceed cap. Incentive fees help align the vendor with our goals, such as finishing early or under cost. I also consider how much capacity we have to manage the vendor and the long-term relationship. I always involve procurement and legal, and make sure the statement of work is clear.

Before the kickoff, I make sure the charter is signed and I have a draft of objectives, scope, high-level milestones and known risks. I invite the sponsor, the core team and key stakeholders, and sometimes hold a separate internal kickoff for the delivery team. I ask the sponsor to open by explaining why the project matters and what success looks like. Then we go through scope and what is out of scope, the milestones, roles using a simple RACI, the main risks and assumptions, and how we will work together: tools, meeting rhythm, reporting and how decisions and changes are made. I leave time for questions and concerns, because the kickoff is also about building trust. I end with clear next steps and owners, then send notes the same day and store everything in Confluence or the shared project space.

I build the budget bottom-up from the WBS, estimating labour, vendors, licences, hardware and other costs for each work package with the people who know the work. I add contingency reserve based on the risk register and keep management reserve for unknowns, agreed with the sponsor. I then spread the costs over time to create a cost baseline, which also helps finance plan cash flow. During the project I track actual costs and committed spend, such as signed purchase orders, every month or more often. I compare them with earned value and update the forecast, because the forecast matters more than the spend to date. If I see an overrun coming, I raise it early with options like scope trade-offs or using contingency. Any change to the baseline goes through change control, so the budget stays honest and auditable.

In the first two weeks I would focus on understanding the real situation. I would review the plan, budget, open issues and risks, and meet each team member and key stakeholder to hear what went wrong. Often the cause is unclear scope, unrealistic estimates or a dependency that keeps slipping. Then I would build a realistic re-plan with the team, including options like reducing scope for the first release, phasing delivery or adding specific skills. I would present these options to the sponsor and agree a new baseline. For the team, I would remove obvious blockers, stop unnecessary overtime and aim for a few quick wins to rebuild confidence. Finally I would set up clear tracking and honest weekly reporting, so the new plan stays credible and problems are seen early.

I would first meet each stakeholder separately to understand not just what they want but why, because the underlying interests are often easier to combine than the stated positions. I would then refer back to the project objectives and business case, which give a neutral reference point. With the team I would look for options that meet the core needs of both, for example phasing delivery, or a design that handles both cases with a simple rule. I would bring the stakeholders together, ideally with the sponsor, present the options and their impacts, and facilitate a decision. If they still cannot agree, the sponsor or steering committee decides, as that is their role. Finally I would record the decision and share it widely so the debate does not restart.

First I would map working hours and find the overlap window, which for India, the UAE and Europe is usually a few hours in the afternoon India time. I would keep live meetings in that window and rotate any difficult meeting times so one location does not always suffer. Most work would happen asynchronously, so I would invest in clear written communication: decisions recorded in Confluence, tasks with clear owners in Jira, and short written updates. I would design clean handoffs between locations so work can continue across time zones without waiting. I would also plan around different weekends and holidays, like Diwali, Eid and Christmas, in the schedule. Finally I would build trust through regular one-to-ones, video on when possible, and celebrating wins together, because distance makes misunderstandings easier.

Yes. On one project, a new regulation made a large part of the planned system unnecessary halfway through. My approach is to keep checking the business case, not just the schedule. When I saw that the benefits had dropped, I gathered evidence: the updated benefit estimate, the cost to finish, and the risks. I made the point that the money already spent is a sunk cost and the real question is whether the remaining spend is worth it. I presented three options to the steering committee: continue as planned, reduce the scope to the parts still valuable, or close the project. They chose to reduce scope, which saved a large part of the remaining budget. We then closed the removed parts properly, reassigned people and recorded lessons learned. Stopping work can be a success.

First I would assess the impact: which deliverables are affected, whether they are on the critical path, and how much the go-live date is really at risk. Then I would meet the vendor quickly, at a senior level if needed, to understand the root cause and get a credible recovery plan with dates. I would check the contract for obligations, service levels and penalties, and use them fairly to keep the vendor focused, without destroying a relationship we still need. In parallel I would look at contingency options, such as partial delivery, a temporary workaround, another supplier, or moving some scope to a later release. I would inform the sponsor early with the facts and options and agree a decision. After the crisis, I would review vendor management so warning signs are caught earlier next time.

I would first run a short discovery to agree the vision, the outcomes that matter and a high-level backlog with rough sizes, so the fixed price is based on something real. Then I would make the contract fix time and cost but treat scope as the variable, with clauses that let the client swap items of similar size without a formal change, and a clear minimum viable scope. We would order the backlog with the client so must-haves come first. During delivery, we would demo working software every sprint so the client sees progress and can steer. I would track a release burnup showing done work against total scope and forecast ranges from velocity. When new items appear, I would make the trade-off visible straight away: something else moves down or the date or budget changes. Risks like integrations would be tackled early to reduce uncertainty.

I avoid giving a single date when uncertainty is high, because it sounds precise but is usually wrong. Instead I give a range with confidence levels, for example a 50% chance by June and 85% by July. I base that on data: three-point estimates for planned work, or historical throughput and velocity for agile teams, and I run a Monte Carlo simulation where possible. I explain the few assumptions and risks that drive the range, such as a vendor API or a regulatory approval, and what we are doing to reduce them. I also separate the team's internal target from an external commitment, which should sit at a higher confidence level. Then I update the forecast regularly, so executives see the range narrow as we learn. This builds trust because surprises become rare and every change has a reason.

First I would look for objective evidence instead of status colours: milestone dates actually hit, burnup or earned value trends, open defects, test results and whether working increments have been demoed. I would check the critical path and key dependencies. In parallel, I would have private one-to-one conversations with team leads, testers and key users, because people often know the real situation but feel unsafe saying it. Once I had a clear picture, I would present it to the sponsor quickly and honestly, with facts, the likely impact and options such as reducing scope, adding capacity or moving the date. With agreement, I would create a recovery plan and new baseline through change control. Finally, I would change how status is reported, using clear criteria and evidence, and I would thank people publicly when they raise problems early, so green really means green.

I would start with one pilot project that has uncertain requirements, an engaged sponsor and a team willing to try, and agree clear outcomes for the pilot. Next, I would sit down with the PMO, finance and governance teams to tailor their requirements rather than ignore them. For example, we could replace detailed design gates with sprint reviews where they see working software, and give them burnup charts and risk updates instead of long documents. Budget could stay fixed for the year while scope is flexible within a product backlog. I would arrange training for the team and, just as important, for stakeholders and managers, and bring in an experienced coach if possible. Throughout, I would make results visible: increments delivered, feedback from users and faster decisions. Afterwards I would share honest lessons and scale gradually, adapting the approach to the organisation instead of copying a framework blindly.

First I would work with legal and compliance to confirm exactly what we must have in place by the deadline, because the regulation often requires less than the full project. That gives us a minimum compliant scope, and everything else moves to a later phase. Next I would re-plan around the critical path for that scope, using fast tracking where the rework risk is acceptable and crashing the cheapest critical tasks, such as adding experienced people early or paying for vendor priority. I would put strong risk management in place, with a contingency plan or manual workaround in case a system piece is late, so we can still comply. I would increase the rhythm of tracking, perhaps short daily checks on critical items, and report clearly to the sponsor and steering group. If compliance is still at risk, I would make sure leadership engages the regulator early, rather than at the last minute.