Of course, a project manager should strive to complete a project on time, but is it correct to say that it is a project manager's professional responsibility? I mean that no matter how professional a project manager is, there are always reasons, impediments that can make it impossible to complete a project on time.

How correct is it to take into account the "on-time"-results of a project manager during a performance review?

  • For which project management methodology? Agile and Waterfall give two very different answers for this, and the exact duties of the Project Manager role can vary depending on the specific methodology used within those two broad approaches (e.g. DSDM vs Scrum).
    – nick012000
    Commented Sep 16, 2020 at 6:23

9 Answers 9


All work is probabilistic. It has an extremely improbable best case result, an extremely improbable worst case result, and an extremely probable most likely result. That probabilistic distribution is driven by both random and non-random variables and a PM, no matter how talented, can do absolutely nothing about the random variables and can likely affect only very little the non-random variables. However, the PM is ultimately accountable to achieving the work within the project constraints, plus or minus a reasonable variance. Therefore, it IS the PM's responsibility to achieve the project on time plus or minus an agreed upon variance. This logically means, then, that the PM cannot or should not accept a project with unachievable targets. It also means that the PM needs to deploy the controls and forecasting capabilities that enable early detection of variance, active mitigation and recovery, continual forecasting, and--most importantly--active communications to impacted stakeholders.

So it is right to say the PM is responsible for bringing the project in on time...AND responsible for forecasting, managing risks, initiating recovery, using contingencies, communicating variances, setting expectations, and resetting expectations.

Here's the analogy: if a pilot finds himself descending towards the ground prior to plan due to some catastrophic event, if the pilot fails to recover, he and all his passengers still die; however, if he executed everything under his control on the emergency checklist flawlessly, then the pilot did his job and did his job well...but he was still "late."

  • 6
    More to the point, one can be responsible for something without necessesarily being to blame when it goes wrong. The pilot was responsible for getting everyone home alive - they did not, but while it was their responsibility, that it didn't happen wasn't necessarily their fault. I think when doing any kind of post-mortem on a failure it's more important to understand why the failure happened rather than focusing on finding someone to blame for the sake of it. How a company manages failures is probably more telling than how they deal with success.
    – J...
    Commented Sep 15, 2020 at 13:08
  • 2
    Agree with the above comment. It is a nuanced finding: the project manager failed but did a fantastic job. Politically, that's a hard sell but is a realistic finding. It's similar to the PM who receives a ton of accolades because the project was a huge success despite his or her incompetence and poor management. And that happens a lot, at least in my experience. The politics are hard to overcome. Commented Sep 15, 2020 at 13:49
  • "So it is right to say the PM is responsible for bringing the project in on time" - Don't see how this is reality, unless they can change and define when on time is....?
    – P.S.
    Commented Mar 13, 2021 at 19:52
  • "This logically means, then, that the PM cannot or should not accept a project with unachievable targets." ...the reality is you may have no choice if you want to still work there, right?
    – P.S.
    Commented Mar 13, 2021 at 19:56

Yes, a project manager is responsible for completing a project on time. However, "on time" is a date that will often move during the life of the project, and it is the agreed date that the PM should be measured against - not necessarily the original date. The initial date may be agreed by all concerned, however requirements may change, issues are likely to emerge, and the expectations for the project may be modified (e.g. "we have delayed the launch of the new product so we don't need the new system until a later date" - or whatever).

So perhaps you should think of the true responsibility of the PM as delivering the project to the satisfaction of the key stakeholders, which will be delivering against a combination of date, cost, scope, and quality, where these are agreed initially and then modified (re-negotiated) during the life of the project. A successful PM will avoid giving the stakeholders unpleasant surprises by keeping them fully informed of risks and issues, and the impact of them, and agreeing the approach to dealing with each of these - which may be to move timelines, reduce scope, add resources (financial or otherwise), or accept certain risks and the associated consequences (e.g. reduced testing, shorter parallel running, less handover, or whatever). Any of these changes should be subject to formal change management - not just at the whim of the PM, though!

In terms of performance reviews, etc, I would take account of the PM's ability to deliver to the agreed date, and / or minimising the number of changes to the date (or other outcomes), and keep the stakeholders fully informed and comfortable. In my experience, stakeholders don't mind change, as long as they understand the reason for it and as long as the change is fully explained, is justifiable, and isn't just because of poor planning or inept project management.

  • "However, "on time" is a date that will often move during the life of the project" This is true in Waterfall, but it is not true for many Agile methodologies that keep the time fixed and instead drop less-important features as their method of adjusting for underestimating the work required.
    – nick012000
    Commented Sep 16, 2020 at 6:19
  • If you "drop features," ie, drop scope, did you really finish on time? @nick012000 Commented Sep 16, 2020 at 14:07
  • 1
    @Daniel, a date cannot be easily moved without change management. With change management, a date should be easily moved via the controlled process. In fact, the CM process should be easy to engage and get through so folks won't learn to avoid it. Commented Sep 16, 2020 at 15:05
  • 1
    Answer updated to include a mention of formal change management which, as @DavidEspina points out, is crucial. It isn't acceptable for the PM to change things on a whim!
    – Iain9688
    Commented Sep 16, 2020 at 15:35
  • 1
    A successful project manager should also supply the key stakeholders with enough information so that a project which must fail can be canceled. eg the idea guy thinks spinning straw into gold would be a good idea...
    – MaxW
    Commented Sep 16, 2020 at 17:21

A project manager has the overall responsibility for the project's success.

But what is project success, you may ask?

Many executives see project success as delivering software on time, on budget and packed with features, which history has shown, time and time again, that for most projects it's impossible to do. Even if you have the right kind of people and a good professional project manager, s#it can always happen. Upper management needs to understand this and, when things don't go according to plans, to collaborate with the project manager to make projects succeed by using and agreeing on a proper definition of success, instead of nailing down three related constraints that can't all happen at the same time anyways.

With that being said, as a project manager you are an employee. And employers can decide on whatever criteria they want when doing performance reviews of their employees. If they decide that Project Managers need to deliver "on time, no matter what", and have that be a criterion for performance evaluations, then that's what you will be evaluated against.

If it is fair or not is a very complicated question, with many variables. And also, fair for whom? For example:

  • I'm a good, professional, give it 110% project manager, and I fail to deliver "on time" for reasons I had no control over. I get a bad review as a result. This is unfair to me as a project manager.
  • I'm a lazy project manager, I inflated all the estimates and release dates. Some project estimated to take 3 months I said it will take 9 months, the team finishes in 8. Even though I intentionally miscommunicated things, now I'm a good project manager for delivering ahead of time. This time I get a good performance evaluation. But this is unfair for the company because I lied and wasted their money and resources just so I look good at the performance evaluation.

The idea is that sane companies should choose sane criteria for performance evaluations. Those that don't will suffer the consequences (employee turnover, employees wasting their resources to defend themselves against bad policies, etc). You usually get what you measure.

  • "which history has shown, time and time again, that for most projects it's impossible to do" - exactly
    – P.S.
    Commented Mar 13, 2021 at 19:57
  • "I'm a lazy project manager, I inflated all the estimates and release dates. Some project estimated to take 3 months I said it will take 9 months, the team finishes in 8." - don't understand, if it took realistically took 8 months then wasn't that a very good and realistic estimate?
    – P.S.
    Commented Mar 13, 2021 at 20:00
  • @P.S. by that I meant lying about delivering a project, then working towards making the lie sound like the truth. If the project actually took 8 months, then you are also lucky, but still a liar.
    – Bogdan
    Commented Mar 14, 2021 at 9:51

I agree with the other two answers, but I'd phrase it slightly differently.

The Project Manager's primary responsibility is to manage the expectations about the project's completion date. This can involve

  • Working with the project team to ensure that work is accomplished to bring the project to completion at/under/near the estimated completion date.

  • Ensuring that the project stakeholders/sponsor are aware of the current estimated completion date.

  • A variety of project management disciplines to predict, revise, refine, maintain and communicate an accurate project completion date.

  • Recommending pre-emptive closure (cancellation) of the project if the estimated completion date cannot be reconciled with sponsor/stakeholder needs.

The PM's job is to communicate to ensure that none of the parties are surprised. To collect, analyze, and manage the information to maintain an accurate (probabilistic/PERT) project completion date and to communicate that to the right stakeholders in their preferred way, in a timely manner.

  • 1
    this seems a bit more realistic. perhaps the title should be "dynamic probability project accountant".
    – P.S.
    Commented Mar 13, 2021 at 20:05

I can only speak for software projects. The team as a whole ought to be responsible for success and timely delivery. If you are dependent on a PM to get the project done on time then you surely have a dysfunctional or disengaged team.

If you wanted to single out one person having a greater part of the accountability for success then it should be the Product Owner or equivalent rather than a PM. Ultimately it is still up to the team however, since most POs (and PMs) don't have the technical knowledge to create solutions without help.

  • objectively speaking, the whole team IS, right, or how could this not not be?
    – P.S.
    Commented Mar 13, 2021 at 20:02

Well, if projects sometimes didn't "go south," and if managers didn't feel that they'd been sacrificed because of it, then books like The Programmer's Death March probably wouldn't "still be in print." 🤔

As a manager, your influences will necessarily always be "in- direct." You will therefore probably never "be the actual foot-soldier." But you are the "single – emphasis 'single' – point of contact" between the project and the rest of the enveloping business organization.

If only because it is obviously impossible for them to interact directly with every soldier – they quite-necessarily look to the responsible commander: You.

"Does every project 'finish on time?'" Of course not – every timeline is a prediction. But: "was the business organization suprised?!" Did it "unexpectedly cost them money?" Did they "learn, too late, that there might have been something that they could have done, had they known?" These are among your legitimate concerns as a project manager. Because everybody works together, up and down the entire line of command, to satisfy: The Customer.


As already pointed out, a Project Manager who always delivers on time is probably inflating his predictions, and may actually be the cause of projects taking longer than needed.

In a company where the PjM's performance review is based mainly on his on-time delivery, then he may not have a choice, if his review/salary/bonus/career depends on the results of such a review.

Though, implementing Risk Management and Assessment may be an acceptable alternative to on-time delivery.

In a healthy development environment, it's not sensible to judge the PjM on his ETA precision.

What the PjM is expected to do is:

  • ensure all possible impediments to project delay are resolved ASAP, thereby minimizing delays.
  • escalate expected delays in delivery ASAP, so that the stakeholders adjust their expectations.
  • if possible, suggest possible tradeoffs that would allow on-time delivery at the expense of certain deliverables, allowing the stakeholder to make a choice between delivery date and deliverables.

Responsibility is collective. Project Manager is, therefore, definitely as responsible as any other team member for the success or failure of a project.

However, the role of 'Project Manager' varies widely across companies, and also within different teams of the same company.

In some cases, the Project Manager plays some of these highly influential aditional roles:

  1. Line Manager for the Developers
  2. Scrum Master
  3. Single Point of contact for the Business Owner / Business team
  4. Attendance & Payroll approver for the developers
  5. Business Analyst
  6. Decision Maker for hiring people into the team
  7. Single point of contact between the team and Senior Management
  8. Escalation Manager for complaints / feedback from Client.

A Project Manager with such influential aditional role tends to be the first person to claim credit for any success, and also the first person who blames a Developer for any problem.

In these cases, where the Project Manager had influence and involvement in the team activity, the Project Manager is responsible for the success or failure of the project.

Contrastingly, in some cases, the Project Manager has virtually no influence.

In some teams,

  • Project Manager merely sends daily status updates to Senior Leadership.
  • Role of Project Manager is overshadowed by that of a senior Developer or a senior QA Manager who is in the same team.
  • Project Manager does not get the opportunity to get involved in cross-team collaboration, due to not knowing (not having rapport with) people outside the team.

In these cases, where the Project Manager did not have proper influence or involvement in team activity, the Project Manager cannot be held responsible for success or failure of the project.

  • "where the Project Manager did not have proper influence or involvement in team activity" — the job title is "manager" and not "passive observer". If the project manager fails to the extent you describe, I think it would be their last task to identify themselves as a fifth wheel needed by noone, and seek involvement with another team that actually needs someone in this role.
    – Levente
    Commented Mar 13, 2021 at 23:05

Unless they can define when on time is and change as needed (in earnest), it's not realistic to hold them personally accountable.

"Completion" is a strong term within a framework to describe periodically, newly generated, increments of work, all in parallel, with different start/ends, that go on infinitely. Perhaps a softer phrase would be "rebirths" or "alive (vs. dead) lines". (if a business wants to stay alive and profitable in a capitalistic economy it must continue not complete)

Projects unknowns grow with the complexity and dynamics of the project, product, materials, team, 3rd parties, etc. By definition, unknown risk factors are unknown and holding someone accountable for unknowns doesn't harmonize with reality.

"Project Shepherd", might be more accurate, realistic and helpful title to all involved.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.